# Dune CLI & Skills
Source: https://docs.dune.com/api-reference/agents/cli-and-skills

Give your AI coding agent direct access to Dune's blockchain data through the Dune CLI and Agent Skills.

The Dune CLI and Agent Skills give your AI coding agent structured access to Dune's datasets, query engine, visualizations, and dashboards -- directly inside the tools you already use.

The **Dune CLI** is a terminal-native interface for discovering datasets, executing DuneSQL queries, managing visualizations, and building dashboards. **Dune Skills** are portable instruction packages that teach AI agents how to use the CLI effectively -- from writing correct SQL to handling errors and optimizing costs.

Together, they turn any skills-compatible agent into a blockchain data analyst that can go from prompt to published dashboard.

<video />

## Dune CLI

The Dune CLI lets you query, explore, and manage blockchain data without leaving your terminal. All commands support both human-readable and JSON output, making them equally useful for interactive work and agent-driven workflows.

### Install

```bash theme={null}
curl -sSfL https://dune.com/cli/install.sh | sh
```

The install script handles everything you need to get started: it installs the Dune CLI, runs `dune auth` to configure your API key, and installs the Dune Agent Skill via `npx skills add`. In most cases, this single command is all you need.

<Note>
  You'll need a Dune API key during setup. Generate one at [dune.com](https://dune.com) under **APIs and Connectors > API Keys** before running the install script.
</Note>

### Authenticate (manual)

If you need to re-authenticate or configure a different API key after installation, you can run:

```bash theme={null}
dune auth
```

You'll be prompted to enter your API key. It's saved to `~/.config/dune/config.yaml` for future sessions.

Alternatively, pass the key inline or via environment variable:

```bash theme={null}
# Environment variable
export DUNE_API_KEY=<your-api-key>

# Inline flag
dune query run 12345 --api-key <your-api-key>
```

### Usage

Run `dune --help` to see all available commands. All commands support `-o json` for structured, machine-parseable output -- ideal for agent consumption:

```bash theme={null}
dune query run-sql --sql "SELECT * FROM ethereum.transactions LIMIT 5" -o json
```

***

## Dune Skills

[Agent Skills](https://agentskills.io) are an open standard for giving AI agents new capabilities. The Dune Skill teaches your agent how to use the Dune CLI to discover datasets, write DuneSQL, execute queries, handle errors, and manage costs -- all from natural language prompts.

Skills are supported by Claude Code, Cursor, OpenCode, OpenAI Codex, VS Code, Gemini CLI, Goose, and [many more](https://agentskills.io).

<Card title="Dune Skills GitHub Repository" icon="github" href="https://github.com/duneanalytics/skills">
  Source code, skill definitions, and documentation for Dune Agent Skills. Includes the `dune` skill for CLI-based blockchain data queries and the `sim` skill for real-time wallet and token lookups.
</Card>

### Install

The Dune Skill is automatically installed when you run the [CLI install script](#install) above -- no extra steps required.

If you need to install or reinstall the skill separately, you can run:

```bash theme={null}
npx skills add duneanalytics/skills
```

<Tabs>
  <Tab title="Claude Code">
    Skills are automatically installed to `~/.claude/skills/` and loaded when your conversation matches blockchain-related triggers.
  </Tab>

  <Tab title="Cursor">
    You can also add the skill via **Settings > Rules > Add Rule > Remote Rule (Github)** with `duneanalytics/skills`.
  </Tab>

  <Tab title="Manual">
    Clone the [duneanalytics/skills](https://github.com/duneanalytics/skills) repository and copy the `skills/dune/` folder into your agent's skill directory:

    | Agent        | Directory                    |
    | ------------ | ---------------------------- |
    | Claude Code  | `~/.claude/skills/`          |
    | Cursor       | `~/.cursor/skills/`          |
    | OpenCode     | `~/.config/opencode/skills/` |
    | OpenAI Codex | `~/.codex/skills/`           |
  </Tab>
</Tabs>

### How it works

Once installed, the Dune Skill activates automatically when your conversation involves blockchain data, on-chain analytics, DuneSQL, token transfers, DEX trades, smart contract events, or wallet analysis. The agent then:

1. Discovers the right tables using `dune dataset search`
2. Inspects column schemas to build correct SQL
3. Writes DuneSQL with proper partition filters for cost efficiency
4. Executes the query and parses results
5. Generates and manages visualizations (charts, counters, tables)
6. Creates and updates dashboards from query results
7. Handles errors with built-in recovery strategies

The skill includes detailed reference documents for query execution, dataset discovery, DuneSQL syntax, and error handling -- loaded on demand to keep context window usage efficient.

***

## Key Benefits

<CardGroup>
  <Card title="Agent-Native Data Access" icon="robot">
    Your AI agent queries blockchain data directly -- no context switching, no copy-pasting SQL between apps.
  </Card>

  <Card title="Works Where You Work" icon="toolbox">
    Compatible with Claude Code, Cursor, VS Code, Codex, and any agent that supports the Agent Skills standard.
  </Card>

  <Card title="Cost-Aware by Default" icon="coins">
    The skill teaches agents to filter on partition columns and choose the right performance tier, reducing credit consumption.
  </Card>
</CardGroup>

## Use Cases

<CardGroup>
  <Card title="Ad-Hoc Analysis" icon="magnifying-glass-chart">
    Ask your agent a question in plain English and get results backed by DuneSQL -- from DEX volumes to gas trends.
  </Card>

  <Card title="Contract Exploration" icon="file-contract">
    Give the agent a contract address and let it discover all decoded event and call tables automatically.
  </Card>

  <Card title="Pipeline Scripting" icon="code">
    Use the CLI's JSON output and async execution to integrate Dune queries into CI/CD pipelines or monitoring scripts.
  </Card>

  <Card title="Reusable Parameterized Queries" icon="arrows-spin">
    Create saved queries with parameters, then run them with different inputs across sessions.
  </Card>
</CardGroup>


# Dune MCP
Source: https://docs.dune.com/api-reference/agents/mcp

Connect AI agents to Dune's official MCP server for onchain analytics workflows.

MCP (Model Context Protocol) is an open standard for connecting AI applications to external systems.

Dune MCP is Dune's official remote MCP server. It gives your agent direct, structured access to Dune workflows: discover relevant datasets, create and run SQL queries, inspect execution results, manage visualizations, and build dashboards — all in the same conversation.

This is the fastest way to move from prompt to reliable onchain analysis.

<video />

## Setup and Usage

## Authentication

Dune MCP supports two authentication modes today:

1. **OAuth 2.0 (recommended for Browser agents or agents with access to the browser)**
2. **Dune API key (recommended for environments with no access to a browser)**

### OAuth

Typically when setting up OAuth the agent just needs:

* `Name`: Dune
* `url`: `https://api.dune.com/mcp/v1`

When you add these details you will likely see your browser open up on the Dune Login page where upon successful login you will be taken back your Agent where you should be logged in and ready to go.

### Api Key

You can authenticate with the MCP using your [Dune Api Key](/api-reference/overview/authentication)

* Header auth: `x-dune-api-key: <dune-api-key>`
* Query auth (for clients that prefer URL auth): `?api_key=<dune_api_key>`

Generally using the Header is preferred but some agents do now allow you to configure the Headers sent with MCP calls. In those cases you can pass the api key in the url query parameters.

## Setup exampls

### Claude Code

#### Oauth

```

claude mcp add --scope user --transport http dune https://api.dune.com/mcp/v1
```

#### API Key

```bash theme={null}
claude mcp add --scope user --transport http dune https://api.dune.com/mcp/v1 --header "x-dune-api-key: <dune-api-key>"
```

### Claude Desktop

<div>
  <iframe title="Add and Connect a Custom Data Connector" />
</div>

### OpenCode

#### Oauth

<img alt="Connect opencode to Dune MCP" />

Once added run `opencode mcp auth Dune` and it will open up a browser where you can log into Dune.

#### API Key

<img alt="Connect opencode to Dune MCP" />

### Codex

#### Oauth

```bash theme={null}
codex mcp add dune --url "https://api.dune.com/mcp/v1"

# Login after adding the MCP
codex mcp login dune
```

#### API Key

```bash theme={null}
codex mcp add dune_prod --url "https://api.dune.com/mcp/v1?api_key=<dune_api_key>"
```

<Warning>
  **Known issue: "Transport closed" errors during long-running queries**

  Codex's MCP client has a default tool timeout of 60 seconds. When `getExecutionResults` polls for a query that takes longer than this, Codex terminates the connection. Due to a [known Codex bug](https://github.com/openai/codex/issues/11489), the MCP transport does not auto-reconnect after a timeout - all subsequent tool calls will fail with `Transport closed` until you start a new session.

  **Workaround:** Increase the Codex tool timeout in your config:

  ```toml theme={null}
  [mcp_servers.dune]
  url = "https://api.dune.com/mcp/v1"
  tool_timeout_sec = 300
  ```
</Warning>

### Cursor

<div>
  <iframe title="Add a Custom MCP Server in Cursor" />
</div>

tl:dr; Add this configuration to your Cursor settings:

**Oauth**

```json theme={null}
{
  "mcpServers": {
    "dune": {
      "url": "https://api.dune.com/mcp/v1",
    }
  }
}
```

**Api Key**

```json theme={null}
{
  "mcpServers": {
    "dune": {
      "url": "https://api.dune.com/mcp/v1",
      "headers": {
        "X-DUNE-API-KEY": "<api_key>"
      }
    }
  }
}
```

## Tools and Resources Inventory

### Tools

| Category            | Tool                            | Description                                                 |
| ------------------- | ------------------------------- | ----------------------------------------------------------- |
| **Discovery**       | `searchDocs`                    | Search Dune docs for guides, examples, and API references   |
| **Discovery**       | `searchTables`                  | Find tables by protocol, chain, category, or schema         |
| **Discovery**       | `listBlockchains`               | List indexed blockchains with table counts                  |
| **Discovery**       | `searchTablesByContractAddress` | Find decoded event/call tables for a contract address       |
| **Discovery**       | `getTableSize`                  | Estimate the data scanned by a query for one or more tables |
| **Query Lifecycle** | `createDuneQuery`               | Create and save a new Dune query                            |
| **Query Lifecycle** | `getDuneQuery`                  | Fetch SQL and metadata for an existing query                |
| **Query Lifecycle** | `updateDuneQuery`               | Update SQL, title, description, tags, or parameters         |
| **Query Lifecycle** | `executeQueryById`              | Execute a saved query and return an execution ID            |
| **Query Lifecycle** | `getExecutionResults`           | Fetch status and results for a query execution              |
| **Visualization**   | `generateVisualization`         | Create charts, counters, and tables from query results      |
| **Visualization**   | `getVisualization`              | Fetch details of an existing visualization                  |
| **Visualization**   | `updateVisualization`           | Update an existing visualization's configuration            |
| **Visualization**   | `deleteVisualization`           | Delete a visualization                                      |
| **Visualization**   | `listQueryVisualizations`       | List all visualizations attached to a query                 |
| **Dashboard**       | `createDashboard`               | Create a new dashboard with widgets and layout              |
| **Dashboard**       | `getDashboard`                  | Fetch details of an existing dashboard                      |
| **Dashboard**       | `updateDashboard`               | Update a dashboard's content, layout, or metadata           |
| **Dashboard**       | `archiveDashboard`              | Archive a dashboard                                         |
| **Account**         | `getUsage`                      | Check current billing-period credit usage                   |

### Resources

| Resource                                 | Description                                     |
| ---------------------------------------- | ----------------------------------------------- |
| `query-engine-writing-efficient-queries` | Performance and cost best practices for DuneSQL |
| `query-engine-functions-and-operators`   | DuneSQL function/operator reference             |

## Server Details

* **Server name:** `dune`
* **Remote MCP URL:** `https://api.dune.com/mcp/v1`
* **Tagline:** Query, analyze, and visualize onchain data from Dune directly inside your MCP-compatible AI client.
* **Primary use cases:**
  * Discover datasets and docs relevant to a protocol, contract, or chain
  * Create, update, execute, and troubleshoot Dune SQL queries
  * Turn query results into charts/tables/counters without leaving your chat
  * Create and manage full dashboards from natural language prompts
  * Track account credit usage while iterating on analysis

## Prompt Examples

Try prompts like these in your MCP-enabled client:

1. "Find the best Dune table for tracking Uniswap v3 swap volume on Ethereum, then create and run a daily volume query for the last 90 days."
2. "I have contract `0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48`. Find decoded tables, build a weekly transfer count query, execute it, and show the top 20 recipient wallets."
3. "Review query `1234567`, optimize it for lower scan cost, update it in place, run it, and summarize result quality and execution credits used."
4. "Generate a visualization from my latest execution results: a line chart of daily active addresses and a counter for total unique users."
5. "Create a dashboard showing Ethereum activity in the past 30 days — include daily transactions, active addresses, and gas usage."
6. "Update my existing dashboard to add a new chart showing weekly DEX volume by protocol."

## Connection Details

### Transport

* Protocol: **Remote MCP over Streamable HTTP**
* Endpoint: `https://api.dune.com/mcp/v1`
* Interaction pattern:
  * `POST /mcp/v1` for MCP requests
  * `GET /mcp/v1` for stream resumption/event replay

#### OAuth 2.0 details

* Authorization server issuer: `https://dune.com/oauth/mcp`
* Discovery metadata: `https://dune.com/.well-known/oauth-authorization-server/oauth/mcp`
* Authorization endpoint: `https://dune.com/oauth/mcp/authorize`
* Token endpoint: `https://dune.com/oauth/mcp/token`
* Dynamic client registration endpoint: `https://dune.com/oauth/mcp/register`
* JWKS endpoint: `https://dune.com/oauth/mcp/jwks.json`
* Grant types: `authorization_code`, `refresh_token`
* Client auth at token endpoint: `none` (public clients)
* PKCE: required (`S256`)
* Scope: `mcp:dune:full`
* Resource parameter for authorization requests: `https://api.dune.com`

## Troubleshooting

* **OAuth `invalid_request` on authorize:** Verify required params (`client_id`, `redirect_uri`, `state`, `code_challenge`, `code_challenge_method=S256`, `resource=https://api.dune.com`).
* **OAuth `unsupported_grant_type` on token:** Use only `authorization_code` or `refresh_token`.
* **OAuth `invalid_grant` on token exchange:** Ensure your `code_verifier` matches the original PKCE challenge and `redirect_uri` exactly matches the authorize request.
* **`Unauthorized` from MCP endpoint:** Confirm valid auth (OAuth bearer token or Dune API key).
* **Codex `Transport closed` during long polls:** Increase MCP tool timeout (for example `tool_timeout_sec = 300`) and restart the session if the transport already closed.

## Related Resources

<CardGroup>
  <Card title="Dune Skills Repository" icon="github" href="https://github.com/duneanalytics/skills">
    Agent Skills for Dune -- portable instruction packages that teach AI agents how to work with blockchain data using the Dune CLI and Sim API.
  </Card>

  <Card title="Dune CLI & Skills Docs" icon="terminal" href="/api-reference/agents/cli-and-skills">
    Learn how to use the Dune CLI and Agent Skills as an alternative to MCP for terminal-native AI workflows.
  </Card>
</CardGroup>

## Privacy and Support

* Privacy policy: [https://dune.com/privacy](https://dune.com/privacy)
* Support: [support@dune.com](mailto:support@dune.com)


# Dune MPP
Source: https://docs.dune.com/api-reference/agents/mpp

Access Dune's API with pay-per-request micropayments using the Machine Payment Protocol.

MPP (Machine Payment Protocol) is an open standard for machine-to-machine HTTP micropayments built on the [HTTP 402 challenge-response flow](https://paymentauth.org/draft-httpauth-payment-00.txt). Dune's MPP integration lets agents pay per-request through a payment channel - no API keys, no user account, and no credit card required.

## How It Works

1. Your client sends a request to a Dune API endpoint.
2. Dune responds with **HTTP 402** and a `WWW-Authenticate: Payment` challenge describing the cost.
3. The `mppx` client library automatically opens a **Tempo payment channel** on the first 402, depositing funds into an on-chain escrow.
4. Subsequent requests are authenticated with signed channel vouchers deducted from the deposit.
5. When you are done, you **close the session** and any unspent deposit is returned to your wallet.

## Available Endpoints

| Endpoint                                  | Description                           |
| ----------------------------------------- | ------------------------------------- |
| `POST /v1/sql/execute`                    | Execute a SQL query                   |
| `GET /v1/execution/:execution_id/results` | Fetch JSON results for an execution   |
| `GET /v1/execution/:execution_id/csv`     | Download CSV results for an execution |

***

## Option 1: Agentic Integration

The fastest way to get started. Ask your AI coding agent to set up Tempo and run a query on Dune - no manual code required. This works with any agent that supports skills or tool use, including Claude Code, Cursor, OpenAI Codex, OpenCode, and others.

### Getting Started

Simply give your agent the following prompt:

```
Read https://tempo.xyz/SKILL.md and set up tempo.
After that, use MPP to run the following query on Dune:

SELECT * FROM ethereum.transactions LIMIT 10
```

Your agent will:

1. Read the Tempo skill instructions and configure itself
2. Open a payment channel funded from your crypto wallet
3. Execute the query against Dune's API via MPP
4. Return the results directly in your conversation

No Dune account, no API key, and no credit card needed - you pay per-request with crypto.

### Closing Your Session

<Warning>
  Always ask your agent to **close the session** when you are done. Closing the session settles the payment channel on-chain and refunds any reserved funds back to your wallet - you are only charged for what you actually used.
</Warning>

When you are finished querying, tell your agent:

```
Close the tempo session.
```

This ensures your unspent deposit is returned promptly. If you forget to close, funds remain in escrow until the channel expires.

***

## Option 2: Manual Integration

For full control, you can integrate MPP directly into your application using the [`mppx`](https://github.com/wevm/mppx) client library and [`viem`](https://viem.sh) for EVM account management. The `mppx` session API wraps the standard `fetch` and handles the 402 negotiation, channel management, spend tracking, and payment signing transparently.

### Step 1 - Install dependencies

```bash theme={null}
npm install mppx viem
```

### Step 2 - Set up your wallet and initialize a session

Create an account from a private key and initialize a Tempo session. The `maxDeposit` parameter sets the maximum amount (in USD) to escrow when a payment channel is opened.

```typescript theme={null}
import { tempo } from "mppx/client";
import { privateKeyToAccount } from "viem/accounts";

const account = privateKeyToAccount(
  process.env.PRIVATE_KEY as `0x${string}`
);
const session = tempo.session({ account, maxDeposit: "10" });
```

### Step 3 - Execute a query

Use `session.fetch` exactly like the standard Fetch API. On the first call, the session intercepts the 402 response, opens a Tempo payment channel, and retries the request with a valid payment credential - all transparently.

```typescript theme={null}
const execRes = await session.fetch("https://api.dune.com/api/v1/sql/execute", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ sql: "SELECT * FROM ethereum.transactions LIMIT 10" }),
});
const { execution_id } = (await execRes.json()) as { execution_id: string };
```

### Step 4 - Poll until the query completes

Dune executes queries asynchronously. Poll the status endpoint until the state is `QUERY_STATE_COMPLETED`.

```typescript theme={null}
let state = "";
do {
  const r = await session.fetch(
    `https://api.dune.com/api/v1/execution/${execution_id}/status`
  );
  state = ((await r.json()) as { state: string }).state;
  if (state === "QUERY_STATE_FAILED") throw new Error("Query failed");
  if (state !== "QUERY_STATE_COMPLETED")
    await new Promise((r) => setTimeout(r, 2_000));
} while (state !== "QUERY_STATE_COMPLETED");
```

### Step 5 - Fetch results

Once the query completes, retrieve the results. Each request is automatically paid through the open channel.

```typescript theme={null}
const resultsRes = await session.fetch(
  `https://api.dune.com/api/v1/execution/${execution_id}/results`
);
console.log(await resultsRes.json());
```

### Step 6 - Close the session

When you are finished, close the session to settle on-chain and reclaim any unspent deposit. You are only charged for what you used.

```typescript theme={null}
await session.close();
```

***

## Learn More

* [`mppx` client library](https://github.com/wevm/mppx) - TypeScript SDK for MPP
* [paymentauth.org](https://paymentauth.org/) - protocol specifications and registry
* [Dune API Reference](/api-reference/overview/introduction) - full list of available API endpoints


# Data API Overview
Source: https://docs.dune.com/api-reference/api-overview



Access Dune's onchain data programmatically via REST endpoints.

The Data API provides programmatic access to execute queries, manage data, track usage, and integrate Dune's onchain analytics into your applications, workflows, and environments.

<Note>
  For complete endpoint documentation, authentication guides, and code examples, visit the **[API Reference](/api-reference/overview/introduction)** tab.
</Note>

## Available Endpoints

<CardGroup>
  <Card title="Executions and Results" icon="play" href="/api-reference/executions/execution-object">
    Execute saved queries and retrieve results in various formats
  </Card>

  <Card title="Query Management" icon="pen-to-square" href="/api-reference/queries/endpoint/query-object">
    Create, update, and manage your Dune queries programmatically
  </Card>

  <Card title="Data Uploads" icon="upload" href="/api-reference/tables/endpoint/overview">
    Upload and manage custom datasets as queryable tables
  </Card>

  <Card title="Materialized Views" icon="layer-group" href="/api-reference/materialized-views/overview">
    Create and refresh materialized views for improved performance
  </Card>

  <Card title="Pipelines" icon="diagram-project" href="/api-reference/pipelines/overview">
    Execute and monitor query pipelines with coordinated workflows
  </Card>

  <Card title="Account Management" icon="user" href="/api-reference/usage/overview">
    Monitor API usage and credit consumption
  </Card>
</CardGroup>

## Full API Reference

<Card title="API Reference Documentation" icon="book" href="/api-reference/overview/introduction">
  Complete endpoint documentation with authentication, rate limits, SDKs, and detailed code examples →
</Card>


# Analyze Onchain Data
Source: https://docs.dune.com/api-reference/apis/quickstart-analyze

Execute SQL queries and build custom analytics pipelines with Dune's query execution engine

## Overview

Perfect for data teams, researchers, and analysts who need to programmatically analyze onchain data, build custom reports, and create automated analytics pipelines.

## What You'll Learn

* Execute SQL queries via API
* Retrieve and process results
* Handle query parameters
* Build analytics pipelines
* Filter and transform data

## Prerequisites

* A Dune account ([create one free](https://dune.com/auth/register))
* An API key ([get your API key](https://dune.com/apis?tab=keys))
* Basic familiarity with SQL

## Quick Start

### 1. Execute a Simple Query

Let's start by executing a query to analyze recent DEX trading volume:

<CodeGroup>
  ```python Python theme={null} theme={null}
  from dune_client.client import DuneClient
  import pandas as pd

  # Initialize client
  dune = DuneClient(api_key="YOUR_API_KEY")

  # Execute SQL query
  sql = """
  SELECT 
      blockchain,
      DATE_TRUNC('hour', block_time) as hour,
      SUM(amount_usd) as volume_usd,
      COUNT(*) as trade_count
  FROM dex.trades
  WHERE block_time > now() - interval '24' hour
  GROUP BY 1, 2
  ORDER BY 2 DESC
  """

  results = dune.run_sql(query_sql=sql)

  # Convert to pandas DataFrame for analysis
  df = pd.DataFrame(results.result.rows)
  print(df.head())
  ```

  ```bash cURL theme={null} theme={null}
  # Step 1: Execute query
  curl -X POST "https://api.dune.com/api/v1/sql/execute" \
    -H "Content-Type: application/json" \
    -H "X-Dune-Api-Key: YOUR_API_KEY" \
    -d '{
      "sql": "SELECT blockchain, DATE_TRUNC('\''hour'\'', block_time) as hour, SUM(amount_usd) as volume_usd, COUNT(*) as trade_count FROM dex.trades WHERE block_time > now() - interval '\''24'\'' hour GROUP BY 1, 2 ORDER BY 2 DESC",
      "performance": "medium"
    }'

  # Response includes execution_id
  # {"execution_id":"01JA...","state":"QUERY_STATE_EXECUTING"}

  # Step 2: Get results (after query completes)
  curl "https://api.dune.com/api/v1/execution/{execution_id}/results" \
    -H "X-Dune-Api-Key: YOUR_API_KEY"
  ```
</CodeGroup>

<Note>
  The `run_sql()` function in our Python SDK automatically handles query execution and polling for completion. With cURL, you'll need to poll the execution status endpoint and then fetch results manually.
</Note>

### 2. Use Parameterized Queries

For reusable analytics, create queries with parameters:

<CodeGroup>
  ```python Python theme={null} theme={null}
  from dune_client.client import DuneClient
  from dune_client.query import QueryBase
  from datetime import datetime, timedelta

  dune = DuneClient(api_key="YOUR_API_KEY")

  # Execute a saved query with parameters
  query_id = 3493826  # Example: Popular DEX analysis query

  query = QueryBase(query_id=query_id)
  results = dune.run_query(query=query)

  # Process results
  for row in results.result.rows:
      protocol = row.get('protocol') or row.get('project', 'Unknown')
      volume = row.get('volume') or row.get('volume_usd', 0)
      print(f"{protocol}: ${volume:,.2f}")
  ```

  ```typescript TypeScript theme={null} theme={null}
  import { DuneClient, QueryParameter } from '@duneanalytics/client-sdk';

  const client = new DuneClient(process.env.DUNE_API_KEY ?? '');

  // Execute a saved query with parameters
  const queryId = 3493826;

  const params = {
    query_parameters: [
      QueryParameter.text("blockchain", "ethereum"),
      QueryParameter.number("min_volume", 1000),
      QueryParameter.number("days", 7),
    ]
  };

  client
    .runQuery(queryId, params)
    .then((executionResult) => {
      // Process results
      executionResult.result?.rows.forEach(row => {
        console.log(`${row.protocol}: $${row.volume.toLocaleString()}`);
      });
    });
  ```
</CodeGroup>

### 3. Build an Analytics Pipeline

Create a pipeline that runs multiple queries and combines results:

```python theme={null} theme={null}
from dune_client.client import DuneClient
import pandas as pd
from datetime import datetime

dune = DuneClient(api_key="YOUR_API_KEY")

def daily_dex_analysis():
    """Run daily DEX analytics pipeline"""
    
    # 1. Get overall volume
    volume_query = """
    SELECT 
        SUM(amount_usd) as total_volume,
        COUNT(DISTINCT taker) as unique_traders
    FROM dex.trades
    WHERE block_time > now() - interval '24' hour
    """
    volume_data = dune.run_sql(query_sql=volume_query)
    
    # 2. Get top protocols
    protocol_query = """
    SELECT 
        project as protocol,
        SUM(amount_usd) as volume,
        COUNT(*) as trades
    FROM dex.trades
    WHERE block_time > now() - interval '24' hour
    GROUP BY 1
    ORDER BY 2 DESC
    LIMIT 10
    """
    protocol_data = dune.run_sql(query_sql=protocol_query)
    
    # 3. Get chain breakdown
    chain_query = """
    SELECT 
        blockchain,
        SUM(amount_usd) as volume
    FROM dex.trades
    WHERE block_time > now() - interval '24' hour
    GROUP BY 1
    ORDER BY 2 DESC
    """
    chain_data = dune.run_sql(query_sql=chain_query)
    
    # Combine and process results
    report = {
        'timestamp': datetime.now(),
        'total_volume': volume_data.result.rows[0]['total_volume'],
        'unique_traders': volume_data.result.rows[0]['unique_traders'],
        'top_protocols': pd.DataFrame(protocol_data.result.rows),
        'chain_breakdown': pd.DataFrame(chain_data.result.rows)
    }
    
    return report

# Run pipeline
report = daily_dex_analysis()
print(f"24h Volume: ${report['total_volume']:,.2f}")
print(f"Unique Traders: {report['unique_traders']:,}")
print("\nTop Protocols:")
print(report['top_protocols'])
```

### 4. Filter and Transform Results

Use Dune's powerful filtering to refine results:

<CodeGroup>
  ```python Python theme={null} theme={null}
  from dune_client.client import DuneClient

  dune = DuneClient(api_key="YOUR_API_KEY")

  # Execute query with SQL-based filtering
  sql = """
  SELECT 
      blockchain,
      project,
      SUM(amount_usd) as volume_usd
  FROM dex.trades
  WHERE block_time > now() - interval '24' hour
      AND blockchain = 'ethereum'
      AND amount_usd > 1000000
  GROUP BY 1, 2
  ORDER BY 3 DESC
  """

  results = dune.run_sql(query_sql=sql)

  # Results are already filtered server-side
  for row in results.result.rows:
      print(row)
  ```

  ```bash cURL theme={null} theme={null}
  # Execute query, then filter results
  curl "https://api.dune.com/api/v1/execution/{execution_id}/results?filters=blockchain%20%3D%20%27ethereum%27%20AND%20volume_usd%20%3E%201000000" \
    -H "X-Dune-Api-Key: YOUR_API_KEY"
  ```
</CodeGroup>

<Tip>
  Server-side filtering with Dune's SQL-like WHERE clause syntax is unique to Dune's API! It saves bandwidth and processing time compared to filtering client-side.
</Tip>

## Common Patterns

### Scheduled Analytics

Run analytics on a schedule (e.g., with cron, Airflow, or cloud scheduler):

```python theme={null} theme={null}
import schedule
import time
from dune_client.client import DuneClient

dune = DuneClient(api_key="YOUR_API_KEY")

def hourly_report():
    """Generate hourly DEX report"""
    sql = """
    SELECT 
        project,
        SUM(amount_usd) as hourly_volume
    FROM dex.trades
    WHERE block_time > now() - interval '1' hour
    GROUP BY 1
    ORDER BY 2 DESC
    """
    
    results = dune.run_sql(query_sql=sql)
    
    # Send to your dashboard/database/Slack
    send_to_dashboard(results.result.rows)

# Run every hour
schedule.every().hour.at(":00").do(hourly_report)

while True:
    schedule.run_pending()
    time.sleep(60)
```

### Onchain Monitoring

Monitor specific metrics and trigger alerts:

```python theme={null} theme={null}
from dune_client.client import DuneClient
import time

dune = DuneClient(api_key="YOUR_API_KEY")

def monitor_large_trades(threshold=1000000):
    """Alert on large trades"""
    sql = f"""
    SELECT *
    FROM dex.trades
    WHERE block_time > now() - interval '5' minute
    AND amount_usd > {threshold}
    ORDER BY block_time DESC
    """
    
    results = dune.run_sql(query_sql=sql)
    
    if results.result.rows:
        for trade in results.result.rows:
            send_alert(f"Large trade: ${trade['amount_usd']:,.2f} on {trade['blockchain']}")

# Run continuously
while True:
    monitor_large_trades()
    time.sleep(300)  # Check every 5 minutes
```

## Next Steps

<CardGroup>
  <Card title="Execute Queries API" icon="play" href="/api-reference/executions/endpoint/execute-sql">
    Full API reference for query execution
  </Card>

  <Card title="Result Filtering" icon="filter" href="/api-reference/executions/filtering">
    Advanced filtering techniques
  </Card>

  <Card title="Materialized Views" icon="layer-group" href="/api-reference/materialized-views/create">
    Create and manage materialized views
  </Card>

  <Card title="DuneSQL Functions" icon="database" href="/query-engine/Functions-and-operators">
    Learn DuneSQL functions and operators
  </Card>
</CardGroup>

## Example Use Cases

* **Research Reports:** Generate daily/weekly reports on DeFi protocols, NFT markets, or chain activity
* **Automated Dashboards:** Feed data to custom dashboards or BI tools
* **Alert Systems:** Monitor metrics and trigger alerts when thresholds are met
* **Comparative Analysis:** Compare metrics across chains, protocols, or time periods


# Build Custom Dashboards & Reports
Source: https://docs.dune.com/api-reference/apis/quickstart-dashboards

Fetch query results, manage executions, and create dynamic visualizations in your own applications

## Overview

Perfect for product teams embedding analytics into their applications, creating white-label solutions, or building custom reporting tools on top of Dune's data.

## What You'll Learn

* Fetch and display query results
* Build interactive visualizations
* Manage query executions
* Create parameterized dashboards
* Handle real-time updates
* Export data in multiple formats

## Prerequisites

* A Dune account ([create one free](https://dune.com/auth/register))
* An API key ([get your API key](https://dune.com/apis?tab=keys))
* Basic knowledge of your frontend framework (React, Vue, etc.)

## Installation

Install the required SDK for your language:

<CodeGroup>
  ```bash TypeScript theme={null}
  npm install @duneanalytics/client-sdk
  ```

  ```bash Python theme={null}
  pip install dune-client
  ```
</CodeGroup>

## Quick Start

### 1. Fetch Query Results

Start by fetching results from an existing Dune query:

<CodeGroup>
  ```javascript React theme={null}
  import { useEffect, useState } from 'react';
  import { DuneClient } from '@duneanalytics/client-sdk';

  function DashboardWidget() {
    const [data, setData] = useState(null);
    const [loading, setLoading] = useState(true);
    
    const dune = new DuneClient(process.env.DUNE_API_KEY);
    
    useEffect(() => {
      async function fetchData() {
        try {
          // Execute query and get results
          const executionResult = await dune.runQuery({ queryId: 3493826 });
          setData(executionResult.result?.rows);
        } catch (error) {
          console.error('Error fetching data:', error);
        } finally {
          setLoading(false);
        }
      }
      
      fetchData();
    }, []);
    
    if (loading) return <div>Loading...</div>;
    
    return (
      <div>
        <h2>DEX Volume (24h)</h2>
        <table>
          <thead>
            <tr>
              <th>Protocol</th>
              <th>Volume</th>
            </tr>
          </thead>
          <tbody>
            {data?.map((row, i) => (
              <tr key={i}>
                <td>{row.protocol}</td>
                <td>${row.volume.toLocaleString()}</td>
              </tr>
            ))}
          </tbody>
        </table>
      </div>
    );
  }

  export default DashboardWidget;
  ```

  ```python Python (Flask) theme={null}
  from flask import Flask, jsonify, render_template
  from dune_client.client import DuneClient
  from dune_client.query import QueryBase
  app = Flask(__name__)
  # DuneClient will read the DUNE_API_KEY environment variable
  dune = DuneClient()

  @app.route('/api/dashboard/dex-volume')
  def get_dex_volume():
      """API endpoint for DEX volume data"""
      query = QueryBase(query_id=3493826)
      results = dune.run_query(query)
      return jsonify({
          'data': results.get_rows(),
          'metadata': {
              'execution_id': results.execution_id,
              'row_count': len(results.get_rows())
          }
      })

  @app.route('/dashboard')
  def dashboard():
      """Render dashboard page"""
      return render_template('dashboard.html')

  if __name__ == '__main__':
      app.run(debug=True)
  ```

  ```python Python (Streamlit) theme={null}
  import streamlit as st
  from dune_client.client import DuneClient
  from dune_client.query import QueryBase
  import pandas as pd
  import plotly.express as px

  # DuneClient will read the DUNE_API_KEY environment variable
  dune = DuneClient()

  st.set_page_config(page_title="DEX Analytics", layout="wide")

  # Dashboard title
  st.title("📊 DEX Analytics Dashboard")

  # Fetch data
  @st.cache_data(ttl=300)  # Cache for 5 minutes
  def load_data():
      query = QueryBase(query_id=3493826)
      results = dune.run_query(query)
      return pd.DataFrame(results.get_rows())

  df = load_data()

  # Display metrics
  col1, col2, col3 = st.columns(3)
  with col1:
      st.metric("Total Volume", f"${df['volume'].sum():,.0f}")
  with col2:
      st.metric("Total Trades", f"{df['trade_count'].sum():,}")
  with col3:
      st.metric("Protocols", len(df))

  # Visualization
  fig = px.bar(df, x='protocol', y='volume', title='Volume by Protocol')
  st.plotly_chart(fig, use_container_width=True)

  # Data table
  st.dataframe(df, use_container_width=True)
  ```
</CodeGroup>

### 2. Build Interactive Visualizations

Create charts using popular visualization libraries:

```python Plotly theme={null}
from dune_client.client import DuneClient
import plotly.graph_objects as go
import pandas as pd

dune = DuneClient(api_key="YOUR_API_KEY")

# Fetch data
sql = """
SELECT 
  DATE_TRUNC('hour', block_time) as time,
  blockchain,
  SUM(amount_usd) as volume
FROM dex.trades
WHERE block_time > now() - interval '24' hour
GROUP BY 1, 2
ORDER BY 1
"""

results = dune.run_sql(query_sql=sql)
df = pd.DataFrame(results.get_rows())

# Create interactive chart
fig = go.Figure()

for blockchain in df['blockchain'].unique():
    chain_data = df[df['blockchain'] == blockchain]
    fig.add_trace(go.Scatter(
        x=chain_data['time'],
        y=chain_data['volume'],
        name=blockchain,
        mode='lines'
    ))

fig.update_layout(
    title='DEX Volume by Chain',
    xaxis_title='Time',
    yaxis_title='Volume (USD)',
    hovermode='x unified'
)

fig.show()
```

<Note>
  **Important Limitations:**

  * **TypeScript SDK:** The TypeScript SDK (`@duneanalytics/client-sdk`) only supports saved queries, not direct SQL execution. For JavaScript/TypeScript applications, create a saved query on Dune and use `dune.runQuery({ queryId })`.

  * **Python SDK:** Direct SQL execution with `dune.run_sql()` requires a Dune Plus subscription. For most users, use saved queries with `query = QueryBase(query_id=123)` and `dune.run_query(query)`.

  The example above shows SQL execution using the Python SDK (Plus subscription required).
</Note>

### 3. Parameterized Dashboards

Create dashboards with user-configurable filters using saved queries:

```typescript theme={null}
import { useState, useEffect } from 'react';
import { DuneClient, QueryParameter } from '@duneanalytics/client-sdk';

interface DashboardFilters {
  blockchain: string;
  protocol: string;
  timeRange: string;
}

function ParameterizedDashboard() {
  const [filters, setFilters] = useState<DashboardFilters>({
    blockchain: 'ethereum',
    protocol: 'all',
    timeRange: '24h'
  });
  const [data, setData] = useState(null);
  
  const dune = new DuneClient(process.env.DUNE_API_KEY!);
  
  useEffect(() => {
    async function fetchData() {
      // Use a saved query with parameters instead of SQL
      const queryId = 3493826; // Your parameterized query ID
      
      const executionResult = await dune.runQuery({
        queryId,
        query_parameters: [
          QueryParameter.text("blockchain", filters.blockchain),
          QueryParameter.text("time_range", filters.timeRange),
        ]
      });
      setData(executionResult.result?.rows);
    }
    
    fetchData();
  }, [filters]);
  
  return (
    <div>
      <div className="filters">
        <select 
          value={filters.blockchain}
          onChange={(e) => setFilters({...filters, blockchain: e.target.value})}
        >
          <option value="all">All Chains</option>
          <option value="ethereum">Ethereum</option>
          <option value="polygon">Polygon</option>
          <option value="arbitrum">Arbitrum</option>
        </select>
        
        <select 
          value={filters.timeRange}
          onChange={(e) => setFilters({...filters, timeRange: e.target.value})}
        >
          <option value="24h">Last 24 Hours</option>
          <option value="7d">Last 7 Days</option>
          <option value="30d">Last 30 Days</option>
        </select>
      </div>
      
      <div className="data-display">
        {data && <VolumeTable data={data} />}
      </div>
    </div>
  );
}
```

### 4. Real-time Dashboard Updates

Implement automatic data refreshes:

```javascript theme={null}
import { useEffect, useState, useCallback } from 'react';
import { DuneClient } from '@duneanalytics/client-sdk';

function RealtimeDashboard() {
  const [data, setData] = useState(null);
  const [lastUpdate, setLastUpdate] = useState(null);
  const [autoRefresh, setAutoRefresh] = useState(true);
  
  const dune = new DuneClient(process.env.DUNE_API_KEY);
  
  const fetchData = useCallback(async () => {
    try {
      const executionResult = await dune.runQuery({ queryId: 3493826 });
      
      setData(executionResult.result?.rows);
      setLastUpdate(new Date());
    } catch (error) {
      console.error('Failed to fetch data:', error);
    }
  }, []);
  
  useEffect(() => {
    // Initial fetch
    fetchData();
    
    // Set up auto-refresh
    let interval;
    if (autoRefresh) {
      interval = setInterval(fetchData, 60000); // Refresh every minute
    }
    
    return () => {
      if (interval) clearInterval(interval);
    };
  }, [fetchData, autoRefresh]);
  
  return (
    <div>
      <div className="controls">
        <button onClick={fetchData}>Refresh Now</button>
        <label>
          <input
            type="checkbox"
            checked={autoRefresh}
            onChange={(e) => setAutoRefresh(e.target.checked)}
          />
          Auto-refresh
        </label>
        {lastUpdate && (
          <span>Last updated: {lastUpdate.toLocaleTimeString()}</span>
        )}
      </div>
      
      <div className="dashboard-content">
        {data && <DashboardContent data={data} />}
      </div>
    </div>
  );
}
```

## Advanced Patterns

### Multi-Query Dashboard

Combine data from multiple queries:

```python theme={null}
from dune_client.client import DuneClient
from dune_client.query import QueryBase
from concurrent.futures import ThreadPoolExecutor

dune = DuneClient(api_key="YOUR_API_KEY")

def build_comprehensive_dashboard():
    """Fetch data from multiple queries in parallel"""
    
    query_ids = {
        'volume': 3493826,
        'users': 3493827,
        'protocols': 3493828,
        'chains': 3493829
    }
    
    # Use ThreadPoolExecutor for parallel execution
    with ThreadPoolExecutor(max_workers=4) as executor:
        futures = {
            name: executor.submit(
                lambda qid: dune.run_query(QueryBase(query_id=qid)),
                query_id
            )
            for name, query_id in query_ids.items()
        }
        
        # Build dashboard data structure
        dashboard = {
            name: future.result().get_rows()
            for name, future in futures.items()
        }
    
    return dashboard

# Run function (no async/await needed)
dashboard_data = build_comprehensive_dashboard()
```

<Note>
  The Python Dune SDK does not support async/await. For parallel query execution, use `ThreadPoolExecutor` as shown above to execute multiple queries concurrently.
</Note>

### Export Data

Provide data export functionality:

```typescript theme={null}
import { DuneClient } from '@duneanalytics/client-sdk';

class DataExporter {
  private dune: DuneClient;
  
  constructor(apiKey: string) {
    this.dune = new DuneClient(apiKey);
  }
  
  async exportToCSV(queryId: number, filename: string) {
    // Use Dune's CSV endpoint
    const response = await fetch(
      `https://api.dune.com/api/v1/query/${queryId}/results/csv`,
      {
        headers: {
          'X-Dune-Api-Key': process.env.DUNE_API_KEY!
        }
      }
    );
    
    const csv = await response.text();
    
    // Trigger download
    const blob = new Blob([csv], { type: 'text/csv' });
    const url = window.URL.createObjectURL(blob);
    const a = document.createElement('a');
    a.href = url;
    a.download = filename;
    a.click();
  }
  
  async exportToJSON(queryId: number) {
    const executionResult = await this.dune.runQuery({ queryId });
    
    const json = JSON.stringify(executionResult.result?.rows, null, 2);
    const blob = new Blob([json], { type: 'application/json' });
    const url = window.URL.createObjectURL(blob);
    const a = document.createElement('a');
    a.href = url;
    a.download = 'data.json';
    a.click();
  }
}

// Usage
function ExportButton({ queryId }: { queryId: number }) {
  const exporter = new DataExporter(process.env.DUNE_API_KEY!);
  
  return (
    <div>
      <button onClick={() => exporter.exportToCSV(queryId, 'data.csv')}>
        Export CSV
      </button>
      <button onClick={() => exporter.exportToJSON(queryId)}>
        Export JSON
      </button>
    </div>
  );
}
```

### Caching Strategy

Implement smart caching for better performance:

```python theme={null}
from flask import Flask, jsonify
from flask_caching import Cache
from dune_client.client import DuneClient
from dune_client.query import QueryBase
import os

app = Flask(__name__)
cache = Cache(app, config={'CACHE_TYPE': 'simple'})
# DuneClient will read the DUNE_API_KEY environment variable
dune = DuneClient()

@app.route('/api/data/<int:query_id>')
@cache.cached(timeout=300)  # Cache for 5 minutes
def get_query_data(query_id):
    """Cached endpoint for query results"""
    query = QueryBase(query_id=query_id)
    results = dune.run_query(query)
    return jsonify({
        'data': results.get_rows(),
        'cached': False,  # First request
        'execution_id': results.execution_id
    })

@app.route('/api/data/<int:query_id>/refresh')
def refresh_data(query_id):
    """Force refresh cached data"""
    cache.delete(f'view//api/data/{query_id}')
    query = QueryBase(query_id=query_id)
    results = dune.run_query(query)
    return jsonify({
        'data': results.get_rows(),
        'cached': False,
        'refreshed': True
    })
```

## Dashboard Templates

### Analytics Dashboard

```javascript theme={null}
// Complete analytics dashboard example using saved queries
import { useEffect, useState } from 'react';
import { DuneClient } from '@duneanalytics/client-sdk';
import { LineChart, BarChart, PieChart } from 'recharts';

function AnalyticsDashboard() {
  const [metrics, setMetrics] = useState({
    totalVolume: 0,
    activeUsers: 0,
    avgTransactionSize: 0,
    topProtocols: []
  });
  
  const dune = new DuneClient(process.env.DUNE_API_KEY);
  
  useEffect(() => {
    async function loadDashboard() {
      // Use saved query IDs for each metric
      const volumeQueryId = 123456;   // Your volume query ID
      const usersQueryId = 123457;    // Your users query ID
      const protocolsQueryId = 123458; // Your protocols query ID
      
      const [volume, users, protocols] = await Promise.all([
        dune.runQuery({ queryId: volumeQueryId }),
        dune.runQuery({ queryId: usersQueryId }),
        dune.runQuery({ queryId: protocolsQueryId })
      ]);
      
      setMetrics({
        totalVolume: volume.result?.rows[0].total,
        activeUsers: users.result?.rows[0].total,
        avgTransactionSize: volume.result?.rows[0].total / users.result?.rows[0].total,
        topProtocols: protocols.result?.rows
      });
    }
    
    loadDashboard();
    
    // Refresh every 5 minutes
    const interval = setInterval(loadDashboard, 300000);
    return () => clearInterval(interval);
  }, []);
  
  return (
    <div className="dashboard">
      <h1>DEX Analytics</h1>
      
      <div className="metrics-grid">
        <MetricCard 
          title="24h Volume" 
          value={`$${metrics.totalVolume.toLocaleString()}`} 
        />
        <MetricCard 
          title="Active Users" 
          value={metrics.activeUsers.toLocaleString()} 
        />
        <MetricCard 
          title="Avg Transaction" 
          value={`$${metrics.avgTransactionSize.toLocaleString()}`} 
        />
      </div>
      
      <div className="charts-grid">
        <BarChart data={metrics.topProtocols} />
      </div>
    </div>
  );
}
```

## Next Steps

<CardGroup>
  <Card title="Execute Queries API" icon="play" href="/api-reference/executions/endpoint/execute-sql">
    Full API reference for query execution
  </Card>

  <Card title="Result Filtering" icon="filter" href="/api-reference/executions/filtering">
    Filter and transform data efficiently
  </Card>

  <Card title="CSV Export" icon="file-csv" href="/api-reference/executions/endpoint/get-execution-result-csv">
    Export data in CSV format
  </Card>

  <Card title="Webhooks" icon="webhook" href="/api-reference/webhooks/webhook">
    Get notified when queries complete
  </Card>
</CardGroup>

## Example Use Cases

* **Internal Analytics:** Build custom dashboards for your team
* **White-label Solutions:** Embed Dune-powered analytics in your product
* **Client Reporting:** Generate automated reports for clients
* **Portfolio Trackers:** Create personalized portfolio dashboards
* **Protocol Dashboards:** Build public dashboards for your protocol


# CI/CD & Workflows
Source: https://docs.dune.com/api-reference/connectors/dbt/cicd-workflows

Set up development workflows and GitHub Actions for dbt on Dune

The dbt template includes pre-configured GitHub Actions workflows for both CI and production deployments.

<Note>
  **Credit Usage in CI/CD**

  All dbt executions triggered by CI/CD workflows consume Dune credits. This includes pull request workflows, deploy workflows, and scheduled runs. The template repository ships with automated triggers **disabled by default** so you can enable them on your own terms. See [Pricing & Best Practices](/api-reference/connectors/dbt/pricing-best-practices) for optimization guidance.
</Note>

## Understanding Credit Costs in CI/CD

When you run dbt models through CI/CD, each execution consumes credits from your Dune plan. Here are a few things to keep in mind:

* **Each push or PR can trigger a pipeline run.** If your GitHub Actions run on every commit, frequent pushes during development will each use credits.
* **All executions draw from the same pool.** Whether a query is triggered locally, from a CI runner, or a scheduled job, it counts the same way.
* **Concurrent executions add up.** Multiple CI jobs running simultaneously (e.g., several open PRs) each consume credits independently.
* **Timed-out queries still use credits.** If a query runs for 30 minutes before timing out, credits are consumed for the compute used during that time.

**Tips for managing costs:**

* Start with `workflow_dispatch` (manual trigger only) until you've validated your models
* Use `--select state:modified` to only run changed models in CI
* Set appropriate query timeouts to keep costs predictable
* Monitor your credit usage in the Dune dashboard after enabling automated workflows

## Development Workflow

### Local Development

1. **Create a feature branch**:
   ```bash theme={null}
   git checkout -b feature/new-transformation
   ```

2. **Develop models locally**:
   ```bash theme={null}
   # Run specific model
   uv run dbt run --select my_model

   # Run with full refresh (ignore incremental logic)
   uv run dbt run --select my_model --full-refresh

   # Run tests for specific model
   uv run dbt test --select my_model
   ```

3. **Query your tables on Dune**:
   * Remember to use the `dune.` catalog prefix:
   ```sql theme={null}
   SELECT * FROM dune.my_team__tmp_alice.my_model
   ```

### Pull Request Workflow

1. **Push changes and open PR**:
   ```bash theme={null}
   git add .
   git commit -m "Add new transformation model"
   git push origin feature/new-transformation
   ```

2. **Automated CI runs**:
   * CI enforces that branch is up-to-date with main
   * Runs modified models with `--full-refresh` in isolated schema `{team}__tmp_pr{number}`
   * Runs tests on modified models
   * Tests incremental run logic

<Note>
  **Tip:** The pull request workflow is disabled by default in the template. To enable it, uncomment the `on:` trigger block in `.github/workflows/dbt_ci.yml`. Each PR sync event (new commits pushed to a PR branch) will trigger a run and consume credits.
</Note>

3. **Team review**:
   * Review transformation logic in GitHub
   * Check CI results
   * Approve and merge when ready

### Production Deployment

The [production workflow](https://github.com/duneanalytics/dune-dbt-template/blob/main/.github/workflows/dbt_prod.yml) includes an hourly schedule (0 \* \* \* \*), but it's commented out by default. You can enable it by uncommenting the corresponding lines when you're ready to run production jobs automatically.

<Note>
  **Tip:** The deploy and scheduled workflows are disabled by default. Only `workflow_dispatch` (manual trigger) is enabled out of the box. Uncomment the `push` and `schedule` triggers in the respective workflow files when you're ready to automate.
</Note>

1. **State comparison**: Uses manifest from previous run to detect changes
2. **Full refresh modified models**: Any changed models run with `--full-refresh`
3. **Incremental run**: All models run with normal incremental logic
4. **Testing**: All models are tested
5. **Notification**: Email sent on failure

## CI/CD with GitHub Actions

The template includes two GitHub Actions workflows:

### CI Workflow (`.github/workflows/ci.yml`)

Runs on every pull request:

```yaml theme={null}
- Enforces branch is up-to-date with main
- Sets DEV_SCHEMA_SUFFIX to pr{number}
- Runs modified models with --full-refresh
- Tests modified models
- Runs incremental logic test
- Tests incremental models
```

**Required GitHub Secrets**:

* `DUNE_API_KEY`

**Required GitHub Variables**:

* `DUNE_TEAM_NAME`

### Production Workflow (`.github/workflows/prod.yml`)

Runs hourly on main branch:

```yaml theme={null}
- Downloads previous manifest (for state comparison)
- Full refreshes any modified models
- Tests modified models
- Runs all models (incremental logic)
- Tests all models
- Uploads manifest for next run
- Sends email notification on failure
```

## Troubleshooting

### Connection Issues

**Problem**: `dbt debug` fails with connection error.

**Solution**:

* Verify `DUNE_API_KEY` and `DUNE_TEAM_NAME` are set correctly
* Check that you have Data Transformations enabled for your team
* Ensure `transformations: true` is in session properties

### Models Not Appearing in Dune

**Problem**: Can't find tables in Data Explorer or queries.

**Solution**:

* Check the Connectors section in Data Explorer under "My Data"
* Remember to use `dune.` catalog prefix in queries
* Verify the table was created in the correct schema

### Incremental Models Not Working

**Problem**: Incremental models always do full refresh.

**Solution**:

* Check that `is_incremental()` macro is used correctly
* Verify the `unique_key` configuration matches your table structure
* Ensure the target table exists before running incrementally

### CI/CD Failures

**Problem**: GitHub Actions failing.

**Solution**:

* Verify secrets and variables are set correctly in GitHub
* Check that branch is up-to-date with main
* Review workflow logs for specific errors

## Limitations

### Metadata Discovery

Limited support for some metadata discovery queries like `SHOW TABLES` or `SHOW SCHEMAS` in certain contexts. This may affect autocomplete in some BI tools.

**Workaround**: Use the [Data Explorer](/web-app/query-editor/data-explorer) or query `information_schema` directly.

### Result Set Size

Large result sets may timeout. Consider:

* Paginating with `LIMIT` and `OFFSET`
* Narrowing filters to reduce data volume
* Breaking complex queries into smaller parts

### Read-After-Write Consistency

Tables and views are available for querying immediately after creation, but catalog caching may cause brief delays (typically \< 60 seconds) before appearing in some listing operations.

### Rate Limits

Rate limits for Data Transformations align with the Dune Data API:

* Requests are subject to the same rate limiting as API executions
* Large query operations run on the [Large Query Engine tier](/query-engine/query-executions#large-engine-size)
* See [Rate Limits](/api-reference/overview/rate-limits) for detailed information


# dbt to Datashare
Source: https://docs.dune.com/api-reference/connectors/dbt/datashares

Sync dbt-managed tables from Dune into your configured datashare target

Use dbt to publish transformation outputs from your private Dune namespace into a configured Datashare target such as Snowflake or BigQuery.

This is useful when you want to keep the transformation logic on Dune, but consume the resulting tables inside your own warehouse.

<Warning>
  dbt to Datashare is an enterprise workflow that requires both **Data Transformations** and **Datashare** to be enabled for your team.
</Warning>

<Note>
  Datashare syncs are billed based on bytes transferred and byte-months of storage for the synced table.
</Note>

## How It Works

1. dbt builds a `table` or `incremental` model in your Dune namespace.
2. A dbt post-hook runs `ALTER TABLE ... EXECUTE datashare(...)` on that table.
3. Dune registers or updates the datashare sync and sends the data to your configured target.
4. You monitor the sync in `dune.datashare.table_syncs` and `dune.datashare.table_sync_runs`.

## Prerequisites

* Enterprise account with Data Transformations enabled
* Datashare configured for your team by Dune
* Dune API key with write access
* A dbt project using the Dune Trino connector

## Recommended Starting Point

The fastest way to get started is the public template repo:

<Card title="dune-dbt-template" icon="github" href="https://github.com/duneanalytics/dune-dbt-template">
  Includes the datashare macro, a prod-only post-hook, and an opt-in example model.
</Card>

## Add The dbt Post-Hook

Add the datashare post-hook to your `dbt_project.yml`:

```yaml theme={null}
models:
  your_project:
    +post-hook:
      - sql: "{{ datashare_trigger_sync() }}"
        transaction: true
```

For safety, the template runs this hook only on the `prod` target. Temporary dev or CI schemas should not create datashare syncs by default.

## Check Table Size Before Syncing

Datashare syncs are billed by reported bytes written during the sync and by byte-months of storage at your target warehouse, so it is worth checking how large a source table is before you enable a sync. You can read the Dune source table's on-disk size from the `$size` metadata table, but you first need to know the **physical** table name that Dune is scanning, which may differ from the logical name you query.

Use the following two-step workflow from any Trino-compatible client (the Dune SQL Editor, a notebook, or `dbt run-operation`).

<Note>
  These queries are read-only and do not require the `transformations=true` session property. The `$size` suffix must be attached to the table name and wrapped in double quotes (for example, `schema."table$size"`).
</Note>

### Step 1: Find The Physical Table Name With `EXPLAIN`

Run `EXPLAIN` against the table you want to size up:

```sql theme={null}
EXPLAIN SELECT * FROM team.schema.table;
```

In the query plan, look for the `TableScan` or `ScanProject` node. The `table = ...` value is the physical table name you need for step 2. The catalog prefix before the colon (for example `dune:` or `delta_prod:`) is part of the connector and should be dropped — only the `schema.table` portion is used in the size query.

### Step 2: Query The `$size` Metadata Table

Plug the physical `schema.table` name from step 1 into the size query, wrapping `table$size` in double quotes:

```sql theme={null}
SELECT
    size_bytes,
    size_bytes / 1000.0 / 1000 / 1000 AS source_size_gb,
    size_bytes / 1000.0 / 1000 / 1000 / 1000 AS source_size_tb
FROM dune.<schema>."<table>$size";
```

This returns the Dune source table's at-rest size using SI units (`1 GB = 1,000,000,000 bytes`). Treat it as a planning estimate only: it is not the destination warehouse table size, and it is not the exact billing meter. Destination storage can differ because each warehouse uses different formats, compression, layout, and metadata. Datashare sync billing is based on bytes written during synchronization, as reported by Dune's sync system. This can differ from both the Dune source table at-rest size and the destination warehouse at-rest size.

### Example 1: A dbt-Created Table

For the dbt model `dune.dune.lineage_query_2`:

```sql theme={null}
EXPLAIN SELECT * FROM dune.dune.lineage_query_2;
```

The `TableScan` line in the plan reads:

```
TableScan[table = dune:dune.lineage_query_2]
```

Here the physical name matches the logical name, so the size query is:

```sql theme={null}
SELECT
    size_bytes,
    size_bytes / 1000.0 / 1000 / 1000 AS source_size_gb,
    size_bytes / 1000.0 / 1000 / 1000 / 1000 AS source_size_tb
FROM dune.dune."lineage_query_2$size";
```

### Example 2: A Dune-Managed Table With A Suffix

For a Dune-managed table such as `base.transactions`:

```sql theme={null}
EXPLAIN SELECT * FROM base.transactions;
```

The plan shows a `ScanProject` node referencing a different physical name:

```
ScanProject[table = delta_prod:base.transactions_0002]
```

Notice the `_0002` suffix on the physical table — that is the name you must use in the size query (drop the `delta_prod:` catalog prefix):

```sql theme={null}
SELECT
    size_bytes,
    size_bytes / 1000.0 / 1000 / 1000 AS source_size_gb,
    size_bytes / 1000.0 / 1000 / 1000 / 1000 AS source_size_tb
FROM base."transactions_0002$size";
```

<Tip>
  After confirming the source-size estimate is acceptable, run a one-off sync with `dry_run: true` (see [Manual Syncs](#manual-syncs)) to preview the generated SQL before enabling the post-hook in production.
</Tip>

## Configure A Model

Enable datashare in `meta.datashare` on a `table` or `incremental` model:

```sql theme={null}
{% set time_start = "current_date - interval '1' day" if is_incremental() else "current_date - interval '2' day" %}
{% set time_end = "current_date + interval '1' day" %}

{{ config(
    materialized = 'incremental',
    incremental_strategy = 'merge',
    unique_key = ['block_number', 'block_date'],
    meta = {
        "datashare": {
            "enabled": true,
            "time_column": "block_date",
            "time_start": time_start,
            "time_end": time_end,
            "target_type": "snowflake",
            "target_region": "us"
        }
    }
) }}

select ...
```

## Configuration Fields

| Field                | Required | Description                                                                                                                                    |
| -------------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| `enabled`            | Yes      | Must be `true` to trigger a sync.                                                                                                              |
| `time_column`        | Yes      | Column used by the sync window.                                                                                                                |
| `time_start`         | Yes      | SQL expression for the start of the window.                                                                                                    |
| `time_end`           | No       | SQL expression for the end of the window. Defaults to `now()`.                                                                                 |
| `unique_key_columns` | No       | Unique row identity columns. Falls back to the model `unique_key`.                                                                             |
| `target_type`        | Yes      | Datashare target platform where the synced table is delivered. One of `snowflake` or `bigquery`. Must match a target configured for your team. |
| `target_region`      | Yes      | Region of the target warehouse to sync into (for example, `us` or `eu`). Must match a region configured for your team's datashare target.      |

Keep `time_column`, `time_start`, and `time_end` at the same granularity. For example, if `time_column` is a `date`, use date-based expressions rather than hour-based timestamp windows.

## Full Refresh Behavior

The sync uses `full_refresh = true` when:

* the model is materialized as a `table`
* the incremental model is running for the first time
* the model is run with `--full-refresh`

Normal incremental runs use `full_refresh = false`.

## Manual Syncs

You can trigger a sync manually with `dbt run-operation`:

```bash theme={null}
uv run dbt run-operation datashare_trigger_sync_operation --target prod --args '
model_selector: my_model
dry_run: true
'
```

This is useful for previewing the generated SQL or running one-off syncs outside a normal `dbt run`.

## Monitor Syncs

```sql theme={null}
SELECT *
FROM dune.datashare.table_syncs
WHERE source_schema = 'your_team';

SELECT *
FROM dune.datashare.table_sync_runs
WHERE source_schema = 'your_team'
ORDER BY created_at DESC;
```

Use `table_syncs` for the current registration state and `table_sync_runs` for execution history.

## Remove A Table From Datashare

```sql theme={null}
ALTER TABLE dune.your_team.my_table EXECUTE delete_datashare
```

## Reference

* [Supported SQL Operations](/api-reference/connectors/sql-operations)
* [dbt Connector Overview](/api-reference/connectors/dbt/overview)
* [Datashare Overview](/datashare/datashare)


# Getting Started
Source: https://docs.dune.com/api-reference/connectors/dbt/getting-started

Set up your dbt project and connect to Dune

The fastest way to get started is using our [dbt template repository](https://github.com/duneanalytics/dune-dbt-template), which includes pre-configured profiles, sample models, and CI/CD workflows.

## Prerequisites

* **Dune Enterprise account** with Data Transformations enabled
* **Dune API key** ([generate one here](https://dune.com/settings/api))
* **Team name** on Dune (defines your namespace)
* **dbt installed locally** (we recommend using `uv` for dependency management)

## 1. Use the Template Repository

We provide a complete dbt project template to get started quickly:

**GitHub Template**: [github.com/duneanalytics/dune-dbt-template](https://github.com/duneanalytics/dune-dbt-template)

The template includes:

* Pre-configured dbt profiles for dev and prod environments
* Sample models demonstrating all model types
* GitHub Actions workflows for CI/CD
* Cursor AI rules for dbt best practices on Dune
* Example project structure following dbt conventions

<Note>
  **CI Workflows Are Disabled by Default**

  The template repository ships with GitHub Actions CI workflows **disabled by default**. Since each dbt execution consumes Dune credits, we recommend:

  1. Running models locally first to get familiar with your pipeline
  2. Reviewing the [Pricing & Best Practices](/api-reference/connectors/dbt/pricing-best-practices) guide
  3. Enabling workflows when you're ready by uncommenting triggers in the workflow files (see the [template README](https://github.com/duneanalytics/dune-dbt-template#-note-) for instructions)
</Note>

**To use the template:**

```bash theme={null}
# Create a new repository from the template
# (Use GitHub's "Use this template" button)

# Clone your new repository
git clone https://github.com/your-org/your-dbt-project.git
cd your-dbt-project

# Install dependencies
uv sync

# Set up environment variables (see next section)
```

## 2. Configure Environment Variables

Set these required environment variables:

```bash theme={null}
# Required
export DUNE_API_KEY="your_api_key_here"
export DUNE_TEAM_NAME="your_team_name"

# Optional - for personal dev environments
export DEV_SCHEMA_SUFFIX="alice"
```

**Persistence options:**

```bash theme={null}
# Option 1: Add to shell profile (recommended for local dev)
echo 'export DUNE_API_KEY="your_key"' >> ~/.zshrc
echo 'export DUNE_TEAM_NAME="your_team"' >> ~/.zshrc
source ~/.zshrc

# Option 2: Use a .env file (remember to add to .gitignore!)
# Option 3: Set in CI/CD secrets for production deployments
```

## 3. Configure dbt Profile

Your `profiles.yml` should look like this:

```yaml theme={null}
dune:
  outputs:
    dev:
      type: trino
      method: jwt
      user: "{{ env_var('DUNE_TEAM_NAME') }}"
      jwt_token: "{{ env_var('DUNE_API_KEY') }}"
      host: trino.api.dune.com
      port: 443
      database: dune
      schema: "{{ env_var('DUNE_TEAM_NAME') }}__tmp_{{ env_var('DEV_SCHEMA_SUFFIX', '') }}"
      http_scheme: https
      session_properties:
        transformations: true
    
    prod:
      type: trino
      method: jwt
      user: "{{ env_var('DUNE_TEAM_NAME') }}"
      jwt_token: "{{ env_var('DUNE_API_KEY') }}"
      host: trino.api.dune.com
      port: 443
      database: dune
      schema: "{{ env_var('DUNE_TEAM_NAME') }}"
      http_scheme: https
      session_properties:
        transformations: true

  target: dev
```

<Note>
  The `transformations: true` session property is **required**. This tells Dune that you're running data transformation operations that need write access.
</Note>

## 4. Test Your Connection

```bash theme={null}
# Install dbt dependencies
uv run dbt deps

# Test connection
uv run dbt debug

# Run your first model
uv run dbt run

# Run tests
uv run dbt test
```

## Project Structure

The template repository follows standard dbt conventions:

```
your-dbt-project/
├── models/
│   ├── templates/          # Example models for each strategy
│   │   ├── dbt_template_view_model.sql
│   │   ├── dbt_template_table_model.sql
│   │   ├── dbt_template_merge_incremental_model.sql
│   │   ├── dbt_template_delete_insert_incremental_model.sql
│   │   └── dbt_template_append_incremental_model.sql
│   └── your_models/        # Your transformation models
├── macros/
│   └── dune_dbt_overrides/
│       └── get_custom_schema.sql  # Schema naming logic
├── tests/                  # Custom data tests
├── seeds/                  # CSV seed files
├── snapshots/              # Snapshot definitions
├── analyses/               # Ad-hoc analyses
├── .github/workflows/      # CI/CD workflows (disabled by default—see note above)
├── profiles.yml            # dbt connection profile
├── dbt_project.yml         # Project configuration
└── README.md
```

## Schema Organization

Schemas are automatically organized based on your dbt target:

| Target | DEV\_SCHEMA\_SUFFIX | Schema Name         | Use Case                    |
| ------ | ------------------- | ------------------- | --------------------------- |
| `dev`  | Not set             | `{team}__tmp_`      | Local development (default) |
| `dev`  | Set to `alice`      | `{team}__tmp_alice` | Personal dev space          |
| `dev`  | Set to `pr123`      | `{team}__tmp_pr123` | CI/CD per PR                |
| `prod` | (any)               | `{team}`            | Production tables           |

This is controlled by the `get_custom_schema.sql` macro in the template.

## How It Works

### Namespace Isolation

All tables and views you create are organized into your team's namespace:

* **Production schema**: `{your_team}` - For production tables
* **Development schemas**: `{your_team}__tmp_*` - For development and testing

This ensures complete isolation between teams and between development/production environments.

### Write Operations

Execute SQL statements to create and manage your data:

1. **Create tables and views** in your namespace
2. **Insert, update, or merge** data using standard SQL
3. **Drop tables** when no longer needed
4. **Optimize and vacuum** tables for optimal performance when querying these tables

All operations are authenticated via your Dune API key and restricted to your team's namespace.

### Data Access

**What You Can Read:**

* **All public Dune datasets**: Full access to blockchain data across all supported chains
* **Your uploaded data**: Private datasets you've uploaded to Dune
* **Your transformation outputs**: Tables and views created in your namespace
* **Materialized views**: Views that are materialized as tables in your namespace via the APP

**What You Can Write:**

* **Your team namespace**: `{team_name}` for production tables
* **Development namespaces**: `{team_name}__tmp_*` for dev and testing
* **Private by default**: All created tables are private unless explicitly made public

**Access Control:**

* Write operations are restricted to your team's namespaces only
* Cannot write to public schemas or other teams' namespaces
* Schema naming rules enforced: no `__tmp_` in team handles

## Querying dbt Models on Dune

<Warning>
  When querying your dbt models in the Dune app or via the API, you **must** use the `dune.` catalog prefix.
</Warning>

**Pattern**: `dune.{schema}.{table}`

```sql theme={null}
-- ❌ Won't work (dbt logs show this but it won't work on Dune)
SELECT * FROM my_team.my_model

-- ✅ Correct
SELECT * FROM dune.my_team.my_model
SELECT * FROM dune.my_team__tmp_alice.dev_model
```

dbt logs omit the catalog name for readability, so remember to add `dune.` when using queries in the Dune app.

## Where Your Data Appears

Tables and views created through dbt appear in the **Data Explorer** under:

**My Data → Connectors**

<img alt="Data Transformations in Data Explorer under Connectors" />

You can:

* Browse your transformation datasets
* View table schemas and metadata
* Delete datasets directly from the UI
* Search and reference them in queries

## Next Steps

<CardGroup>
  <Card title="Incremental Models" icon="layer-group" href="/api-reference/connectors/dbt/incremental-models">
    Learn about merge, delete+insert, and append strategies
  </Card>

  <Card title="CI/CD & Workflows" icon="code-branch" href="/api-reference/connectors/dbt/cicd-workflows">
    Set up GitHub Actions and development workflows
  </Card>
</CardGroup>


# Incremental Models
Source: https://docs.dune.com/api-reference/connectors/dbt/incremental-models

Efficiently update large tables with merge, delete+insert, and append strategies

dbt supports multiple strategies for incremental models. The template includes examples of each strategy to help you get started.

## 1. Merge Strategy (Recommended)

**When to use**: When you need to update existing rows and insert new ones.

**Example**:

```sql theme={null}
{{
    config(
        materialized='incremental',
        unique_key='user_address',
        incremental_strategy='merge'
    )
}}

SELECT
    user_address,
    COUNT(*) as trade_count,
    SUM(volume_usd) as total_volume,
    MAX(block_time) as last_trade_time
FROM {{ source('ethereum', 'dex_trades') }}
WHERE block_time >= date_trunc('day', now() - interval '1' day)
{% if is_incremental() %}
    AND block_time >= (SELECT MAX(last_trade_time) FROM {{ this }})
{% endif %}
GROUP BY 1
```

## 2. Delete+Insert Strategy

**When to use**: When recomputing entire partitions (e.g., daily aggregations).

**Example**:

```sql theme={null}
{{
    config(
        materialized='incremental',
        unique_key='date',
        incremental_strategy='delete+insert'
    )
}}

SELECT
    date_trunc('day', block_time) as date,
    protocol,
    COUNT(*) as transaction_count,
    SUM(amount_usd) as volume
FROM {{ source('ethereum', 'decoded_events') }}
WHERE block_time >= date_trunc('day', now() - interval '7' day)
{% if is_incremental() %}
    AND date_trunc('day', block_time) >= date_trunc('day', now() - interval '1' day)
{% endif %}
GROUP BY 1, 2
```

## 3. Append Strategy

**When to use**: For immutable event logs that only need new rows appended.

**Example**:

```sql theme={null}
{{
    config(
        materialized='incremental',
        unique_key='tx_hash',
        incremental_strategy='append'
    )
}}

SELECT
    tx_hash,
    block_time,
    block_number,
    "from" as from_address,
    "to" as to_address,
    value
FROM {{ source('ethereum', 'transactions') }}
WHERE block_time >= date_trunc('hour', now() - interval '1' hour)
{% if is_incremental() %}
    AND block_time >= (SELECT MAX(block_time) FROM {{ this }})
{% endif %}
```

## Strategy Comparison

| Strategy          | Best For                               | How It Works                                           |
| ----------------- | -------------------------------------- | ------------------------------------------------------ |
| **Merge**         | Updating existing rows + inserting new | Matches on `unique_key`, updates existing, inserts new |
| **Delete+Insert** | Recomputing partitions                 | Deletes matching rows, then inserts new data           |
| **Append**        | Immutable event logs                   | Only inserts new rows, no updates or deletes           |

## Table Maintenance

Maintenance operations consume credits based on compute and data written. These operations are necessary to keep your tables performant and to reclaim storage space.

### Manual Maintenance

Run OPTIMIZE and VACUUM to improve performance and reduce storage costs:

```bash theme={null}
# Optimize a specific table
uv run dbt run-operation optimize_table --args '{table_name: "my_model"}'

# Vacuum a specific table
uv run dbt run-operation vacuum_table --args '{table_name: "my_model"}'
```

### Automated Maintenance with dbt post-hooks

Add post-hooks to your model configuration:

```sql theme={null}
{{
    config(
        materialized='incremental',
        post_hook=[
            "ALTER TABLE {{ this }} EXECUTE OPTIMIZE",
            "ALTER TABLE {{ this }} EXECUTE VACUUM"
        ]
    )
}}

SELECT ...
```

### Project level post-hooks

Add post-hooks to your project configuration:

```yaml theme={null}
# dbt_project.yml
post-hooks:
  - "ALTER TABLE {{ this }} EXECUTE OPTIMIZE"
  - "ALTER TABLE {{ this }} EXECUTE VACUUM"
```

The [template repository](https://github.com/duneanalytics/dune-dbt-template) includes a default post-hook that runs OPTIMIZE and VACUUM on all tables.

## Dropping Tables

dbt doesn't have a built-in way to drop tables. Options:

### Option 1: Use dbt's --full-refresh flag then remove the model

```bash theme={null}
# This will drop and recreate
uv run dbt run --select my_model --full-refresh

# Then delete the model file and run again
rm models/my_model.sql
uv run dbt run
```

### Option 2: Connect with a SQL client

Use any Trino-compatible client (Hex, Jupyter, DBeaver) to execute:

```sql theme={null}
DROP TABLE IF EXISTS dune.your_team.old_model;
```

See the [SQL Operations Reference](/api-reference/connectors/sql-operations) for details.

## Examples

Complete examples are available in the template repository:

* **View Model**: Lightweight, always fresh data
* **Table Model**: Static snapshots for specific points in time
* **Merge Incremental**: Update existing rows, insert new ones
* **Delete+Insert Incremental**: Recompute partitions efficiently
* **Append Incremental**: Add-only with deduplication

<Card title="dbt Template Repository" icon="github" href="https://github.com/duneanalytics/dune-dbt-template">
  See all example models in our official dbt template repository
</Card>


# dbt Connector Overview
Source: https://docs.dune.com/api-reference/connectors/dbt/overview

Run production-grade dbt projects directly on Dune with full incremental model support

The dbt Connector enables you to run production-grade dbt projects directly against Dune's data warehouse using the [dbt-trino adapter](https://docs.getdbt.com/docs/core/connect-data-platform/trino-setup). Build, test, and deploy transformation pipelines with full support for incremental models, testing frameworks, and CI/CD orchestration.

This connector provides **write access to DuneSQL** via a Trino API endpoint, enabling you to create, update, and manage tables in your private namespace while reading from Dune's comprehensive blockchain datasets.

Enterprise teams can also use dbt to publish transformed tables from Dune into a configured Datashare target. See [dbt to Datashare](/api-reference/connectors/dbt/datashares).

<Card title="dbt Template Repository" icon="github" href="https://github.com/duneanalytics/dune-dbt-template">
  Get started quickly with our official dbt template repository, featuring example models for all model strategies and CI/CD workflows.
</Card>

<Card title="dbt to Datashare" icon="share-nodes" href="/api-reference/connectors/dbt/datashares">
  Sync dbt-managed tables from your Dune namespace into Snowflake or BigQuery.
</Card>

<Warning>
  The dbt Connector is currently only available to Enterprise customers with Data Transformations enabled.
</Warning>

<Tip>
  Interested in having the dbt Connector enabled for your team? [Contact our team](https://dune.com/enterprise)—please mention the dbt Connector when you reach out.
</Tip>

<Note>
  **Credits & CI/CD**

  Each dbt run consumes Dune credits, including runs triggered by CI/CD pipelines. If you're using GitHub Actions or similar tools, we recommend reviewing [Pricing & Best Practices](/api-reference/connectors/dbt/pricing-best-practices) for optimization tips and [CI/CD & Workflows](/api-reference/connectors/dbt/cicd-workflows) for guidance on configuring triggers.
</Note>

## Video Tutorial

Watch this step-by-step guide to get started with the dbt Connector on Dune:

<iframe title="YouTube video player" />

## What is dbt?

[dbt (data build tool)](https://www.getdbt.com/) is the industry-standard framework for analytics engineering. It enables data teams to transform raw data into analysis-ready datasets using SQL and software engineering best practices.

**Key capabilities:**

* **SQL-based transformations**: Write SELECT statements, dbt handles the DDL/DML
* **Incremental models**: Efficiently update large tables with merge, append, or delete+insert strategies
* **Testing & documentation**: Built-in data quality tests and auto-generated documentation
* **Version control**: Manage transformation logic in Git with code review workflows
* **Dependency management**: Define relationships between models with automatic execution ordering

<Card title="dbt Documentation" icon="book" href="https://docs.getdbt.com/">
  Learn more about dbt's features, best practices, and advanced capabilities in the official dbt documentation.
</Card>

## Why dbt on Dune?

### Enterprise-Grade Transformations

* **Full incremental support**: Use merge, delete+insert, or append strategies for efficient updates
* **Warehouse publishing**: Sync transformation outputs to a configured Datashare target
* **Testing framework**: Validate data quality with dbt's built-in testing capabilities
* **Documentation**: Generate and maintain documentation alongside your transformations
* **Modularity**: Build reusable models and macros for complex transformation logic

### Seamless Integration

* **Drop-in compatibility**: Works with your existing dbt projects and workflows
* **Version control**: Manage transformation logic in Git with PR reviews
* **Production orchestration**: Schedule with GitHub Actions, Airflow, Prefect, or dbt Cloud. See [Pricing & Best Practices](/api-reference/connectors/dbt/pricing-best-practices) for credit optimization tips
* **Private by default**: Keep proprietary transformation logic within your organization

### No Spellbook Dependency

* **Autonomous deployment**: Deploy transformations on your schedule without community review
* **Proprietary logic**: Keep sensitive business logic private
* **Faster iteration**: Test and deploy changes immediately

## Connection Details

Connect to Dune using these parameters:

| Parameter            | Value                                                  |
| -------------------- | ------------------------------------------------------ |
| **Host**             | `trino.api.dune.com`                                   |
| **Port**             | `443`                                                  |
| **Protocol**         | HTTPS                                                  |
| **Catalog**          | `dune` (required)                                      |
| **Authentication**   | JWT (use your Dune API key)                            |
| **Session Property** | `transformations=true` (required for write operations) |

<Warning>
  The session property `transformations=true` is **required** for all write operations. Without it, DDL and DML statements will be rejected.
</Warning>

## Use Cases

### Enterprise Data Pipelines

Add Dune to your existing data infrastructure without reworking your workflows:

* **Drop-in compatibility**: Integrate with your current dbt projects, Airflow DAGs, or Prefect flows
* **Full incremental support**: Use merge, delete+insert, or append strategies for efficient updates
* **Production orchestration**: Schedule with the tools you already use (GitHub Actions, Airflow, Prefect)
* **Version controlled**: Keep all transformation logic in Git alongside your other data pipelines

### Governance & Compliance

Meet enterprise requirements for data control and auditability:

* **Private by default**: All datasets remain private to your team unless explicitly shared
* **Audit trails**: Track every transformation through Git history and PR workflows
* **Data lineage**: Maintain clear lineage from raw data through transformations to analytics
* **Review processes**: Implement PR reviews and approval workflows before deploying to production
* **Access control**: Restrict write access to specific teams and namespaces

### Complex Analytics Workflows

Build sophisticated multi-stage data pipelines:

* Read from Dune's comprehensive blockchain datasets across all chains
* Transform and enrich with your proprietary business logic
* Create reusable intermediate datasets for downstream analytics
* Chain multiple transformations into complex data products

### Alternative to Spellbook

Build and maintain custom datasets without community review processes:

* Deploy transformations on your own schedule
* Keep proprietary logic private to your organization
* Faster iteration cycles without PR review delays

## Next Steps

<CardGroup>
  <Card title="Getting Started" icon="rocket" href="/api-reference/connectors/dbt/getting-started">
    Set up your dbt project and connect to Dune
  </Card>

  <Card title="Incremental Models" icon="layer-group" href="/api-reference/connectors/dbt/incremental-models">
    Learn about merge, delete+insert, and append strategies
  </Card>

  <Card title="dbt to Datashare" icon="share-nodes" href="/api-reference/connectors/dbt/datashares">
    Publish dbt-managed tables to your configured Datashare target
  </Card>

  <Card title="CI/CD & Workflows" icon="code-branch" href="/api-reference/connectors/dbt/cicd-workflows">
    Set up GitHub Actions and development workflows
  </Card>

  <Card title="Pricing & Best Practices" icon="credit-card" href="/api-reference/connectors/dbt/pricing-best-practices">
    Understand credit consumption and optimization tips
  </Card>
</CardGroup>

## SQLMesh Compatibility

<Note>
  [SQLMesh](https://sqlmesh.com/) also works out of the box with Dune using the same Trino connection approach described above. If you prefer SQLMesh over dbt for your data transformation workflows, you can connect it to Dune using the [SQLMesh Trino adapter](https://sqlmesh.readthedocs.io/en/stable/integrations/engines/trino/) with the same connection parameters.

  We plan to release a dedicated SQLMesh template in the future. Until then, follow the same connection setup (host, port, authentication, and session properties) to get started with SQLMesh on Dune.
</Note>


# Pricing & Best Practices
Source: https://docs.dune.com/api-reference/connectors/dbt/pricing-best-practices

Credit consumption, optimization tips, and best practices for dbt on Dune

Data Transformations is an **Enterprise-only feature** with usage-based credit consumption.

<Note>
  **CI/CD and Credit Usage**

  Each dbt execution consumes credits, whether triggered locally, through CI/CD, or on a schedule. The template repository ships with automated CI/CD triggers **disabled by default** so you can enable them when you're ready. See [CI/CD & Workflows](/api-reference/connectors/dbt/cicd-workflows) for tips on managing costs in automated pipelines.
</Note>

## Pricing & Credits

### Credit Consumption

Your credit usage includes three components:

#### Compute Credits

* Same as Fluid Engine credits for query execution
* Charged based on actual compute resources used
* Depends on query complexity and execution time

#### Write Operations

* **Minimum 3 credits** per write operation
* Scales with data volume (GB written)
* Applied to INSERT, MERGE, CREATE TABLE AS SELECT, etc.

#### Storage Credits

* **4 credits per GB per month**
* Calculated based on end-of-day storage usage
* Encourages efficient data management and cleanup

#### Maintenance Operations

* OPTIMIZE, VACUUM, and ANALYZE operations consume credits
* Based on compute resources and data written during maintenance
* Can be automated with dbt post-hooks

<Note>
  There is no separate platform fee. You only pay for what you use through credits. See [Billing](/api-reference/overview/billing) for more details on credit pricing.
</Note>

## Best Practices

### Model Organization

```
models/
├── staging/           # Clean and standardize raw data
├── intermediate/      # Business logic transformations  
├── marts/            # Final datasets for analytics
└── utils/            # Reusable utility models
```

### Schema Organization

* Use `dev` target with personal suffixes during development
* Keep `prod` target for production deployments only
* Consider separate schemas for different projects or domains

### Performance Optimization

* Use incremental models for large datasets
* Partition by date fields when possible
* Add appropriate partitions via dbt configurations
* Run OPTIMIZE and VACUUM on large tables

### Credit Management

* Monitor credit usage in your Dune dashboard
* Use incremental models to reduce compute and write costs
* Drop unused development tables regularly
* Implement table lifecycle policies

### Data Management

* Clean up temporary/test data in `__tmp_` schemas
* Document table retention requirements
* Regularly review and optimize storage usage

### Version Control

* Store all transformation logic in Git
* Use meaningful commit messages
* Tag production releases
* Review PRs before merging to main

### Documentation

```yaml theme={null}
# schema.yml
models:
  - name: user_stats
    description: "Daily user trading statistics"
    columns:
      - name: user_address
        description: "Ethereum address of the user"
        tests:
          - not_null
          - unique
      - name: trade_count
        description: "Number of trades in the period"
```

## Resources

### Documentation

* [dbt Template Repository](https://github.com/duneanalytics/dune-dbt-template)
* [SQL Operations Reference](/api-reference/connectors/sql-operations)
* [Query Engine Overview](/query-engine/overview) - DuneSQL capabilities and read operations
* [Trino Connector](/api-reference/connectors/trino/overview) - General Trino connection guide
* [dbt Documentation](https://docs.getdbt.com/)
* [dbt-trino Setup Guide](https://docs.getdbt.com/docs/core/connect-data-platform/trino-setup)

### Support

* **Dune Discord**: [discord.gg/ErrzwBz](https://discord.gg/ErrzwBz)
* **Enterprise Support**: Contact your account team
* **GitHub Issues**: Report issues in the [template repository](https://github.com/duneanalytics/dune-dbt-template)

## Getting Started

Ready to get started? Clone the [template repository](https://github.com/duneanalytics/dune-dbt-template) and have your first dbt model running on Dune in minutes!

<CardGroup>
  <Card title="dbt Template Repository" icon="github" href="https://github.com/duneanalytics/dune-dbt-template">
    Clone our official template to get started
  </Card>

  <Card title="Getting Started Guide" icon="rocket" href="/api-reference/connectors/dbt/getting-started">
    Step-by-step setup instructions
  </Card>
</CardGroup>


# Supported SQL Operations
Source: https://docs.dune.com/api-reference/connectors/sql-operations

Comprehensive reference of DDL and DML statements supported for data transformations

## Overview

This page documents **write operations** supported via the Data Transformations connector. These operations enable you to create, manage, and manipulate tables and views in your private namespace on Dune.

Both read and write operations use the same Trino endpoint (`trino.api.dune.com`), but write operations require the `transformations=true` session property.

**Standard read operations** (SELECT, JOIN, WHERE, etc.) are documented in the [Query Engine](/query-engine/overview) section and work without any special session properties.

While [dbt](/api-reference/connectors/dbt/overview) is the recommended tool for data transformations, these SQL operations work with any Trino-compatible client including Hex, Jupyter notebooks, SQLMesh, or direct Trino connections.

<Note>
  All write operations require the `transformations=true` session property to be set. Without this property, DDL and DML statements will be rejected.
</Note>

## Prerequisites

* Dune Enterprise account with Data Transformations enabled
* Valid Dune API key with write permissions
* Queries must target the `dune` catalog

## DDL Operations

### Schema Management

Create and manage schemas within your namespace.

#### CREATE SCHEMA

**`CREATE SCHEMA [IF NOT EXISTS] schema_name`**

Create a new schema in your team namespace.

**Examples:**

```sql theme={null}
CREATE SCHEMA IF NOT EXISTS your_team;
CREATE SCHEMA IF NOT EXISTS your_team__tmp_dev;
```

**Access control**: You can only create schemas matching your team handle or temporary schemas with the pattern `{team}__tmp_*`.

#### SHOW SCHEMAS

**`SHOW SCHEMAS [FROM catalog]`**

List all schemas you have access to.

**Example:**

```sql theme={null}
SHOW SCHEMAS FROM dune;
```

**Returns**: All public schemas plus your own schemas.

#### Query Information Schema

**`SELECT ... FROM dune.information_schema.schemata`**

Get detailed schema metadata using information schema queries.

**Example:**

```sql theme={null}
SELECT schema_name, catalog_name
FROM dune.information_schema.schemata
WHERE schema_name LIKE 'your_team%'
ORDER BY schema_name;
```

### Table Management

#### CREATE TABLE

**`CREATE TABLE [IF NOT EXISTS] table_name (column_definitions)`**

Create a new table with explicit column definitions.

**Example:**

```sql theme={null}
CREATE TABLE IF NOT EXISTS your_team.users (
    user_id BIGINT,
    address VARBINARY,
    created_at TIMESTAMP,
    total_volume DOUBLE
);
```

**Supported column types**: All DuneSQL data types including `BIGINT`, `DOUBLE`, `VARCHAR`, `VARBINARY`, `TIMESTAMP`, `BOOLEAN`, `ARRAY`, `MAP`, and custom types like [`UINT256` and `INT256`](https://docs.dune.com/query-engine/datatypes#uint256-dune-sql).

To control whether a table is publicly queryable, see [Table Visibility](#table-visibility).

#### CREATE TABLE AS SELECT (CTAS)

**`CREATE TABLE table_name AS query`**

Create a table from a query result.

**Example:**

```sql theme={null}
CREATE TABLE your_team.daily_volumes AS
SELECT
    DATE_TRUNC('day', block_time) as day,
    COUNT(*) as tx_count,
    SUM(value) as total_volume
FROM ethereum.transactions
WHERE block_time >= NOW() - INTERVAL '7' DAY
GROUP BY 1;
```

#### CREATE OR REPLACE TABLE

**`CREATE OR REPLACE TABLE table_name AS query`**

Create or replace an existing table atomically.

**Example:**

```sql theme={null}
CREATE OR REPLACE TABLE your_team.latest_prices AS
SELECT
    contract_address,
    symbol,
    price_usd,
    MAX(minute) as last_updated
FROM prices.usd
WHERE minute >= NOW() - INTERVAL '1' HOUR
GROUP BY 1, 2, 3;
```

**Note**: This completely replaces the table. For incremental updates, use `MERGE` instead. To control table visibility (public/private), see [Table Visibility](#table-visibility).

#### DROP TABLE

**`DROP TABLE [IF EXISTS] table_name`**

Delete a table and its data.

**Examples:**

```sql theme={null}
DROP TABLE IF EXISTS your_team.old_analysis;
DROP TABLE IF EXISTS your_team__tmp_pr123.test_model;
```

**Access control**: You can only drop tables in your own namespaces.

#### SHOW TABLES

**`SHOW TABLES [FROM schema]`**

List all tables in a schema.

**Examples:**

```sql theme={null}
SHOW TABLES FROM your_team;
SHOW TABLES FROM your_team__tmp_;
```

#### SHOW CREATE TABLE

**`SHOW CREATE TABLE table_name`**

View the DDL for a table.

**Example:**

```sql theme={null}
SHOW CREATE TABLE your_team.users;
```

**Returns**: The full `CREATE TABLE` statement that can recreate the table, including any table properties like visibility settings.

#### Table Visibility

<Note>
  `ALTER TABLE ... SET PROPERTIES` and all other write statements must be run through a Trino-compatible client (CLI, dbt, Hex, Python `trino` package, etc.) connected to `trino.api.dune.com` with `transformations=true` enabled at connection time. They cannot be executed from the Dune web app — attempting to do so returns `Access Denied: Cannot set system session property transformations`. See [Running write statements via the Trino CLI](#running-write-statements-via-the-trino-cli) for a working example.
</Note>

Tables created via Data Transformations are **private by default** -- only your team can query them. You can make a table publicly queryable by anyone on Dune by setting the `dune.public` property.

<Note>
  Table visibility only applies to tables, not views.
</Note>

**Set visibility when creating a table:**

```sql theme={null}
-- Create a public table with explicit columns
CREATE TABLE your_team.public_metrics (
    metric_name VARCHAR,
    metric_value DOUBLE,
    updated_at TIMESTAMP
)
WITH (
    extra_properties = map_from_entries(ARRAY[
        ROW('dune.public', 'true')
    ])
);

-- Create a public table from a query
CREATE TABLE your_team.public_metrics
WITH (
    extra_properties = map_from_entries(ARRAY[
        ROW('dune.public', 'true')
    ])
) AS
SELECT
    DATE_TRUNC('day', block_time) as day,
    COUNT(*) as tx_count
FROM ethereum.transactions
WHERE block_time >= NOW() - INTERVAL '7' DAY
GROUP BY 1;
```

**Set visibility with CREATE OR REPLACE TABLE:**

```sql theme={null}
CREATE OR REPLACE TABLE your_team.public_metrics
WITH (
    extra_properties = map_from_entries(ARRAY[
        ROW('dune.public', 'true')
    ])
) AS
SELECT
    DATE_TRUNC('day', block_time) as day,
    COUNT(*) as tx_count
FROM ethereum.transactions
WHERE block_time >= NOW() - INTERVAL '7' DAY
GROUP BY 1;
```

When using `CREATE OR REPLACE TABLE`:

* If the table **already exists** and you omit `dune.public`, the existing visibility setting is preserved.
* If the table **does not exist** and you omit `dune.public`, it defaults to private.

**Change visibility on an existing table:**

```sql theme={null}
-- Make a table public
ALTER TABLE dune.your_team.my_table
SET PROPERTIES extra_properties = map_from_entries(ARRAY[
    ROW('dune.public', 'true')
]);

-- Make a table private again
ALTER TABLE dune.your_team.my_table
SET PROPERTIES extra_properties = map_from_entries(ARRAY[
    ROW('dune.public', 'false')
]);
```

**Check the current visibility setting:**

```sql theme={null}
-- Method 1: View the full CREATE TABLE statement
SHOW CREATE TABLE dune.your_team.my_table;

-- Method 2: Query table properties directly
SELECT * FROM dune.your_team."my_table$properties";
```

<Tip>
  Public tables are queryable by anyone on Dune and appear in the data explorer under community data.
</Tip>

### View Management

#### CREATE OR REPLACE VIEW

**`CREATE OR REPLACE VIEW view_name AS query`**

Create or update a view definition.

**Example:**

```sql theme={null}
CREATE OR REPLACE VIEW your_team.active_traders AS
SELECT
    trader_address,
    COUNT(*) as trade_count,
    SUM(amount_usd) as total_volume
FROM your_team.dex_trades
WHERE block_time >= NOW() - INTERVAL '30' DAY
GROUP BY 1
HAVING COUNT(*) >= 10;
```

**Benefits**: Views don't store data, so they don't consume storage credits. They're computed on-the-fly when queried.

#### DROP VIEW

**`DROP VIEW [IF EXISTS] view_name`**

Delete a view definition.

**Example:**

```sql theme={null}
DROP VIEW IF EXISTS your_team.old_view;
```

#### SHOW CREATE VIEW

**`SHOW CREATE VIEW view_name`**

View the SQL definition of a view.

**Example:**

```sql theme={null}
SHOW CREATE VIEW your_team.active_traders;
```

### Column Operations

#### SHOW COLUMNS

**`SHOW COLUMNS FROM table_name`**

List all columns in a table.

**Example:**

```sql theme={null}
SHOW COLUMNS FROM your_team.users;
```

#### DESCRIBE

**`DESCRIBE table_name`**

Get detailed column information including names, types, and metadata.

**Example:**

```sql theme={null}
DESCRIBE your_team.users;
```

**Returns**: Column names, data types, nullability, and additional metadata.

#### Query Information Schema for Columns

**`SELECT ... FROM dune.information_schema.columns`**

Get detailed column metadata using information schema queries.

**Example:**

```sql theme={null}
SELECT
    table_schema,
    table_name,
    column_name,
    data_type,
    is_nullable
FROM dune.information_schema.columns
WHERE table_schema = 'your_team'
    AND table_name = 'users'
ORDER BY ordinal_position;
```

## DML Operations

### Insert Operations

#### INSERT INTO with VALUES

**`INSERT INTO table_name (columns) VALUES (values)`**

Insert specific rows into a table.

**Example:**

```sql theme={null}
INSERT INTO your_team.config (key, value, updated_at)
VALUES
    ('max_slippage', '0.5', NOW()),
    ('min_liquidity', '1000', NOW());
```

#### INSERT INTO with SELECT

**`INSERT INTO table_name SELECT ...`**

Insert query results into a table.

**Example:**

```sql theme={null}
INSERT INTO your_team.daily_aggregates
SELECT
    DATE_TRUNC('day', block_time) as day,
    protocol,
    COUNT(*) as transaction_count,
    SUM(amount_usd) as volume_usd
FROM your_team.decoded_events
WHERE block_time >= CURRENT_DATE
GROUP BY 1, 2;
```

**Use case**: Append-only incremental models, historical snapshots, event logging.

### Update Operations

#### MERGE INTO

**`MERGE INTO target USING source ON condition WHEN MATCHED THEN UPDATE ... WHEN NOT MATCHED THEN INSERT ...`**

Upsert data - update existing rows and insert new ones in a single operation.

**Example:**

```sql theme={null}
MERGE INTO your_team.user_stats t
USING (
    SELECT
        user_address,
        COUNT(*) as trade_count,
        SUM(volume_usd) as total_volume,
        MAX(block_time) as last_trade
    FROM ethereum.dex_trades
    WHERE block_time >= CURRENT_DATE - INTERVAL '1' DAY
    GROUP BY 1
) s
ON t.user_address = s.user_address
WHEN MATCHED THEN
    UPDATE SET
        trade_count = t.trade_count + s.trade_count,
        total_volume = t.total_volume + s.total_volume,
        last_trade = GREATEST(t.last_trade, s.last_trade)
WHEN NOT MATCHED THEN
    INSERT (user_address, trade_count, total_volume, last_trade)
    VALUES (s.user_address, s.trade_count, s.total_volume, s.last_trade);
```

**Use case**: Incremental models that update existing records and insert new ones (dbt merge strategy).

**Performance**: More efficient than delete+insert for partial updates of large tables.

### Delete Operations

#### DELETE FROM

**`DELETE FROM table_name WHERE condition`**

Delete rows matching a condition.

**Example:**

```sql theme={null}
DELETE FROM your_team.staging_data
WHERE created_at < NOW() - INTERVAL '7' DAY;
```

#### TRUNCATE TABLE

**`TRUNCATE TABLE table_name`**

Remove all rows from a table efficiently.

**Example:**

```sql theme={null}
TRUNCATE TABLE your_team.temp_calculations;
```

**Performance**: `TRUNCATE` is faster than `DELETE FROM table` for removing all rows as it doesn't scan individual rows.

## Maintenance Operations

These operations optimize table performance and manage metadata. They consume credits based on compute and data written.

### OPTIMIZE

**`ALTER TABLE table_name EXECUTE OPTIMIZE`**

Compact small files and optimize table layout for better query performance.

**Example:**

```sql theme={null}
ALTER TABLE your_team.large_dataset EXECUTE OPTIMIZE;
```

**When to use**:

* After many small writes
* Before running complex queries
* Periodically for frequently-updated tables

**Effect**: Combines small data files into larger ones, improving query performance by reducing file overhead.

### VACUUM

**`ALTER TABLE table_name EXECUTE VACUUM`**

Remove old data files and reclaim storage space.

**Example:**

```sql theme={null}
ALTER TABLE your_team.historical_data EXECUTE VACUUM;
```

**When to use**:

* After major updates or deletes
* To reclaim storage space
* Based on your retention policies

**Effect**: Removes old file versions that are no longer needed, reducing storage costs.

<Tip>
  VACUUM is most effective when run after OPTIMIZE, as it can remove the redundant small files replaced during compaction.
</Tip>

### Automating Maintenance in dbt

Use dbt post-hooks to automate maintenance:

```yaml theme={null}
models:
  your_project:
    large_model:
      +post-hook:
        - "ALTER TABLE {{ this }} EXECUTE OPTIMIZE"
        - "ALTER TABLE {{ this }} EXECUTE VACUUM"
```

## Datashare Operations

These table procedures register a table for Datashare sync and manage its lifecycle.

<Warning>
  These operations require Datashare to be enabled and configured for your team. They are intended for tables in your production namespace, not temporary dev or PR schemas.
</Warning>

### Register Or Trigger A Datashare Sync

**`ALTER TABLE table_name EXECUTE datashare(...)`**

Register a table for Datashare and trigger a sync to your configured target.

**Example:**

```sql theme={null}
ALTER TABLE dune.your_team.daily_metrics EXECUTE datashare(
    time_column => 'block_date',
    unique_key_columns => ARRAY['block_number', 'block_date'],
    time_start => CAST(current_date - interval '1' day AS VARCHAR),
    time_end => CAST(current_date + interval '1' day AS VARCHAR),
    full_refresh => false
);
```

**Arguments:**

* `time_column`: Column used to define the sync window
* `unique_key_columns`: Columns that uniquely identify a row
* `time_start`: SQL expression for the start of the sync window
* `time_end`: SQL expression for the end of the sync window
* `full_refresh`: Whether the sync should rebuild the full exported table

Keep the window expressions aligned with the `time_column` granularity. For example, date columns should use date-based window expressions.

### Remove A Table From Datashare

**`ALTER TABLE table_name EXECUTE delete_datashare`**

Stop syncing a table to Datashare.

**Example:**

```sql theme={null}
ALTER TABLE dune.your_team.daily_metrics EXECUTE delete_datashare;
```

### Monitor Datashare State

Use the Datashare system tables to inspect registrations and sync history:

```sql theme={null}
SELECT *
FROM dune.datashare.table_syncs
WHERE source_schema = 'your_team';

SELECT *
FROM dune.datashare.table_sync_runs
WHERE source_schema = 'your_team'
ORDER BY created_at DESC;
```

For dbt-specific setup, see [dbt to Datashare](/api-reference/connectors/dbt/datashares).

## Information Schema Queries

Query metadata about your tables and schemas.

### List All Tables

```sql theme={null}
SELECT
    table_schema,
    table_name,
    table_type
FROM dune.information_schema.tables
WHERE table_schema = 'your_team'
ORDER BY table_name;
```

### Find Tables by Pattern

```sql theme={null}
SELECT
    table_schema,
    table_name
FROM dune.information_schema.tables
WHERE table_schema LIKE 'your_team%'
    AND table_name LIKE 'user_%'
ORDER BY table_schema, table_name;
```

### Get Table Column Details

```sql theme={null}
SELECT
    column_name,
    data_type,
    is_nullable,
    ordinal_position
FROM dune.information_schema.columns
WHERE table_schema = 'your_team'
    AND table_name = 'users'
ORDER BY ordinal_position;
```

### Check Table Existence

```sql theme={null}
SELECT COUNT(*) > 0 as table_exists
FROM dune.information_schema.tables
WHERE table_schema = 'your_team'
    AND table_name = 'my_model';
```

## Permissions & Access Control

### What You Can Do

#### Read Permissions

* All public Dune datasets
* Your team's private uploaded data
* Your transformation tables and views

#### Write Permissions

* Create schemas: `{team_name}` and `{team_name}__tmp_*`
* Create tables/views in your schemas only
* Insert, update, delete data in your tables only
* Drop your own tables and views
* Set [table visibility](#table-visibility) (public/private) on tables you own

### What You Cannot Do

* Write to public schemas (e.g., `ethereum`, `prices`, etc.)
* Write to other teams' namespaces
* Modify tables you don't own

### Schema Naming Rules

Valid namespace patterns:

* `your_team` - Production schema
* `your_team__tmp_` - Default development schema
* `your_team__tmp_alice` - Personal development schema
* `your_team__tmp_pr123` - CI/CD schema for PR #123

Invalid patterns:

* `eth__tmp_` - Cannot use reserved prefixes
* `another_team` - Cannot use other team names
* `public__tmp_` - Cannot use system schemas

## Session Properties

### Required Property

```sql theme={null}
SET SESSION transformations = true;
```

**Purpose**: Enables write operations. Without this, all DDL/DML statements will be rejected.

**How to set**:

* **dbt**: Add to `profiles.yml` under `session_properties`
* **Python**: Set in connection parameters
* **Trino CLI**: Pass `--session=transformations=true` at connection time. See [Running write statements via the Trino CLI](#running-write-statements-via-the-trino-cli).
* **Other Trino clients (Hex, Python `trino`, DBeaver, etc.)**: Set `transformations=true` in the client's session properties at connection time.

### Running write statements via the Trino CLI

Write statements (DDL, DML, `ALTER TABLE ... SET PROPERTIES`) cannot be executed from the Dune web app. They must be run through a Trino-compatible client with the `transformations=true` session property set at connection time.

Here is a working example using the [Trino CLI](https://trino.io/docs/current/client/cli.html) to make a table public:

```bash theme={null}
# Set the API key as an environment variable (do not pass it inline)
export TRINO_PASSWORD=<your-dune-api-key>

trino \
  --server https://trino.api.dune.com \
  --user dune \
  --password \
  --session=transformations=true \
  --execute="ALTER TABLE dune.your_team.your_table SET PROPERTIES extra_properties = map_from_entries(ARRAY[ROW('dune.public','true')])"
```

<Warning>
  The `--password` flag does **not** accept the API key as a value. It tells the CLI to prompt for one interactively. To pass the API key non-interactively, set the `TRINO_PASSWORD` environment variable as shown above.
</Warning>

<Warning>
  The `--session` value must not contain whitespace. Writing `--session='transformations=true '` (with a trailing space) will fail with `Session property value contains spaces or is not ASCII`. Use `--session=transformations=true` exactly.
</Warning>

For dbt, set the session property in `profiles.yml` under `session_properties` — see the [dbt Getting Started](/api-reference/connectors/dbt/getting-started) guide.

### Optional Properties

#### Join Distribution Type

Optimize join performance:

```sql theme={null}
SET SESSION join_distribution_type = 'PARTITIONED';
```

**Options**:

* `AUTOMATIC` (default) - Let Trino choose
* `PARTITIONED` - Repartition both tables
* `BROADCAST` - Broadcast smaller table

**When to use**: For complex joins on large tables.

## Common Patterns

### Incremental Model Pattern (Merge)

```sql theme={null}
-- Check if target table exists
CREATE TABLE IF NOT EXISTS your_team.user_daily_stats (
    date DATE,
    user_address VARBINARY,
    tx_count BIGINT,
    volume_usd DOUBLE,
    PRIMARY KEY (date, user_address)
);

-- Merge new data
MERGE INTO your_team.user_daily_stats t
USING (
    SELECT
        DATE_TRUNC('day', block_time) as date,
        "from" as user_address,
        COUNT(*) as tx_count,
        SUM(value) as volume_usd
    FROM ethereum.transactions
    WHERE block_time >= CURRENT_DATE - INTERVAL '1' DAY
    GROUP BY 1, 2
) s
ON t.date = s.date AND t.user_address = s.user_address
WHEN MATCHED THEN
    UPDATE SET
        tx_count = s.tx_count,
        volume_usd = s.volume_usd
WHEN NOT MATCHED THEN
    INSERT (date, user_address, tx_count, volume_usd)
    VALUES (s.date, s.user_address, s.tx_count, s.volume_usd);
```

### Delete+Insert Pattern

```sql theme={null}
-- Delete existing data for update period
DELETE FROM your_team.hourly_metrics
WHERE hour >= DATE_TRUNC('hour', NOW() - INTERVAL '24' HOUR);

-- Insert fresh data
INSERT INTO your_team.hourly_metrics
SELECT
    DATE_TRUNC('hour', block_time) as hour,
    protocol,
    COUNT(*) as event_count,
    SUM(amount_usd) as total_volume
FROM your_team.decoded_events
WHERE block_time >= DATE_TRUNC('hour', NOW() - INTERVAL '24' HOUR)
GROUP BY 1, 2;
```

### Append-Only Pattern with Deduplication

```sql theme={null}
-- Insert new records only
INSERT INTO your_team.event_log
SELECT DISTINCT
    evt_tx_hash,
    evt_block_time,
    evt_block_number,
    user_address,
    action_type
FROM ethereum.decoded_events
WHERE evt_block_time >= (
    SELECT COALESCE(MAX(evt_block_time), TIMESTAMP '2020-01-01')
    FROM your_team.event_log
)
AND NOT EXISTS (
    SELECT 1
    FROM your_team.event_log existing
    WHERE existing.evt_tx_hash = ethereum.decoded_events.evt_tx_hash
);
```

### Staging Table Pattern

```sql theme={null}
-- Create staging table
CREATE TABLE your_team__tmp_.staging_new_users AS
SELECT
    user_id,
    address,
    first_seen,
    tx_count
FROM your_source.raw_users
WHERE created_at >= CURRENT_DATE;

-- Validate staging data
SELECT
    COUNT(*) as total_rows,
    COUNT(DISTINCT user_id) as unique_users,
    COUNT(*) FILTER (WHERE address IS NULL) as null_addresses
FROM your_team__tmp_.staging_new_users;

-- Promote to production
INSERT INTO your_team.users
SELECT * FROM your_team__tmp_.staging_new_users;

-- Clean up staging
DROP TABLE your_team__tmp_.staging_new_users;
```

## Best Practices

### Use Appropriate Incremental Strategy

* **Merge**: When you need to update existing rows (e.g., daily aggregations)
* **Delete+Insert**: When recomputing entire partitions (e.g., hourly metrics)
* **Append**: For immutable event logs

### Optimize Write Operations

* Batch inserts instead of single-row inserts
* Use CTAS for bulk table creation
* Partition large tables by date for efficient updates

### Manage Table Lifecycle

* Drop temporary tables in `__tmp_` schemas regularly
* Use views for derived data that doesn't need persistence
* Run OPTIMIZE periodically on frequently-updated tables

### Monitor Credit Usage

* Track write operations in large tables
* Use incremental models to minimize data written

## Limitations & Considerations

### No ALTER TABLE for Schema Changes

You cannot alter table structure (add, rename, or drop columns) directly. Instead, recreate the table:

```sql theme={null}
-- Create new table with desired schema
CREATE TABLE your_team.users_new AS
SELECT
    user_id,
    address,
    created_at,
    -- Add new columns or modify types
    CAST(total_volume AS DECIMAL(38, 2)) as total_volume_precise
FROM your_team.users;

-- Drop old table
DROP TABLE your_team.users;

-- Rename new table (via re-create)
CREATE TABLE your_team.users AS
SELECT * FROM your_team.users_new;

DROP TABLE your_team.users_new;
```

<Note>
  `ALTER TABLE ... SET PROPERTIES` **is** supported for changing table properties like visibility. See [Table Visibility](#table-visibility).
</Note>

### No SCHEMA DROP

Empty schemas are automatically managed. You cannot explicitly drop schemas.

### Transaction Behavior

Each statement is auto-committed. There is no multi-statement transaction support.

### Concurrent Writes

Writing to the same table from multiple processes simultaneously may cause conflicts. Use:

* Separate staging tables
* Partitioned writes
* Sequential execution

## Troubleshooting

### "Access Denied" Errors

**Problem**: Cannot create table in schema.

**Solution**: Verify you're using the correct team namespace and have Data Transformations enabled.

### "Session Property Required" or "Cannot set system session property transformations" Error

**Problem**: Write operation rejected, or `SET SESSION transformations = true` returns `Access Denied`.

**Solution**: Write statements cannot be run from the Dune web app. Connect via a Trino-compatible client (Trino CLI, dbt, Hex, Python `trino`, etc.) and set `transformations=true` at connection time, not as a runtime `SET SESSION` statement. See [Running write statements via the Trino CLI](#running-write-statements-via-the-trino-cli) for a working example.

### Slow MERGE Operations

**Problem**: MERGE takes too long on large tables.

**Solution**:

* Add filters to reduce rows matched
* Run OPTIMIZE before MERGE
* Consider delete+insert for full partition updates

### Table Not Visible in Dune App

**Problem**: Created table doesn't appear in queries.

**Solution**: Remember to use the `dune.` catalog prefix:

```sql theme={null}
SELECT * FROM dune.your_team.your_table;
```

## Examples

Complete examples and templates are available in the [dune-dbt-template repository](https://github.com/duneanalytics/dune-dbt-template).

See the `/models/templates/` directory for:

* View model example
* Table model example
* Merge incremental model
* Delete+insert incremental model
* Append incremental model with deduplication

## Related Documentation

* [dbt Connector](/api-reference/connectors/dbt/overview)
* [Trino Connector](/api-reference/connectors/trino/overview)
* [Query Engine Overview](/query-engine/overview)
* [DuneSQL Functions & Operators](/query-engine/Functions-and-operators/index)
* [Rate Limits](/api-reference/overview/rate-limits)
* [Billing](/api-reference/overview/billing)


# DBeaver
Source: https://docs.dune.com/api-reference/connectors/trino/dbeaver

Connect Dune to DBeaver for direct SQL access

Follow these steps to connect Dune as a data source in DBeaver.

## Add a Database Connection

<Steps>
  <Step title="Create new connection">
    In DBeaver, click the <b>New Database Connection</b> button. It usually looks like a plug with a plus on it.
  </Step>

  <Step title="Select Trino database">
    You'll be taken to the "Connect to a database" screen. Find and select <b>Trino</b> from the list of accepted databases, then click on it.

    <Frame>
      <img alt="DBeaver step 2: Select Trino from database list" />
    </Frame>
  </Step>

  <Step title="Configure connection details">
    You'll be taken to a screen where you can fill in your connection details. Make sure to click <b>Connect by host</b>, then fill in the connection parameters using the values from the [Connection Parameters](/api-reference/connectors/trino/overview#connection-parameters) section.

    <Frame>
      <img alt="DBeaver step 3: Enter connection details" />
    </Frame>
  </Step>

  <Step title="Finish connection setup">
    Once you have all the details filled out properly, click <b>Finish</b> to create the connection.
  </Step>
</Steps>

## Run a Test Query

After configuring your connection, you can run a query to verify that everything is working.

<Steps>
  <Step title="Open SQL editor">
    Right-click on your Dune database connection and navigate to the <b>SQL Editor</b> section. This will open up a new SQL editor.
  </Step>

  <Step title="Write your SQL query">
    In the SQL editor, you can write all of your Dune-compatible SQL. Paste the example query below into the editor.
  </Step>

  <Step title="Run the script">
    Click the <b>Run</b> button to execute your script. If everything went well, you will see the results displayed in the results panel.

    <Frame>
      <img alt="DBeaver step 5: Run SQL script and view results" />
    </Frame>
  </Step>
</Steps>

You can use this query to test your connection. It fetches the daily transaction count from the last year on Base.

```sql theme={null}
SELECT
  date_trunc('day', block_time) AS time,
  count(*) AS count
FROM base.transactions
WHERE block_time > now() - interval '12' month
GROUP BY 1
ORDER BY 1 DESC
```


# Hex
Source: https://docs.dune.com/api-reference/connectors/trino/hex

Connect Dune to Hex's notebook-native analytics platform

Follow these steps to connect Dune as a data source in your Hex workspace.

## Add the Data Connection

<Steps>
  <Step title="Open Data sources">
    Under Workspace settings, select <b>Data sources</b>.

    <Frame>
      <img alt="Hex step 1: Open Data sources" />
    </Frame>
  </Step>

  <Step title="Add connection and choose Trino">
    Click the green <b>+ Connection</b> button, then select <b>Trino</b> from
    the list of available connections.

    <Frame>
      <img alt="Hex step 2: Add connection and choose Trino" />
    </Frame>
  </Step>

  <Step title="Enter connection details">
    Fill in the form fields using the values from the [Connection Parameters](/api-reference/connectors/trino/overview#connection-parameters) section.

    <Frame>
      <img alt="Hex step 3: Enter connection details" />
    </Frame>
  </Step>
</Steps>

## Run a Test Query

Once your data source is configured, you can query it directly from any Hex project.

<Steps>
  <Step title="Open or create a project">
    Open an existing project or create a new one.
  </Step>

  <Step title="Add a SQL cell">
    Add a new <b>SQL cell</b> to your notebook.
  </Step>

  <Step title="Select data source">
    In the data source dropdown at the top of the cell, select your newly
    created <b>Dune SQL</b> connection.
  </Step>

  <Step title="Paste and run SQL">
    Paste the example query below into the cell and run it.

    <Frame>
      <img alt="Hex step: Paste and run SQL" />
    </Frame>
  </Step>
</Steps>

You can use this query to test your connection. It fetches the daily transaction count from the last year on Base.

```sql theme={null}
SELECT
  date_trunc('day', block_time) AS time,
  count(*) AS count
FROM base.transactions
WHERE block_time > now() - interval '12' month
GROUP BY 1
ORDER BY 1 DESC
```


# Metabase
Source: https://docs.dune.com/api-reference/connectors/trino/metabase

Connect Dune to Metabase for BI dashboards

Follow these steps to connect Dune as a data source in Metabase.

## Add the Database Connection

<Steps>
  <Step title="Open Admin settings">
    From the Metabase home page, click the <b>Settings</b> gear icon in the top-right corner.
    Select <b>Admin settings</b> from the dropdown menu.

    <Frame>
      <img alt="Metabase step 1: Open Admin settings" />
    </Frame>
  </Step>

  <Step title="Go to Databases">
    In the Admin panel, navigate to the <b>Databases</b> tab.

    <Frame>
      <img alt="Metabase step 2: Go to Databases" />
    </Frame>
  </Step>

  <Step title="Add database">
    Click the blue <b>Add database</b> button to open the configuration modal.

    <Frame>
      <img alt="Metabase step 3: Add database" />
    </Frame>
  </Step>

  <Step title="Choose driver">
    In the modal, select <code>Starburst (Trino)</code> as the <b>Database type</b>.
  </Step>

  <Step title="Enter connection details">
    Fill in the form fields using the values from the [Connection Parameters](/api-reference/connectors/trino/overview#connection-parameters) section.
    For best performance in Metabase, we recommend disabling <b>Rerun queries for simple explorations</b> and <b>Periodically refingerprint tables</b> in the advanced settings.
  </Step>
</Steps>

<Note>
  Schema discovery queries such as <code>SHOW TABLES</code> or <code>SHOW SCHEMAS</code> may not be available in Metabase with this connector because Dune's catalog spans millions of tables. Many BI tools are not yet optimized to enumerate catalogs at this scale. An update with improved schema discovery is planned for the future.
</Note>

## Run a Test Query

After configuring and saving the connection, you can run a query to verify that everything is working.

<Steps>
  <Step title="Create a new SQL query">
    Click the <b>+ New</b> button and select <b>SQL query</b>.
  </Step>

  <Step title="Select database">
    In the editor, choose your newly created <b>Dune SQL</b> data source from
    the <b>Select a database</b> dropdown.
  </Step>

  <Step title="Paste example SQL">
    Paste the example query below into the editor.
  </Step>

  <Step title="Run the query">Run the query to verify the connection.</Step>
</Steps>

You can use this query to test your connection. It fetches the daily transaction count from the last year on Base.

```sql theme={null}
SELECT
  date_trunc('day', block_time) AS time,
  count(*) AS count
FROM base.transactions
WHERE block_time > now() - interval '12' month
GROUP BY 1
ORDER BY 1 DESC
```


# Trino Connector Overview
Source: https://docs.dune.com/api-reference/connectors/trino/overview

Access Dune's blockchain data through Trino/Presto-compatible tools and SDKs

Access Dune's blockchain data from your favorite BI tools and clients using the DuneSQL Trino/Presto connector. Connect Dune with popular tools like Hex, Metabase, DBeaver, and any Trino, Presto, or Starburst-compatible application for seamless data analysis.

<Frame>
  <img alt="Dune Trino Presto connector architecture diagram showing integration flow" />

  <img alt="Dune Trino Presto connector architecture diagram showing integration flow" />
</Frame>

<Warning>
  The DuneSQL Trino Connector is currently only available to Plus and Enterprise customers.
</Warning>

## Compatible Tools

Dune's Trino connector supports any tool that works with Trino, Presto, or Starburst connectors. Popular Dune integrations include:

<CardGroup>
  <Card title="Hex" icon="cube" href="/api-reference/connectors/trino/hex">
    Connect Dune to Hex's notebook-native analytics via built-in Trino connector.
  </Card>

  <Card title="Metabase" icon="chart-bar" href="/api-reference/connectors/trino/metabase">
    Integrate Dune with Metabase using the Starburst/Trino driver for BI dashboards.
  </Card>

  <Card title="DBeaver" icon="database" href="/api-reference/connectors/trino/dbeaver">
    Connect Dune to DBeaver using the Trino driver for direct SQL access to blockchain data.
  </Card>

  <Card title="Trino SDKs" icon="plug" href="/api-reference/connectors/trino/sdks">
    Treat Dune like a Database in your language of choice with popular Trino libraries.
  </Card>
</CardGroup>

<Note>
  Any of the supported client applications listed in the [Trino ecosystem](https://trino.io/ecosystem/#official-client-applications) are supported. Please visit their documentation to learn about their specific connection instructions, though the configuration should generally follow the same pattern using the connection parameters below.
</Note>

## Connection Parameters

Use these values in your Trino, Presto, or Starburst client configuration:

| Parameter   | Value                 | Description                                                 |
| ----------- | --------------------- | ----------------------------------------------------------- |
| Host        | `trino.api.dune.com`  | Dune's Trino/Presto endpoint                                |
| Port        | `443`                 | Standard HTTPS port                                         |
| Username    | `dune`                | Fixed username for all connections                          |
| Password    | `<your-dune-api-key>` | [Your Dune API key](/api-reference/overview/authentication) |
| Catalog     | `delta_prod`          | Main data catalog                                           |
| SSL/TLS     | `true`                | Always use encrypted connections                            |
| HTTP scheme | `https`               | Required for secure connections                             |

<Note>
  If you need an API key, see our guide on [Authentication](/api-reference/overview/authentication). Remember to keep your API keys secret and rotate them immediately if they are ever exposed.
</Note>

## Supported SQL Operations

Queries executed via the connector align with what you can run on the Dune platform. See the [Query Engine overview](/query-engine/overview) for more information on supported functions and syntax.

## Rate Limits

Rate limits for the connector mirror those of the Dune Data API. Please refer to the [Rate Limits](/api-reference/overview/rate-limits) documentation for details.

## Billing & Cost

All queries run via the connector are executed on the [Large Query Engine](/query-engine/query-executions#query-engine-size). Credits are consumed based on actual compute resources used. In addition, fetching results consumes credits proportional to the number of datapoints returned. For a full breakdown, please see our documentation on [Billing](/api-reference/overview/billing).

## Limitations

The connector currently has limited support for metadata discovery queries such as `SHOW TABLES` or `SHOW SCHEMAS`. This may impact the data source browsing and autocomplete experience within some BI tools.

For schema and table discovery, see the [Data Explorer](/web-app/query-editor/data-explorer) guide. If you encounter timeouts with large result sets, consider paginating your queries using `LIMIT` and `OFFSET`, narrowing your filters, or splitting complex queries into smaller, more manageable parts.


# Trino SDKs
Source: https://docs.dune.com/api-reference/connectors/trino/sdks

Connect to Dune using Trino SDKs in your preferred programming language

Connect to Dune using Trino SDKs in your preferred language. Dune supports any Trino, Presto, or Starburst-compatible client library.

## Code Examples

<Tabs>
  <Tab title="Bash">
    ```bash theme={null}
    # Install: brew install trino
    trino --server https://trino.api.dune.com:443 \
      --user dune --password \
      --catalog delta_prod \
      --schema runtime \
      --execute "SELECT count(*) FROM base.transactions WHERE block_time > now() - interval '1' day"
    ```
  </Tab>

  <Tab title="TypeScript">
    ```typescript theme={null}
    import { Trino, BasicAuth } from "trino-client";

    const trino = Trino.create({
      server: "https://trino.api.dune.com:443",
      catalog: "delta_prod",
      schema: "runtime",
      auth: new BasicAuth("dune", process.env.DUNE_API_KEY),
    });

    const iter = await trino.query("SELECT count(*) FROM base.transactions WHERE block_time > now() - interval '1' day");
    for await (const result of iter) {
      console.log(result.data);
    }
    ```
  </Tab>

  <Tab title="Python">
    ```python theme={null}
    import trino
    import os

    conn = trino.dbapi.connect(
        host='trino.api.dune.com',
        port=443,
        user='dune',
        catalog='delta_prod',
        schema='runtime',
        auth=trino.auth.BasicAuthentication('dune', os.environ['DUNE_API_KEY']),
        http_scheme='https'
    )

    cursor = conn.cursor()
    cursor.execute("SELECT count(*) FROM base.transactions WHERE block_time > now() - interval '1' day")
    print(cursor.fetchall())
    ```
  </Tab>

  <Tab title="Rust">
    ```rust theme={null}
    use prusto::{ClientBuilder, Presto};

    #[derive(Presto, Debug)]
    struct Foo {
        a: i64,
        b: f64,
        c: String,
    }

    #[tokio::main]
    async fn main() {
        let cli = ClientBuilder::new("user", "localhost")
            .port(8090)
            .catalog("catalog")
            .build()
            .unwrap();

        let sql = "select 1 as a, cast(1.1 as double) as b, 'bar' as c ";

        let data = cli.get_all::<Foo>(sql.into()).await.unwrap().into_vec();

        for r in data {
            println!("{:?}", r)
        }
    }
    ```
  </Tab>

  <Tab title="Go">
    ```go theme={null}
    import "database/sql"
    import _ "github.com/trinodb/trino-go-client/trino"

    dsn := "http://user@localhost:8080?catalog=default&schema=test"
    db, err := sql.Open("trino", dsn)
    ```
  </Tab>

  <Tab title="Ruby">
    ```ruby theme={null}
    require 'trino-client'

    # create a client object:
    client = Trino::Client.new(
      server: "localhost:8880",   # required option
      ssl: {verify: false},
      catalog: "native",
      schema: "default",
      user: "frsyuki",
      password: "********",
      time_zone: "US/Pacific",
      language: "English",
      properties: {
        "hive.force_local_scheduling": true,
        "raptor.reader_stream_buffer_size": "32MB"
      },
      http_proxy: "proxy.example.com:8080",
      http_debug: true
    )

    # run a query and get results as an array of arrays:
    columns, rows = client.run("select * from sys.node")
    rows.each {|row|
      p row  # row is an array
    }

    # run a query and get results as an array of hashes:
    results = client.run_with_names("select alpha, 1 AS beta from tablename")
    results.each {|row|
      p row['alpha']   # access by name
      p row['beta']
      p row.values[0]  # access by index
      p row.values[1]
    }

    # run a query and fetch results streamingly:
    client.query("select * from sys.node") do |q|
      # get columns:
      q.columns.each {|column|
        puts "column: #{column.name}.#{column.type}"
      }

      # get query results. it feeds more rows until
      # query execution finishes:
      q.each_row {|row|
        p row  # row is an array
      }
    end

    # killing a query
    query = client.query("select * from sys.node")
    query_id = query.query_info.query_id
    query.each_row {|row| ... }  # when a thread is processing the query,
    client.kill(query_id)  # another thread / process can kill the query.

    # Use Query#transform_row to parse Trino ROW types into Ruby Hashes.
    # You can also set a scalar_parser to parse scalars how you'd like them.
    scalar_parser = -> (data, type) { (type === 'json') ? JSON.parse(data) : data }
    client.query("select * from sys.node") do |q|
      q.scalar_parser = scalar_parser

      # get query results. it feeds more rows until
      # query execution finishes:
      q.each_row {|row|
        p q.transform_row(row)
      }
    end
    ```
  </Tab>
</Tabs>

<Note>
  Besides the code samples shown above, Trino supports a variety of other official and unofficial SDKs. Please check the [official Trino SDKs page](https://trino.io/ecosystem/client-driver#official-client-drivers) to see which ones are available and to view their GitHub repositories for updated code samples and documentation.
</Note>

## Connection Parameters

For all SDK integrations, use the following connection parameters:

| Parameter   | Value                |
| ----------- | -------------------- |
| Host        | `trino.api.dune.com` |
| Port        | `443`                |
| Username    | `dune`               |
| Password    | Your Dune API key    |
| Catalog     | `delta_prod`         |
| HTTP scheme | `https`              |

See the [Overview](/api-reference/connectors/trino/overview#connection-parameters) for complete connection details.


# Get Dataset
Source: https://docs.dune.com/api-reference/datasets/endpoint/get

GET /v1/datasets/{slug}
Retrieve dataset information including columns, metadata, and ownership details

<Info>
  Minimum required API key scope: `Read`
</Info>

<Note>
  * Retrieve detailed information about a specific dataset by its slug - Returns
    complete schema including all columns with data types - Includes ownership
    details and metadata - Example slugs: `dex.trades`, `tokens.erc20`,
    `ethereum.transactions`
</Note>

# Use Cases

* **Schema Discovery**: Retrieve the complete schema of a dataset including column names, data types, and nullability.
* **Table Exploration**: Understand the structure of a dataset before writing queries against it.
* **Data Integration**: Programmatically fetch table schemas for ETL pipelines and data integration tools.
* **Documentation Generation**: Automatically generate documentation for datasets based on their schemas.
* **Validation**: Verify dataset structure and columns before building queries or applications.


# List Datasets
Source: https://docs.dune.com/api-reference/datasets/endpoint/list

GET /v1/datasets
Retrieve a paginated list of datasets with optional filtering by owner and type

<Info>
  Minimum required API key scope: `Read`
</Info>

# Use Cases

* **Browse Available Data**: Programmatically discover all tables and datasets available on Dune for querying.
* **Filter by Owner**: Find all datasets owned by a specific user or team using `owner_handle` parameter.
* **Filter by Type**: Narrow down results to specific dataset types like curated tables, decoded tables, or transformations using the `type` parameter.
* **Build Data Catalogs**: Create custom data discovery tools that index and search through Dune's table ecosystem.
* **Access Management**: Audit and manage datasets owned by your team or organization.


# Search Datasets
Source: https://docs.dune.com/api-reference/datasets/endpoint/search

POST /v1/datasets/search
Search for datasets across the Dune catalog, with filtering by categories, blockchains, schemas, and more

<Info>
  Minimum required API key scope: `Read`
</Info>

# Use Cases

* **Free-Text Search**: Search across Dune's entire dataset catalog using natural language queries like `"dex trades"` or `"ethereum transactions"`.
* **Filter by Category**: Narrow results to specific categories such as `canonical`, `decoded`, `spell`, or `community` datasets.
* **Filter by Blockchain**: Find datasets for specific blockchains by passing blockchain names in the `blockchains` parameter.
* **AI Agents**: Enable AI agents to discover relevant tables and schemas before constructing SQL queries.
* **Build Search UIs**: Power custom dataset search interfaces and data discovery tools on top of Dune's catalog.


# Search Datasets by Contract Address
Source: https://docs.dune.com/api-reference/datasets/endpoint/search-by-contract

POST /v1/datasets/search-by-contract
Find decoded datasets associated with a smart contract address

<Info>
  Minimum required API key scope: `Read`
</Info>

# Use Cases

* **Contract Analysis**: Find all decoded datasets associated with a specific smart contract address.
* **Blockchain Filtering**: Narrow results to decoded tables on specific blockchains using the `blockchains` parameter.
* **Build Contract Explorers**: Power contract exploration tools that surface relevant decoded tables for any contract address.
* **Data Integration**: Programmatically discover decoded event and function tables for a contract to build ETL pipelines.
* **Schema Discovery**: Retrieve the schema of decoded tables for a contract by setting `include_schema` to `true`.


# Overview
Source: https://docs.dune.com/api-reference/datasets/introduction



Leverage Dune's Datasets API for programmatic access to explore all queryable tables on Dune. Discover schemas, metadata, and ownership details without writing SQL—perfect for building data catalogs, discovery tools, and data integration pipelines.

## Use Cases

* **Data Discovery**: Programmatically browse and search through all available datasets on Dune
* **AI Agents**: Allow AI agents to understand the available tables and schemas before constructing the SQL query.
* **Schema Exploration**: Retrieve column names, data types, and metadata for any table
* **Access Management**: Filter datasets by owner to understand team data assets

<CardGroup>
  <Card title="List Datasets" icon="list" href="/api-reference/datasets/endpoint/list">
    Retrieve a paginated list of datasets with optional filtering by owner and
    type.
  </Card>

  <Card title="Get Dataset" icon="table" href="/api-reference/datasets/endpoint/get">
    Get detailed information about a specific dataset including columns and
    metadata.
  </Card>

  <Card title="Search Datasets" icon="magnifying-glass" href="/api-reference/datasets/endpoint/search">
    Search across the dataset catalog with free-text queries and advanced
    filters.
  </Card>

  <Card title="Search by Contract Address" icon="file-contract" href="/api-reference/datasets/endpoint/search-by-contract">
    Find decoded datasets associated with a specific smart contract address.
  </Card>
</CardGroup>

<br />


# Cancel Execution
Source: https://docs.dune.com/api-reference/executions/endpoint/cancel-execution

POST /v1/execution/{execution_id}/cancel
Cancel a triggered execution request given the execution ID

<Info>
  Minimum required API key scope: `Read`
</Info>

You must pass the `execution_id` obtained from making an [execute query](/api-reference/executions/endpoint/execute-query) POST request.

The result returns a boolean for whether the execution is successfully canceled.

<RequestExample>
  ```bash cURL theme={null}

  curl -X POST -H x-dune-api-key:{{api_key}} "https://api.dune.com/api/v1/execution/{{execution_id}}/cancel"

  ```

  ```python Python SDK theme={null}

  '''
  Download Dune Python SDK by running `pip install dune-client`
  For more info, visit the GitHub repository: https://github.com/duneanalytics/dune-client/tree/d2195b2a9577e2dcae5d2600cb3eddce20987f38
  '''

  import json
  from dune_client.types import QueryParameter
  from dune_client.client import DuneClient
  from dune_client.query import QueryBase

  # setup Dune Python client
  dune = DuneClient()

  result = dune.cancel_execution(job_id = '01HM79YYNXADPK66YWZK5X0NXB') # pass in the execution_id

  ```

  ```python Python theme={null}
  import requests

  url = "https://api.dune.com/api/v1/execution/{execution_id}/cancel"

  headers = {"X-DUNE-API-KEY": "<x-dune-api-key>"}

  response = requests.request("POST", url, headers=headers)

  print(response.text)

  ```

  ```javascript Javascript theme={null}
  const options = {method: 'POST', headers: {'X-DUNE-API-KEY': '<x-dune-api-key>'}};

  fetch('https://api.dune.com/api/v1/execution/{execution_id}/cancel', options)
    .then(response => response.json())
    .then(response => console.log(response))
    .catch(err => console.error(err));

  ```

  ```go Go theme={null}
  package main

  import (
  	"fmt"
  	"net/http"
  	"io/ioutil"
  )

  func main() {

  	url := "https://api.dune.com/api/v1/execution/{execution_id}/cancel"

  	req, _ := http.NewRequest("POST", url, nil)

  	req.Header.Add("X-DUNE-API-KEY", "<x-dune-api-key>")

  	res, _ := http.DefaultClient.Do(req)

  	defer res.Body.Close()
  	body, _ := ioutil.ReadAll(res.Body)

  	fmt.Println(res)
  	fmt.Println(string(body))

  }

  ```

  ```php PHP theme={null}
  <?php

  $curl = curl_init();

  curl_setopt_array($curl, [
    CURLOPT_URL => "https://api.dune.com/api/v1/execution/{execution_id}/cancel",
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_ENCODING => "",
    CURLOPT_MAXREDIRS => 10,
    CURLOPT_TIMEOUT => 30,
    CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
    CURLOPT_CUSTOMREQUEST => "POST",
    CURLOPT_HTTPHEADER => [
      "X-DUNE-API-KEY: <x-dune-api-key>"
    ],
  ]);

  $response = curl_exec($curl);
  $err = curl_error($curl);

  curl_close($curl);

  if ($err) {
    echo "cURL Error #:" . $err;
  } else {
    echo $response;
  }

  ```

  ```java Java theme={null}
  HttpResponse<String> response = Unirest.post("https://api.dune.com/api/v1/execution/{execution_id}/cancel")
    .header("X-DUNE-API-KEY", "<x-dune-api-key>")
    .asString();

  ```
</RequestExample>


# Execute Query
Source: https://docs.dune.com/api-reference/executions/endpoint/execute-query

POST /v1/query/{query_id}/execute
Execute, or run a query for the specified query ID

<Info>
  Minimum required API key scope: `Read`
</Info>

<Accordion title="Execute query and get result in one call">
  <Tip> If you are using the [Python SDK](https://github.com/duneanalytics/dune-client/tree/d2195b2a9577e2dcae5d2600cb3eddce20987f38), you can directly execute and fetch result in one function call, like below: </Tip>

  Use `run_query` to get result in JSON,
  `run_query_csv` to get result in CSV format,
  and `run_query_dataframe` to get result in Pandas dataframe

  ```python Python SDK  theme={null}

  import json
  from dune_client.types import QueryParameter
  from dune_client.client import DuneClient
  from dune_client.query import QueryBase

  # setup Dune Python client
  dune = DuneClient()

  query = QueryBase(
      name="Sample Query",
      query_id=1215383,
  )

  result = dune.run_query(
      query = query,
      performance = 'large' # optionally define which tier to run the execution on (default is "medium")
  )

  # go over the results returned
  for row in result.result.rows: 
      print (row) # as an example we print the rows
  ```
</Accordion>

If the query has parameters and you don't add them in your API call, it will just run with the default params. You may add query parameters as part of the POST params data.

You can choose to include a `performance` parameter, by default it will use the "medium" performance tier. Credits are consumed based on actual compute resources used. "large" tier provides more resources for complex queries.

Returns an execution\_id associated with the triggered query execution and the state of the execution.

<RequestExample>
  ```bash cURL theme={null}
  curl -X POST "https://api.dune.com/api/v1/query/{{query_id}}/execute"   \
    -H "X-Dune-API-Key: {{api_key}}"                                       \
    -H "Content-Type: application/json"                                   \
    -d '{"query_parameters": {"param1":24}, "performance": "large"}'
  ```

  ```python Python SDK theme={null}

  '''
  Download Dune Python SDK by running `pip install dune-client`
  For more info, visit the GitHub repository: https://github.com/duneanalytics/dune-client/tree/d2195b2a9577e2dcae5d2600cb3eddce20987f38
  '''

  import json
  from dune_client.types import QueryParameter
  from dune_client.client import DuneClient
  from dune_client.query import QueryBase

  # setup Dune Python client
  dune = DuneClient()

  # define the query to run
  query = QueryBase(
      name="Sample Query",
      query_id=1215383,
      params=[
          QueryParameter.text_type(name="TextField", value="Word"),
          QueryParameter.number_type(name="NumberField", value=3.1415926535),
          QueryParameter.date_type(name="DateField", value="2022-05-04 00:00:00"),
          QueryParameter.enum_type(name="ListField", value="Option 1"),
      ],
  )

  result = dune.execute_query(query = query # pass in the query we just defined
            , performance = "large" # define engine query is run on, default is "medium"
  )

  ```

  ```python Python theme={null}
  import requests

  url = "https://api.dune.com/api/v1/query/{query_id}/execute"

  headers = {"X-DUNE-API-KEY": "<x-dune-api-key>"}

  response = requests.request("POST", url, headers=headers)

  print(response.text)

  ```

  ```javascript Javascript theme={null}
  const options = {method: 'POST', headers: {'X-DUNE-API-KEY': '<x-dune-api-key>'}};

  fetch('https://api.dune.com/api/v1/query/{query_id}/execute', options)
  .then(response => response.json())
  .then(response => console.log(response))
  .catch(err => console.error(err));

  ```

  ```go Go theme={null}
  package main

  import (
      "fmt"
      "net/http"
      "io/ioutil"
  )

  func main() {

      url := "https://api.dune.com/api/v1/query/{query_id}/execute"

      req, _ := http.NewRequest("POST", url, nil)

      req.Header.Add("X-DUNE-API-KEY", "<x-dune-api-key>")

      res, _ := http.DefaultClient.Do(req)

      defer res.Body.Close()
      body, _ := ioutil.ReadAll(res.Body)

      fmt.Println(res)
      fmt.Println(string(body))

  }

  ```

  ```php PHP theme={null}
  <?php

  $curl = curl_init();

  curl_setopt_array($curl, [
  CURLOPT_URL => "https://api.dune.com/api/v1/query/{query_id}/execute",
  CURLOPT_RETURNTRANSFER => true,
  CURLOPT_ENCODING => "",
  CURLOPT_MAXREDIRS => 10,
  CURLOPT_TIMEOUT => 30,
  CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
  CURLOPT_CUSTOMREQUEST => "POST",
  CURLOPT_HTTPHEADER => [
      "X-DUNE-API-KEY: <x-dune-api-key>"
  ],
  ]);

  $response = curl_exec($curl);
  $err = curl_error($curl);

  curl_close($curl);

  if ($err) {
  echo "cURL Error #:" . $err;
  } else {
  echo $response;
  }

  ```

  ```java Java theme={null}
  HttpResponse<String> response = Unirest.post("https://api.dune.com/api/v1/query/{query_id}/execute")
  .header("X-DUNE-API-KEY", "<x-dune-api-key>")
  .asString();
  ```
</RequestExample>


# Execute Query Pipeline
Source: https://docs.dune.com/api-reference/executions/endpoint/execute-query-pipeline

POST /v1/query/{query_id}/pipeline/execute
Builds a query pipeline from the specified query and executes it. A pipeline allows you to chain multiple queries together and execute them as a single unit.

<Info>
  Minimum required API key scope: `Read`
</Info>

This endpoint builds a query pipeline from the specified query and executes it. A pipeline allows you to chain multiple queries together and execute them as a single unit.

## What is a Query Pipeline?

A query pipeline enables you to create a chain of dependencies between queries, where:

* Each query in the pipeline can depend on the results of previous queries
* The pipeline executes queries in the correct order based on their dependencies
* All queries are executed as a single atomic operation

## Use Cases

Query pipelines are ideal for:

* **Complex Data Transformations**: Breaking down complex analysis into smaller, manageable queries
* **Data Lineage**: Maintaining clear dependencies between related queries
* **Coordinated Updates**: Ensuring multiple queries are executed together
* **Incremental Processing**: Building data pipelines where each step depends on the previous one

## Response

The endpoint returns a `pipeline_execution_id` which you can use to:

1. Check the status of the pipeline execution using the [Get Pipeline Execution Status](/api-reference/pipelines/endpoint/get-pipeline-status) endpoint
2. Monitor the progress of individual nodes in the pipeline
3. Retrieve results from each query in the pipeline once execution completes

<Note>
  * Credits are consumed based on actual compute resources used for each query in the pipeline
  * Use the `performance` parameter to specify execution tier (medium or large)
  * Query parameters can be passed to parameterize queries in the pipeline
</Note>

## Example Workflow

```bash theme={null}
# 1. Execute the pipeline
curl -X POST "https://api.dune.com/api/v1/query/1234567/pipeline/execute" \
  -H "X-Dune-Api-Key: YOUR_API_KEY"

# Response: { "pipeline_execution_id": "01HZABC123..." }

# 2. Check pipeline status
curl "https://api.dune.com/api/v1/pipelines/executions/01HZABC123.../status" \
  -H "X-Dune-Api-Key: YOUR_API_KEY"
```

## Related Endpoints

* [Get Query Pipeline](/api-reference/queries/endpoint/get-query-pipeline) - Inspect pipeline structure before execution
* [Get Pipeline Status](/api-reference/pipelines/endpoint/get-pipeline-status) - Check pipeline execution status
* [Execute Pipeline](/api-reference/pipelines/endpoint/execute-pipeline) - Execute a lineage-based pipeline


# Execute SQL
Source: https://docs.dune.com/api-reference/executions/endpoint/execute-sql

POST /v1/sql/execute
Execute raw SQL queries directly without needing to create a saved query first

<Info>
  Minimum required API key scope: `Read`
</Info>

> Run arbitrary SQL queries via API. This endpoint allows you to execute SQL directly without first creating a query object, perfect for dynamic analysis and automated workflows.

<Note>
  When executing arbitrary SQL queries (queries not saved in Dune), the `query_id` in the response will always be `0`. This is a placeholder value since these queries are not stored in the Dune database.
</Note>

## Pricing

This endpoint is **usage-based** and consumes credits based on the computational resources used during execution.

<RequestExample>
  ```bash cURL theme={null}
  curl -X POST "https://api.dune.com/api/v1/sql/execute" \
    -H "Content-Type: application/json" \
    -H "X-Dune-Api-Key: YOUR_API_KEY" \
    -d '{
      "sql": "SELECT * FROM dex.trades WHERE block_time > now() - interval '\''1'\'' day LIMIT 10",
      "performance": "medium"
    }'
  ```

  ```python Python theme={null}
  import requests

  url = "https://api.dune.com/api/v1/sql/execute"
  headers = {
      "X-DUNE-API-KEY": "YOUR_API_KEY",
      "Content-Type": "application/json"
  }
  data = {
      "sql": "SELECT * FROM dex.trades WHERE block_time > now() - interval '1' day LIMIT 10",
      "performance": "medium"
  }

  response = requests.post(url, json=data, headers=headers)
  print(response.json())
  ```

  ```javascript JavaScript theme={null}
  const response = await fetch('https://api.dune.com/api/v1/sql/execute', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'X-DUNE-API-KEY': 'YOUR_API_KEY'
    },
    body: JSON.stringify({
      sql: "SELECT * FROM dex.trades WHERE block_time > now() - interval '1' day LIMIT 10",
      performance: 'medium'
    })
  });

  const data = await response.json();
  console.log(data);
  ```

  ```bash Complete Workflow theme={null}
  # Step 1: Execute SQL and get execution ID
  EXECUTION_ID=$(curl -s -X POST "https://api.dune.com/api/v1/sql/execute" \
    -H "Content-Type: application/json" \
    -H "X-Dune-Api-Key: YOUR_API_KEY" \
    -d '{"sql": "SELECT * FROM dex.trades LIMIT 10", "performance": "medium"}' \
    | jq -r '.execution_id')

  # Step 2: Poll for completion
  while true; do
    STATE=$(curl -s "https://api.dune.com/api/v1/execution/$EXECUTION_ID/status" \
      -H "X-Dune-Api-Key: YOUR_API_KEY" \
      | jq -r '.state')

    echo "State: $STATE"
    [[ "$STATE" =~ (QUERY_STATE_COMPLETED|QUERY_STATE_FAILED|QUERY_STATE_CANCELLED) ]] && break
    sleep 2
  done

  # Step 3: Get results
  curl -s "https://api.dune.com/api/v1/execution/$EXECUTION_ID/results" \
    -H "X-Dune-Api-Key: YOUR_API_KEY" | jq
  ```
</RequestExample>

<ResponseExample>
  ```json theme={null}
  {
    "execution_id": "01HKZJ2683PHF9Q9PHHQ8FW4Q1",
    "state": "QUERY_STATE_PENDING"
  }
  ```
</ResponseExample>


# Get Execution Result
Source: https://docs.dune.com/api-reference/executions/endpoint/get-execution-result

GET /v1/execution/{execution_id}/results
Given an execution ID, returns result of a an execution request

<Info>
  Minimum required API key scope: `Read`
</Info>

You must pass the `execution_id` obtained from making an [execute query](/api-reference/executions/endpoint/execute-query) POST request.

Result returns the status, metadata, and query results (in JSON) from a query execution.

<Tip>
  * Read more on [Filtering](../filtering), [Sorting](../sorting), and [Sampling](../sampling) to learn more about flexibly grabbing query results.
  * Read more on [Pagination](../pagination) to get the most out of the API and handle large results.
</Tip>

<Info>
  * Results data from an execution are stored for 90 days. This is visible on the API response on the “expires\_at” field in the execution status and results body.
  * Dune internally has a maximum query result size limit (which currently is 32GB). If your query yields more than 32GB of data, the result will be truncated in storage. In such cases, pulling the result data (using pagination) but without specifying `allow_partial_results` set to true will trigger an error message: "error": "Partial Result, please request with 'allows\_partial\_results=true'". If you wish to retrieve partial results, you can pass the parameter `allow_partial_results=true`. But please make sure you indeed want to fetch the truncated result.
</Info>

<Accordion title="Execute query and get result in one call">
  <Tip> If you are using the [Python SDK](https://github.com/duneanalytics/dune-client/tree/d2195b2a9577e2dcae5d2600cb3eddce20987f38) or community [Typescript SDK](https://github.com/bh2smith/ts-dune-client), you can directly execute and fetch a result in one function call, like below: </Tip>

  <Tabs>
    <Tab title="Python SDK">
      ```python theme={null}

      import json
      from dune_client.types import QueryParameter
      from dune_client.client import DuneClient
      from dune_client.query import QueryBase

      # setup Dune Python client
      dune = DuneClient()

      ```

      Use `run_query` to get result in JSON,
      `run_query_csv` to get result in CSV format,
      and `run_query_dataframe` to get result in Pandas dataframe

      ```

      result = dune.run_query(
          query=query # pass in query to run 
          , performance = 'large' # optionally define which tier to run the execution on (default is "medium")
          )

      ```
    </Tab>

    <Tab title="Typescript SDK">
      ```typescript theme={null}
      import { QueryParameter, DuneClient } from "@duneanalytics/client-sdk";
      const { DUNE_API_KEY } = process.env;
      const client = new DuneClient(DUNE_API_KEY ?? "");
      ```

      Use `refresh` to get result in JSON

      ```typescript theme={null}
      const queryID = 1215383;
      const parameters = [
        QueryParameter.text("TextField", "Plain Text"),
        QueryParameter.number("NumberField", 3.1415926535),
        QueryParameter.date("DateField", "2022-05-04 00:00:00"),
        QueryParameter.enum("ListField", "Option 1"),
      ];

      client
        .refresh(queryID, parameters)
        .then((executionResult) => console.log(executionResult.result?.rows));

      // should look like
      // [
      //   {
      //     date_field: "2022-05-04 00:00:00",
      //     list_field: "Option 1",
      //     number_field: "3.1415926535",
      //     text_field: "Plain Text",
      //   },
      // ];
      ```
    </Tab>
  </Tabs>
</Accordion>

<RequestExample>
  ```bash cURL theme={null}

  curl -X GET "https://api.dune.com/api/v1/execution/{{execution_id}}/results" -H x-dune-api-key:{{api_key}}

  ```

  ```python Python SDK theme={null}

  '''
  Download Dune Python SDK by running `pip install dune-client`
  For more info, visit the GitHub repository: https://github.com/duneanalytics/dune-client/tree/d2195b2a9577e2dcae5d2600cb3eddce20987f38
  '''

  import json
  from dune_client.types import QueryParameter
  from dune_client.client import DuneClient
  from dune_client.query import QueryBase

  # setup Dune Python client
  dune = DuneClient()

  result = dune.get_execution_results(job_id = '01HM79YYNXADPK66YWZK5X0NXB') # pass in the execution_id

  ```

  ```python Python theme={null}
  import requests

  url = "https://api.dune.com/api/v1/execution/{execution_id}/results"

  headers = {"X-DUNE-API-KEY": "<x-dune-api-key>"}

  response = requests.request("GET", url, headers=headers)

  print(response.text)

  ```

  ```javascript Javascript theme={null}
  const options = {method: 'GET', headers: {'X-DUNE-API-KEY': '<x-dune-api-key>'}};

  fetch('https://api.dune.com/api/v1/execution/{execution_id}/results', options)
    .then(response => response.json())
    .then(response => console.log(response))
    .catch(err => console.error(err));

  ```

  ```go Go theme={null}
  package main

  import (
  	"fmt"
  	"net/http"
  	"io/ioutil"
  )

  func main() {

  	url := "https://api.dune.com/api/v1/execution/{execution_id}/results"

  	req, _ := http.NewRequest("GET", url, nil)

  	req.Header.Add("X-DUNE-API-KEY", "<x-dune-api-key>")

  	res, _ := http.DefaultClient.Do(req)

  	defer res.Body.Close()
  	body, _ := ioutil.ReadAll(res.Body)

  	fmt.Println(res)
  	fmt.Println(string(body))

  }

  ```

  ```php PHP theme={null}
  <?php

  $curl = curl_init();

  curl_setopt_array($curl, [
    CURLOPT_URL => "https://api.dune.com/api/v1/execution/{execution_id}/results",
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_ENCODING => "",
    CURLOPT_MAXREDIRS => 10,
    CURLOPT_TIMEOUT => 30,
    CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
    CURLOPT_CUSTOMREQUEST => "GET",
    CURLOPT_HTTPHEADER => [
      "X-DUNE-API-KEY: <x-dune-api-key>"
    ],
  ]);

  $response = curl_exec($curl);
  $err = curl_error($curl);

  curl_close($curl);

  if ($err) {
    echo "cURL Error #:" . $err;
  } else {
    echo $response;
  }

  ```

  ```java Java theme={null}
  HttpResponse<String> response = Unirest.get("https://api.dune.com/api/v1/execution/{execution_id}/results")
    .header("X-DUNE-API-KEY", "<x-dune-api-key>")
    .asString();

  ```
</RequestExample>


# Get Execution Result in CSV
Source: https://docs.dune.com/api-reference/executions/endpoint/get-execution-result-csv

GET /v1/execution/{execution_id}/results/csv
Given a query ID, returns the latest executed result of a query on Dune in CSV format

<Info>
  Minimum required API key scope: `Read`
</Info>

You must pass the `execution_id` obtained from making an [execute query](/api-reference/executions/endpoint/execute-query) POST request.

Result returns the status, metadata, and query results (in CSV) from a query execution.

<Tip>
  * Read more on [Filtering](../filtering), [Sorting](../sorting), and [Sampling](../sampling) to learn more about flexibly grabbing query results.
  * Read more on [Pagination](../pagination) to get the most out of the API and handle large results.
</Tip>

<Info>
  * Results data from an execution are stored with an expiration date of 90 days. This is visible on the API response on the “expires\_at” field in the execution status and results json body (not on the CSV endpoint).
  * Dune internally has a maximum query result size limit (which currently is 32GB). If your query yields more than 32GB of data, the result will be truncated in storage. In such cases, pulling the result data (using pagination) but without specifying `allow_partial_results` set to true will trigger an error message: "error": "Partial Result, please request with 'allows\_partial\_results=true'". If you wish to retrieve partial results, you can pass the parameter `allow_partial_results=true`. But please make sure you indeed want to fetch the truncated result.
</Info>

<Accordion title="Execute query and get result in one call">
  <Tip> If you are using the [Python SDK](https://github.com/duneanalytics/dune-client/tree/d2195b2a9577e2dcae5d2600cb3eddce20987f38), you can directly execute and fetch result in one function call, like below: </Tip>

  ```python Python SDK  theme={null}

  import json
  from dune_client.types import QueryParameter
  from dune_client.client import DuneClient
  from dune_client.query import QueryBase

  # setup Dune Python client
  dune = DuneClient()

  ```

  Use `run_query` to get result in JSON,
  `run_query_csv` to get result in CSV format,
  and `run_query_dataframe` to get result in Pandas dataframe

  ```

  result = dune.run_query(
      query=query # pass in query to run 
      , performance = 'large' # optionally define which tier to run the execution on (default is "medium")
      )

  ```
</Accordion>

<RequestExample>
  ```bash cURL theme={null}

  curl -X GET "https://api.dune.com/api/v1/execution/{{execution_id}}/results/csv" -H x-dune-api-key:{{api_key}}

  ```

  ```python Python SDK theme={null}

  '''
  Download Dune Python SDK by running `pip install dune-client`
  For more info, visit the GitHub repository: https://github.com/duneanalytics/dune-client/tree/d2195b2a9577e2dcae5d2600cb3eddce20987f38
  '''

  import json
  from dune_client.types import QueryParameter
  from dune_client.client import DuneClient
  from dune_client.query import QueryBase

  # setup Dune Python client
  dune = DuneClient()

  result = dune.get_execution_results_csv(job_id = '01HM7F50BXZVPHJNWJQM6GMS1M') # pass in the execution_id

  ```

  ```python Python theme={null}
  import requests

  url = "https://api.dune.com/api/v1/execution/{execution_id}/results/csv"

  headers = {"X-DUNE-API-KEY": "<x-dune-api-key>"}

  response = requests.request("GET", url, headers=headers)

  print(response.text)

  ```

  ```javascript Javascript theme={null}
  const options = {method: 'GET', headers: {'X-DUNE-API-KEY': '<x-dune-api-key>'}};

  fetch('https://api.dune.com/api/v1/execution/{execution_id}/results/csv', options)
    .then(response => response.json())
    .then(response => console.log(response))
    .catch(err => console.error(err));

  ```

  ```go Go theme={null}
  package main

  import (
  	"fmt"
  	"net/http"
  	"io/ioutil"
  )

  func main() {

  	url := "https://api.dune.com/api/v1/execution/{execution_id}/results/csv"

  	req, _ := http.NewRequest("GET", url, nil)

  	req.Header.Add("X-DUNE-API-KEY", "<x-dune-api-key>")

  	res, _ := http.DefaultClient.Do(req)

  	defer res.Body.Close()
  	body, _ := ioutil.ReadAll(res.Body)

  	fmt.Println(res)
  	fmt.Println(string(body))

  }

  ```

  ```php PHP theme={null}
  <?php

  $curl = curl_init();

  curl_setopt_array($curl, [
    CURLOPT_URL => "https://api.dune.com/api/v1/execution/{execution_id}/results/csv",
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_ENCODING => "",
    CURLOPT_MAXREDIRS => 10,
    CURLOPT_TIMEOUT => 30,
    CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
    CURLOPT_CUSTOMREQUEST => "GET",
    CURLOPT_HTTPHEADER => [
      "X-DUNE-API-KEY: <x-dune-api-key>"
    ],
  ]);

  $response = curl_exec($curl);
  $err = curl_error($curl);

  curl_close($curl);

  if ($err) {
    echo "cURL Error #:" . $err;
  } else {
    echo $response;
  }

  ```

  ```java Java theme={null}
  HttpResponse<String> response = Unirest.get("https://api.dune.com/api/v1/execution/{execution_id}/results/csv")
    .header("X-DUNE-API-KEY", "<x-dune-api-key>")
    .asString();

  ```
</RequestExample>


# Get Execution Status
Source: https://docs.dune.com/api-reference/executions/endpoint/get-execution-status

GET /v1/execution/{execution_id}/status
Check the status of an execution request

<Info>
  Minimum required API key scope: `Read`
</Info>

You must pass the `execution_id` obtained from making an [execute query](/api-reference/executions/endpoint/execute-query) or [execute SQL](/api-reference/executions/endpoint/execute-sql) POST request.

Returns the status of a query execution along with relevant metadata of the results if the execution is completed. **This endpoint now includes detailed error information when a query fails**, eliminating the need to call the results endpoint just to get error details.

## Pricing

This endpoint has **no charge** and does not consume credits.

## Execution States

Once an execution is triggered, it can be in one of the following states:

* `QUERY_STATE_PENDING`: The query execution is waiting for an execution slot.
* `QUERY_STATE_EXECUTING`: The query is currently executing.
* `QUERY_STATE_FAILED`: The query execution failed. This is a terminal state. **The response will include detailed error information.**
* `QUERY_STATE_COMPLETED`: The query execution completed successfully. You can retrieve the query result for this execution\_id.
* `QUERY_STATE_CANCELED`: The query execution was canceled by the user.
* `QUERY_STATE_EXPIRED`: The query execution expired, and the result is no longer available.
* `QUERY_STATE_COMPLETED_PARTIAL`: The query execution was successful, but the result was truncated because it was too large. To receive the truncated result, set the `allow_partial_results` flag to `true` in the API request to fetch the result.

## Error Response Fields

When a query execution fails (`QUERY_STATE_FAILED`), the response includes an `error` object with the following fields:

* **type** (string): Error type classification (e.g., `FAILED_TYPE_EXECUTION_FAILED`)
* **message** (string): Detailed error message explaining what went wrong, including line and column information
* **metadata** (object): Additional error context
  * **line** (integer): Line number where the error occurred
  * **column** (integer): Column position where the error occurred

<RequestExample>
  ```bash cURL theme={null}

  curl -X GET "https://api.dune.com/api/v1/execution/{{execution_id}}/status" -H x-dune-api-key:{{api_key}}

  ```

  ```python Python SDK theme={null}

  '''
  Download Dune Python SDK by running `pip install dune-client`
  For more info, visit the GitHub repository: https://github.com/duneanalytics/dune-client/tree/d2195b2a9577e2dcae5d2600cb3eddce20987f38
  '''

  import json
  from dune_client.types import QueryParameter
  from dune_client.client import DuneClient
  from dune_client.query import QueryBase

  # setup Dune Python client
  dune = DuneClient()

  result = dune.get_execution_status(job_id = '01HM79YYNXADPK66YWZK5X0NXB') # pass in the execution_id

  ```

  ```python Python theme={null}
  import requests

  url = "https://api.dune.com/api/v1/execution/{execution_id}/status"

  headers = {"X-DUNE-API-KEY": "<x-dune-api-key>"}

  response = requests.request("GET", url, headers=headers)

  print(response.text)

  ```

  ```javascript Javascript theme={null}
  const options = {method: 'GET', headers: {'X-DUNE-API-KEY': '<x-dune-api-key>'}};

  fetch('https://api.dune.com/api/v1/execution/{execution_id}/status', options)
    .then(response => response.json())
    .then(response => console.log(response))
    .catch(err => console.error(err));

  ```

  ```go Go theme={null}
  package main

  import (
  	"fmt"
  	"net/http"
  	"io/ioutil"
  )

  func main() {

  	url := "https://api.dune.com/api/v1/execution/{execution_id}/status"

  	req, _ := http.NewRequest("GET", url, nil)

  	req.Header.Add("X-DUNE-API-KEY", "<x-dune-api-key>")

  	res, _ := http.DefaultClient.Do(req)

  	defer res.Body.Close()
  	body, _ := ioutil.ReadAll(res.Body)

  	fmt.Println(res)
  	fmt.Println(string(body))

  }

  ```

  ```php PHP theme={null}
  <?php

  $curl = curl_init();

  curl_setopt_array($curl, [
    CURLOPT_URL => "https://api.dune.com/api/v1/execution/{execution_id}/status",
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_ENCODING => "",
    CURLOPT_MAXREDIRS => 10,
    CURLOPT_TIMEOUT => 30,
    CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
    CURLOPT_CUSTOMREQUEST => "GET",
    CURLOPT_HTTPHEADER => [
      "X-DUNE-API-KEY: <x-dune-api-key>"
    ],
  ]);

  $response = curl_exec($curl);
  $err = curl_error($curl);

  curl_close($curl);

  if ($err) {
    echo "cURL Error #:" . $err;
  } else {
    echo $response;
  }

  ```

  ```java Java theme={null}
  HttpResponse<String> response = Unirest.get("https://api.dune.com/api/v1/execution/{execution_id}/status")
    .header("X-DUNE-API-KEY", "<x-dune-api-key>")
    .asString();

  ```
</RequestExample>

<ResponseExample>
  ```json Success Response theme={null}
  {
    "execution_id": "01HKZJ2683PHF9Q9PHHQ8FW4Q1",
    "query_id": 3493826,
    "is_execution_finished": true,
    "state": "QUERY_STATE_COMPLETED",
    "submitted_at": "2025-10-22T10:31:04.222464Z",
    "expires_at": "2026-01-20T10:31:04.36241Z",
    "execution_started_at": "2025-10-22T10:31:05.123456Z",
    "execution_ended_at": "2025-10-22T10:31:15.789012Z",
    "execution_cost_credits": 10
  }
  ```

  ```json Error Response theme={null}
  {
    "execution_id": "01K85QHSS0RBGW4BHDM0RFCG9C",
    "query_id": 6012998,
    "is_execution_finished": true,
    "state": "QUERY_STATE_FAILED",
    "submitted_at": "2025-10-22T10:31:04.222464Z",
    "expires_at": "2026-01-20T10:31:04.36241Z",
    "execution_cost_credits": 0,
    "error": {
      "type": "FAILED_TYPE_EXECUTION_FAILED",
      "message": "line 1:8: Column 'x' cannot be resolved at line 1, position 8. Please verify that this column exists using the data explorer. Learn how to use the data explorer here: https://dune.com/docs/app/query-editor/data-explorer/ [Execution ID: 01K85QHSS0RBGW4BHDM0RFCG9C]",
      "metadata": {
        "line": 1,
        "column": 8
      }
    }
  }
  ```
</ResponseExample>


# Get Latest Query Result
Source: https://docs.dune.com/api-reference/executions/endpoint/get-query-result

GET /v1/query/{query_id}/results
Given a query ID, returns the latest executed result of a query on Dune in JSON format

<Info>
  Minimum required API key scope: `Read`
</Info>

You must pass parameter query\_id.

Returns the latest execution id and results (in JSON) of that latest run, regardless of the job id/run or if it is run in the app or the api.

The query specified must either be public or a query you have ownership of (you or a team you belong to have ownership).

<Tip>
  * This endpoint does NOT trigger an execution but does **consume credits based on the result size**. See [Billing](/api-reference/overview/billing) for details.
  * Read more on [Filtering](../filtering), [Sorting](../sorting), and [Sampling](../sampling) to learn more about flexibly grabbing query results.
  * Read more on [Pagination](../pagination) to get the most out of the API and handle large results.
</Tip>

<Info>
  * Dune internally has a maximum query result size limit (which currently is 32GB). If your query yields more than 32GB of data, the result will be truncated in storage. In such cases, pulling the result data (using pagination) but without specifying `allow_partial_results` set to true will trigger an error message: "error": "Partial Result, please request with 'allows\_partial\_results=true'". If you wish to retrieve partial results, you can pass the parameter `allow_partial_results=true`. But please make sure you indeed want to fetch the truncated result.
</Info>

<Accordion title="Execute query and get result in one call">
  <Tip> If you are using the [Python SDK](https://github.com/duneanalytics/dune-client/tree/d2195b2a9577e2dcae5d2600cb3eddce20987f38), you can directly execute and fetch result in one function call, like below: </Tip>

  ```python Python SDK  theme={null}

  import json
  from dune_client.types import QueryParameter
  from dune_client.client import DuneClient
  from dune_client.query import QueryBase

  # setup Dune Python client
  dune = DuneClient()

  ```

  Use `run_query` to get result in JSON,
  `run_query_csv` to get result in CSV format,
  and `run_query_dataframe` to get result in Pandas dataframe

  ```

  result = dune.run_query(
      query=query # pass in query to run 
      , performance = 'large' # optionally define which tier to run the execution on (default is "medium")
      )

  ```
</Accordion>

<RequestExample>
  ```bash cURL theme={null}

  curl --request GET \
    --url https://api.dune.com/api/v1/query/{query_id}/results
    
  ```

  ```python Python SDK theme={null}

  '''
  Download Dune Python SDK by running `pip install dune-client`
  For more info, visit the GitHub repository: https://github.com/duneanalytics/dune-client/tree/d2195b2a9577e2dcae5d2600cb3eddce20987f38
  '''

  import json
  from dune_client.types import QueryParameter
  from dune_client.client import DuneClient
  from dune_client.query import QueryBase

  # setup Dune Python client
  dune = DuneClient()

  # pass in the query_id
  # optionally specify a `max_age_hours` to re-run the query if the data is too outdated
  result =  dune.get_latest_result('2363421', max_age_hours=8) 

  # can also call `get_latest_result_dataframe` method to get latest result in Python Pandas dataframe format

  ```

  ```python Python theme={null}
  import requests

  url = "https://api.dune.com/api/v1/query/{query_id}/results"

  headers = {"X-DUNE-API-KEY": "<x-dune-api-key>"}

  response = requests.request("GET", url, headers=headers)

  print(response.text)

  ```

  ```javascript Javascript theme={null}
  const options = {method: 'GET', headers: {'X-DUNE-API-KEY': '<x-dune-api-key>'}};

  fetch('https://api.dune.com/api/v1/query/{query_id}/results', options)
    .then(response => response.json())
    .then(response => console.log(response))
    .catch(err => console.error(err));

  ```

  ```go Go theme={null}
  package main

  import (
  	"fmt"
  	"net/http"
  	"io/ioutil"
  )

  func main() {

  	url := "https://api.dune.com/api/v1/query/{query_id}/results"

  	req, _ := http.NewRequest("GET", url, nil)

  	req.Header.Add("X-DUNE-API-KEY", "<x-dune-api-key>")

  	res, _ := http.DefaultClient.Do(req)

  	defer res.Body.Close()
  	body, _ := ioutil.ReadAll(res.Body)

  	fmt.Println(res)
  	fmt.Println(string(body))

  }

  ```

  ```php PHP theme={null}
  <?php

  $curl = curl_init();

  curl_setopt_array($curl, [
    CURLOPT_URL => "https://api.dune.com/api/v1/query/{query_id}/results",
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_ENCODING => "",
    CURLOPT_MAXREDIRS => 10,
    CURLOPT_TIMEOUT => 30,
    CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
    CURLOPT_CUSTOMREQUEST => "GET",
    CURLOPT_HTTPHEADER => [
      "X-DUNE-API-KEY: <x-dune-api-key>"
    ],
  ]);

  $response = curl_exec($curl);
  $err = curl_error($curl);

  curl_close($curl);

  if ($err) {
    echo "cURL Error #:" . $err;
  } else {
    echo $response;
  }

  ```

  ```java Java theme={null}
  HttpResponse<String> response = Unirest.get("https://api.dune.com/api/v1/query/{query_id}/results")
    .header("X-DUNE-API-KEY", "<x-dune-api-key>")
    .asString();

  ```
</RequestExample>


# Get Latest Query Result in CSV
Source: https://docs.dune.com/api-reference/executions/endpoint/get-query-result-csv

GET /v1/query/{query_id}/results/csv
Given a query ID, returns the latest executed result of a query on Dune as CSV

<Info>
  Minimum required API key scope: `Read`
</Info>

You must pass parameter query\_id.

Returns the latest execution id and results (in CSV) of that latest run, regardless of the job id/run or if it is run in the app or the api.

The query specified must either be public or a query you have ownership of (you or a team you belong to have ownership).

<Tip>
  * This endpoint does NOT trigger an execution but does **consume credits based on the result size**. See [Billing](/api-reference/overview/billing) for details.
  * Read more on [Filtering](../filtering), [Sorting](../sorting), and [Sampling](../sampling) to learn more about flexibly grabbing query results.
  * Read more on [Pagination](../pagination) to get the most out of the API and handle large results.
</Tip>

<Info>
  * Dune internally has a maximum query result size limit (which currently is 32GB). If your query yields more than 32GB of data, the result will be truncated in storage. In such cases, pulling the result data (using pagination) but without specifying `allow_partial_results` set to true will trigger an error message: "error": "Partial Result, please request with 'allows\_partial\_results=true'". If you wish to retrieve partial results, you can pass the parameter `allow_partial_results=true`. But please make sure you indeed want to fetch the truncated result.
</Info>

<Accordion title="Execute query and get result in one call">
  <Tip> If you are using the [Python SDK](https://github.com/duneanalytics/dune-client/tree/d2195b2a9577e2dcae5d2600cb3eddce20987f38), you can directly execute and fetch result in one function call, like below: </Tip>

  ```python Python SDK  theme={null}

  import json
  from dune_client.types import QueryParameter
  from dune_client.client import DuneClient
  from dune_client.query import QueryBase

  # setup Dune Python client
  dune = DuneClient()

  ```

  Use `run_query` to get result in JSON,
  `run_query_csv` to get result in CSV format,
  and `run_query_dataframe` to get result in Pandas dataframe.

  ```

  result = dune.run_query(
      query=query # pass in query to run 
      , performance = 'large' # optionally define which tier to run the execution on (default is "medium")
      )

  ```
</Accordion>

<RequestExample>
  ```bash cURL theme={null}

  curl --request GET \
    --url https://api.dune.com/api/v1/query/{query_id}/results/csv

  ```

  ```python Python SDK theme={null}

  '''
  Download Dune Python SDK by running `pip install dune-client`
  For more info, visit the GitHub repository: https://github.com/duneanalytics/dune-client/tree/d2195b2a9577e2dcae5d2600cb3eddce20987f38
  '''

  import json
  from dune_client.types import QueryParameter
  from dune_client.client import DuneClient
  from dune_client.query import QueryBase

  # setup Dune Python client
  dune = DuneClient()

  # pass in the query_id
  result = dune.download_csv('2363421') 

  # can also call `get_latest_result_dataframe` method to get latest result in Python Pandas dataframe format

  ```

  ```python Python theme={null}
  import requests

  url = "https://api.dune.com/api/v1/query/{query_id}/results/csv"

  headers = {"X-DUNE-API-KEY": "<x-dune-api-key>"}

  response = requests.request("GET", url, headers=headers)

  print(response.text)

  ```

  ```javascript Javascript theme={null}
  const options = {method: 'GET', headers: {'X-DUNE-API-KEY': '<x-dune-api-key>'}};

  fetch('https://api.dune.com/api/v1/query/{query_id}/results/csv', options)
    .then(response => response.json())
    .then(response => console.log(response))
    .catch(err => console.error(err));

  ```

  ```go Go theme={null}
  package main

  import (
  	"fmt"
  	"net/http"
  	"io/ioutil"
  )

  func main() {

  	url := "https://api.dune.com/api/v1/query/{query_id}/results/csv"

  	req, _ := http.NewRequest("GET", url, nil)

  	req.Header.Add("X-DUNE-API-KEY", "<x-dune-api-key>")

  	res, _ := http.DefaultClient.Do(req)

  	defer res.Body.Close()
  	body, _ := ioutil.ReadAll(res.Body)

  	fmt.Println(res)
  	fmt.Println(string(body))

  }

  ```

  ```php PHP theme={null}
  <?php

  $curl = curl_init();

  curl_setopt_array($curl, [
    CURLOPT_URL => "https://api.dune.com/api/v1/query/{query_id}/results/csv",
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_ENCODING => "",
    CURLOPT_MAXREDIRS => 10,
    CURLOPT_TIMEOUT => 30,
    CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
    CURLOPT_CUSTOMREQUEST => "GET",
    CURLOPT_HTTPHEADER => [
      "X-DUNE-API-KEY: <x-dune-api-key>"
    ],
  ]);

  $response = curl_exec($curl);
  $err = curl_error($curl);

  curl_close($curl);

  if ($err) {
    echo "cURL Error #:" . $err;
  } else {
    echo $response;
  }

  ```

  ```java Java theme={null}
  HttpResponse<String> response = Unirest.get("https://api.dune.com/api/v1/query/{query_id}/results/csv")
    .header("X-DUNE-API-KEY", "<x-dune-api-key>")
    .asString();

  ```
</RequestExample>


# Overview
Source: https://docs.dune.com/api-reference/executions/execution-object



The executions and results endpoints facilitate the execution of saved queries, retrieval of results in various formats, and management of query executions.

## Queries, Executions, and Results

Results are linked to executions, and executions are tied to queries. Each execution has an `execution_id`. An `execution_id` is generated when you initiate the execution of a query through the [execute query](./endpoint/execute-query) endpoint.

Unlike a `query_id`, which identifies a specific query, an `execution_id` represents a particular execution of that query. With an `execution_id`, you can monitor the execution's status using the [check status](./endpoint/get-execution-status) endpoint. The status can be one of the following: pending, success, or failure.

If an execution is successful, you can get the result using [get result](./endpoint/get-execution-result). Results are saved and can be retrieved multiple times.
Results data from an execution are stored with an expiration date of 90 days (subject to change). This is visible on the API response on the “expires\_at” field in the execution status and results json body (not on the CSV endpoint).

<Tip>
  * Save your `execution_id` for later use without re-executing.
  * Use the [get latest query result](./endpoint/get-query-result) endpoint to fetch the most recent result.
  * Understanding the differences and relationships between query results filters, schedules, executions, and params is crucial. Further details are provided below.
</Tip>

## Query Filters vs. Execution Parameters

Two primary methods exist for fetching data from the Dune API while applying specific conditions:

**Option 1**: Utilize filters with the latest query result and employ schedules to maintain data freshness.

1. Obtain the `query_id`.
2. Use [get latest query result](./endpoint/get-query-result) endpoint to access the most recent results.
3. Apply [filters](./filtering) for desired data subsets.
4. Implement schedules for maintaining data freshness.

**Option 2**: Execute a query with parameters to retrieve the desired subset of data.

1. Obtain the `query_id`.
2. Use [execute query](./endpoint/execute-query) endpoint with parameters to trigger fresh execution.
3. Grab the `execution_id` from the response.
4. Fetch results via [get execution result](./endpoint/get-execution-result) endpoint using the `execution_id`.

### Choosing Between Options

* Option 1 offers speed, as it builds upon existing results with filters. Use it when quick results are essential.
* Option 2 allows dynamic parameter passing for fresh executions. Employ it when real-time parameterization is required.

## Endpoints

Below is an overview of each endpoint, providing a high-level understanding of their functionalities.

| Endpoint Title                                                     | Endpoint                                       | Description                                                                                                                 |
| ------------------------------------------------------------------ | ---------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| [Execute SQL](./endpoint/execute-sql)                              | `POST /v1/sql/execute`                         | Executes arbitrary SQL queries directly. Returns an `execution_id` to track the query execution.                            |
| [Execute Query](./endpoint/execute-query)                          | `POST /v1/query/{query_id}/execute`            | Triggers an execution based on the `query_id`. Returns an `execution_id`.                                                   |
| [Execute Query Pipeline](./endpoint/execute-query-pipeline)        | `POST /v1/query/{query_id}/pipeline/execute`   | Executes a query pipeline with all its dependencies. Returns a `pipeline_execution_id`.                                     |
| [Get Execution Status](./endpoint/get-execution-status)            | `GET /v1/execution/{execution_id}/status`      | Provides the status of a query execution given an `execution_id`.                                                           |
| [Get Execution Result](./endpoint/get-execution-result)            | `GET /v1/execution/{execution_id}/results`     | Fetches the execution status, metadata, and results in JSON format. Similar data handling as CSV endpoint.                  |
| [Get Execution Result in CSV](./endpoint/get-execution-result-csv) | `GET /v1/execution/{execution_id}/results/csv` | Retrieves the status, metadata, and results in CSV format. Includes data retention and limit information.                   |
| [Get Latest Query Result](./endpoint/get-query-result)             | `GET /v1/query/{query_id}/results`             | Similar to the CSV endpoint but returns results in JSON format. Follows the same access and data limit policies.            |
| [Get Latest Query Result in CSV](./endpoint/get-query-result-csv)  | `GET /v1/query/{query_id}/results/csv`         | Returns the latest results of a query in CSV format, irrespective of the execution method. Queries must be public or owned. |
| [Cancel Execution](./endpoint/cancel-execution)                    | `POST /v1/execution/{execution_id}/cancel`     | Cancels an ongoing query execution. Requires the `execution_id`. Returns a success boolean.                                 |


# Result Filtering
Source: https://docs.dune.com/api-reference/executions/filtering

Filter query results server-side using SQL-like WHERE clauses - unique to Dune's API

<Note>
  **Unique to Dune:** Server-side result filtering is a powerful feature that sets Dune's API apart. Filter millions of rows using SQL-like WHERE clauses without transferring unnecessary data or processing client-side.
</Note>

## Overview

Dune's API supports sophisticated filtering on all `/results` endpoints, allowing you to refine query results server-side. Apply filters on rows and columns to dramatically reduce bandwidth and processing time.

**Benefits:**

* **Reduce bandwidth:** Only transfer the data you need
* **Save processing time:** Filter server-side before data transfer
* **Simplify client code:** No need for complex client-side filtering logic
* **Lower costs:** Minimize data transfer and API calls

**Available on these endpoints:**

* [Get Execution Results](./endpoint/get-execution-result)
* [Get Execution Results CSV](./endpoint/get-execution-result-csv)
* [Get Query Results](./endpoint/get-query-result)
* [Get Query Results CSV](./endpoint/get-query-result-csv)

Filtering can be effectively used in conjunction with [pagination](./pagination) and [sorting](./sorting) to further enhance query efficiency and relevance. See an example of filtering in action with [this Dune farcaster frame](/learning/how-tos/dune-frames).

#### Example Filtering Request

<Tabs>
  <Tab title="Python SDK">
    ```python theme={null}
    from dune_client.client import DuneClient

    # setup Dune Python client
    dune = DuneClient()

    query_result = dune.get_latest_result_dataframe(
        query=3567562 # https://dune.com/queries/3567562
        , filters="overtip_amount > 0"
        , columns=["donor_fname","overtip_amount","days_overtipped","overall_tip_given_amount","overall_avg_tip_amount"]
        , sort_by=["overall_tip_given_amount desc"]
    )

    print(query_result)

    ```
  </Tab>

  <Tab title="cURL">
    ```bash theme={null}
    curl -X GET 'https://api.dune.com/api/v1/query/{{query_id}}/results?limit=10&filters=block_time%3E%272024-03-01%27&columns=tx_from%2Ctx_to%2Ctx_hash%2Camount_usd&sort_by=amount_usd%20desc%2Cblock_time' \
    -H 'x-dune-api-key:{{api_key}}’
    ```
  </Tab>

  <Tab title="Python">
    ```python theme={null}
    import requests

    url = "https://api.dune.com/api/v1/query/{query_id}/results"

    headers = {"X-DUNE-API-KEY": "<x-dune-api-key>"}

    params = {
        "limit": 10,
        "filters": "block_time > '2024-03-01'",
        "columns": "tx_from,tx_to,tx_hash,amount_usd",
        "sort_by": "amount_usd desc, block_time"
        }

    response = requests.request("GET", url, headers=headers, params=params)

    print(response.text)

    ```
  </Tab>

  <Tab title="Javascript">
    ```javascript theme={null}

    const options = {
        method: 'GET',
        headers: {
            'X-DUNE-API-KEY': '<x-dune-api-key>'
        }
    };

    const queryParams = new URLSearchParams({
        limit: 10,
        filters: "block_time > '2024-03-01'",
        columns: "tx_from,tx_to,tx_hash,amount_usd",
        sort_by: "amount_usd desc, block_time"
    });
    const url = `https://api.dune.com/api/v1/query/{query_id}/results?${queryParams}`;

    fetch(url, options)
        .then(response => response.json())
        .then(response => console.log(response))
        .catch(err => console.error(err));


    ```
  </Tab>

  <Tab title="Go">
    ```go theme={null}

    package main

    import (
        "fmt"
        "net/http"
        "io/ioutil"
        "net/url"
    )

    func main() {
        url := "https://api.dune.com/api/v1/query/{query_id}/results"

        // Create query parameters
        params := url.Values{}
        params.Set("limit", "10")
        params.Set("filters", "block_time > '2024-03-01'")
        params.Set("columns", "tx_from,tx_to,tx_hash,amount_usd")
        params.Set("sort_by", "amount_usd desc, block_time")

        // Add parameters to URL
        fullURL := fmt.Sprintf("%s?%s", url, params.Encode())

        req, _ := http.NewRequest("GET", fullURL, nil)

        req.Header.Add("X-DUNE-API-KEY", "<x-dune-api-key>")

        res, _ := http.DefaultClient.Do(req)

        defer res.Body.Close()
        body, _ := ioutil.ReadAll(res.Body)

        fmt.Println(res)
        fmt.Println(string(body))
    }
    ```
  </Tab>

  <Tab title="PHP">
    ```php theme={null}
    <?php

    $curl = curl_init();

    $url = "https://api.dune.com/api/v1/query/{query_id}/results";
    $queryParams = http_build_query([
        'limit' => 10,
        'filters' => "block_time > '2024-03-01'",
        'columns' => "tx_from,tx_to,tx_hash,amount_usd",
        'sort_by' => "amount_usd desc, block_time",
    ]);
    $url .= '?' . $queryParams;

    curl_setopt_array($curl, [
        CURLOPT_URL => $url,
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_ENCODING => "",
        CURLOPT_MAXREDIRS => 10,
        CURLOPT_TIMEOUT => 30,
        CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
        CURLOPT_CUSTOMREQUEST => "GET",
        CURLOPT_HTTPHEADER => [
            "X-DUNE-API-KEY: <x-dune-api-key>"
        ],
    ]);

    $response = curl_exec($curl);
    $err = curl_error($curl);

    curl_close($curl);

    if ($err) {
        echo "cURL Error #:" . $err;
    } else {
        echo $response;
    }
    ?>
    ```
  </Tab>

  <Tab title="Java">
    ```java theme={null}

    import kong.unirest.HttpResponse;
    import kong.unirest.Unirest;

    public class Main {
        public static void main(String[] args) {
            HttpResponse<String> response = Unirest.get("https://api.dune.com/api/v1/query/{query_id}/results")
                    .header("X-DUNE-API-KEY", "<x-dune-api-key>")
                    .queryString("limit", 10)
                    .queryString("filters", "block_time > '2024-03-01'")
                    .queryString("columns", "tx_from,tx_to,tx_hash,amount_usd")
                    .queryString("sort_by", "amount_usd desc, block_time")
                    .asString();

            System.out.println(response.getBody());
        }
    }
    ```
  </Tab>
</Tabs>

### Filtering Parameters

#### `filters`

* **Type:** `string`
* **Description:** Allows specifying criteria to filter rows in the result set. It functions similarly to a SQL `WHERE` clause. If omitted, all results are returned.

<Note>
  - Use the format `<column_name> <operator> <value>` for criteria, for example, `block_time >= '2024-03-05 15:03'`.
  - Combine criteria using parentheses and logical operators `AND` / `OR`, e.g., `block_time >= '2024-03-05 15:03' AND (project = 'uniswap' OR project = 'balancer')`.
  - The `IN` operator is permitted, as in `tx_to IN (0x6a3e4b7e23661108aaec70266c468e6c679ae022, 0xdbf89389504e39f03fbb6bdd601aabb6bfbbed71)`.
  - The `NOT` operator is not supported; using `NOT IN` or `NOT LIKE` will produce an error.
  - For column names with special characters (e.g., spaces, emojis, dashes, dots), enclose them in double quotes: `"special, column" = 'ABC'`.
  - Values must be strings or numbers. SQL expressions like `now() - interval '1' day` are not allowed.
  - Dates and times should be formatted as strings, e.g., `block_time > '2023-01-03'`.
</Note>

#### `columns`

* **Type:** `string`
* **Description:** Specifies the column names to include in the result set. If omitted, all columns are returned.

<Note>
  - List column names without spaces, e.g., use `project,block_time,amount_usd` instead of `project, block_time, amount_usd`.
  - Specifying columns helps limit the results to essential data, reducing the data cost of the call.
</Note>

## Common Filtering Patterns

### Filter by Time Range

```bash theme={null}
# Last 24 hours
filters="block_time > '2024-03-05'"

# Specific time range
filters="block_time >= '2024-03-01' AND block_time < '2024-04-01'"

# Recent data (note: relative time expressions are NOT supported in filters)
# Instead, calculate the date client-side
filters="block_time > '2024-03-10 15:30'"
```

### Filter by Value Thresholds

```bash theme={null}
# Transactions above $1000
filters="amount_usd > 1000"

# Volume between ranges
filters="volume_usd >= 10000 AND volume_usd <= 100000"

# Non-null values
filters="amount_usd IS NOT NULL"
```

### Filter by Category

```bash theme={null}
# Single protocol
filters="project = 'uniswap'"

# Multiple protocols (using OR)
filters="project = 'uniswap' OR project = 'sushiswap'"

# Using IN operator
filters="project IN ('uniswap', 'sushiswap', 'curve')"

# Specific blockchain
filters="blockchain = 'ethereum'"
```

### Complex Conditions

```bash theme={null}
# Combine multiple conditions
filters="blockchain = 'ethereum' AND amount_usd > 1000 AND block_time > '2024-03-01'"

# Use parentheses for grouping
filters="(project = 'uniswap' OR project = 'sushiswap') AND amount_usd > 10000"

# Filter with pattern matching
filters="token_symbol LIKE 'WETH%'"

# Address filtering
filters="tx_to IN ('0x6a3e4b7e23661108aaec70266c468e6c679ae022', '0xdbf89389504e39f03fbb6bdd601aabb6bfbbed71')"
```

### Filter with Column Selection

```python theme={null}
# Python SDK example: Get only specific columns for large trades
results = dune.get_latest_result_dataframe(
    query=3493826,
    filters="amount_usd > 10000 AND blockchain = 'ethereum'",
    columns="tx_hash,tx_from,tx_to,amount_usd,block_time"
)
```

<Tip>
  **Performance tip:** Combine filtering with column selection to minimize data transfer. For example, instead of fetching all 50 columns for millions of rows, fetch only the 5 columns you need for 1000 filtered rows.
</Tip>

## Real-World Examples

### Example 1: Whale Transactions

```python theme={null}
from dune_client import DuneClient

dune = DuneClient(api_key="YOUR_API_KEY")

# Get large USDC transfers in the last day
results = dune.get_latest_result_dataframe(
    query=3493826,
    filters="token_symbol = 'USDC' AND amount_usd > 1000000 AND block_time > '2024-03-10'",
    columns="tx_hash,tx_from,tx_to,amount_usd,block_time",
    sort_by="amount_usd desc"
)

print(f"Found {len(results)} whale transactions")
```

### Example 2: Protocol-Specific Analytics

```typescript theme={null}
import { DuneClient } from '@duneanalytics/client';

const dune = new DuneClient('YOUR_API_KEY');

// Get Uniswap V3 trades on Arbitrum
const results = await dune.getLatestResults({
  queryId: 3493826,
  filters: "project = 'uniswap' AND version = '3' AND blockchain = 'arbitrum'",
  columns: "trader,token_bought_symbol,token_sold_symbol,amount_usd",
  limit: 100
});
```

### Example 3: Token-Specific Monitoring

```bash theme={null}
# Monitor recent trades for a specific token pair
curl -X GET \
  'https://api.dune.com/api/v1/query/3493826/results?filters=token_bought_symbol%20%3D%20%27WETH%27%20AND%20token_sold_symbol%20%3D%20%27USDC%27%20AND%20block_time%20%3E%20%272024-03-10%27&columns=amount_usd%2Cprice%2Cblock_time&sort_by=block_time%20desc' \
  -H 'X-DUNE-API-KEY: YOUR_API_KEY'
```

### Example 4: Multi-Chain Analysis

```python theme={null}
# Compare volumes across chains for the same protocol
blockchains = ['ethereum', 'polygon', 'arbitrum', 'optimism']

for chain in blockchains:
    results = dune.get_latest_result_dataframe(
        query=3493826,
        filters=f"blockchain = '{chain}' AND project = 'uniswap'",
        columns="blockchain,amount_usd"
    )
    total_volume = results['amount_usd'].sum()
    print(f"{chain}: ${total_volume:,.2f}")
```

## Filtering Best Practices

<AccordionGroup>
  <Accordion title="Always filter time ranges">
    Reduce the amount of data scanned by filtering by `block_time`:

    ```bash theme={null}
    # ✅ Good - filters recent data
    filters="block_time > '2024-03-01' AND amount_usd > 1000"

    # ❌ Less efficient - scans all historical data
    filters="amount_usd > 1000"
    ```
  </Accordion>

  <Accordion title="Combine filters with column selection">
    Minimize bandwidth by only requesting needed columns:

    ```bash theme={null}
    # ✅ Optimal - filtered rows, selected columns
    filters="amount_usd > 10000"&columns="tx_hash,amount_usd,block_time"

    # ❌ Wasteful - fetches all columns
    filters="amount_usd > 10000"
    ```
  </Accordion>

  <Accordion title="Use IN for multiple values">
    More efficient than multiple OR conditions:

    ```bash theme={null}
    # ✅ Better
    filters="blockchain IN ('ethereum', 'polygon', 'arbitrum')"

    # ✅ Also valid but longer
    filters="blockchain = 'ethereum' OR blockchain = 'polygon' OR blockchain = 'arbitrum'"
    ```
  </Accordion>

  <Accordion title="Be specific with data types">
    Use proper quoting for strings, no quotes for numbers:

    ```bash theme={null}
    # ✅ Correct
    filters="blockchain = 'ethereum' AND amount_usd > 1000"

    # ❌ Wrong - amount_usd should not be quoted
    filters="blockchain = 'ethereum' AND amount_usd > '1000'"
    ```
  </Accordion>

  <Accordion title="Handle special column names">
    Use double quotes for columns with special characters:

    ```bash theme={null}
    # ✅ Correct for special characters
    filters="\"token.symbol\" = 'USDC'"

    # ✅ No quotes needed for normal names
    filters="token_symbol = 'USDC'"
    ```
  </Accordion>
</AccordionGroup>

## Limitations

<Warning>
  * **No SQL expressions:** Filters must use literal values. Expressions like `now() - interval '1' day` are not supported. Calculate values client-side instead.
  * **No NOT operator:** `NOT IN` and `NOT LIKE` are not supported. Use positive conditions instead.
  * **No subqueries:** Filters cannot contain subqueries. Use parameterized queries for complex logic.
  * **String and number values only:** Filters only support string and numeric literals.
</Warning>

## Filtered Response

<Accordion title="Example filtered response">
  ```json theme={null}
      {
          "execution_id": "01HR8AGD6CWGHGP1BN3Z1SJ4MD",
          "query_id": 3493826,
          "is_execution_finished": true,
          "state": "QUERY_STATE_COMPLETED",
          "submitted_at": "2024-03-05T22:07:22.828653Z",
          "expires_at": "2024-06-03T22:07:53.36647Z",
          "execution_started_at": "2024-03-05T22:07:24.013663281Z",
          "execution_ended_at": "2024-03-05T22:07:53.366469062Z",
          "result": {
              "rows": [
                  {
                      "amount_usd": null,
                      "block_time": "2024-03-05 20:50:59.000 UTC",
                      "tx_from": "0x38032f326436fdb9c7a9b359e90010f86b8ab482",
                      "tx_hash": "0xce6f59cf2f0b395d8fc33e49d1f5db5686be95555135fd8126bc7c59327cd9be",
                      "tx_to": "0x061b87122ed14b9526a813209c8a59a633257bab"
                  },
                  {
                      "amount_usd": null,
                      "block_time": "2024-03-05 20:49:33.000 UTC",
                      "tx_from": "0xb46b909be665d75f833be22c6e6285ba5ad74dfa",
                      "tx_hash": "0x1f1725ebe374b1ffb50047055b793b2be6a8cb07ab75fd685b95e842953da4ca",
                      "tx_to": "0x1111111254eeb25477b68fb85ed929f73a960582"
                  },
                  {
                      "amount_usd": null,
                      "block_time": "2024-03-05 20:48:53.000 UTC",
                      "tx_from": "0x40014275b332f38423fa0de39939d26c7294ffc0",
                      "tx_hash": "0xb4364656c20007fb1d7bfa93d87fc6fe345a91b10661835d1a54d1ac7761a244",
                      "tx_to": "0x1111111254eeb25477b68fb85ed929f73a960582"
                  },
                  {
                      "amount_usd": 1397.903560808159,
                      "block_time": "2024-03-05 20:48:03.000 UTC",
                      "tx_from": "0xb46b909be665d75f833be22c6e6285ba5ad74dfa",
                      "tx_hash": "0x818f701a6c7dcf78a090cfd8324da5896005c2a6d8e3ec5ac2c29cfa5e67f5d9",
                      "tx_to": "0x1111111254eeb25477b68fb85ed929f73a960582"
                  },
                  {
                      "amount_usd": null,
                      "block_time": "2024-03-05 20:47:55.000 UTC",
                      "tx_from": "0x50758bdc1735e94401ed73eb7e8bde482766819c",
                      "tx_hash": "0x1dc342dc397ffa7b433fa64280fe9f4a7e0b51409e9abc9fde61bc9b85c938be",
                      "tx_to": "0x4c4af8dbc524681930a27b2f1af5bcc8062e6fb7"
                  },
                  {
                      "amount_usd": null,
                      "block_time": "2024-03-05 20:47:55.000 UTC",
                      "tx_from": "0x50758bdc1735e94401ed73eb7e8bde482766819c",
                      "tx_hash": "0x1dc342dc397ffa7b433fa64280fe9f4a7e0b51409e9abc9fde61bc9b85c938be",
                      "tx_to": "0x4c4af8dbc524681930a27b2f1af5bcc8062e6fb7"
                  },
                  {
                      "amount_usd": null,
                      "block_time": "2024-03-05 20:47:53.000 UTC",
                      "tx_from": "0xfa3dc8db10e7c2f7dfa87e86bba6257066731bc1",
                      "tx_hash": "0x0d34634a9438ce241e2870b23e70a008c8db839ba38daadc1074c9b1a52be7c7",
                      "tx_to": "0xba12222222228d8ba445958a75a0704d566bf2c8"
                  },
                  {
                      "amount_usd": 2.753641952846242,
                      "block_time": "2024-03-05 20:47:53.000 UTC",
                      "tx_from": "0xfa3dc8db10e7c2f7dfa87e86bba6257066731bc1",
                      "tx_hash": "0x0d34634a9438ce241e2870b23e70a008c8db839ba38daadc1074c9b1a52be7c7",
                      "tx_to": "0xba12222222228d8ba445958a75a0704d566bf2c8"
                  },
                  {
                      "amount_usd": null,
                      "block_time": "2024-03-05 20:47:53.000 UTC",
                      "tx_from": "0xfa3dc8db10e7c2f7dfa87e86bba6257066731bc1",
                      "tx_hash": "0x0d34634a9438ce241e2870b23e70a008c8db839ba38daadc1074c9b1a52be7c7",
                      "tx_to": "0xba12222222228d8ba445958a75a0704d566bf2c8"
                  },
                  {
                      "amount_usd": 1798.8186143812122,
                      "block_time": "2024-03-05 20:47:49.000 UTC",
                      "tx_from": "0xb46b909be665d75f833be22c6e6285ba5ad74dfa",
                      "tx_hash": "0xcf8d9873f017a8ba9e624c3bb61bede8e11c194965690026cd394f20c55f896a",
                      "tx_to": "0x1111111254eeb25477b68fb85ed929f73a960582"
                  }
              ],
              "metadata": {
                  "column_names": [
                      "block_time",
                      "tx_from",
                      "tx_to",
                      "tx_hash",
                      "amount_usd"
                  ],
                  "row_count": 10,
                  "result_set_bytes": 2042,
                  "total_row_count": 100,
                  "total_result_set_bytes": 56496,
                  "datapoint_count": 50,
                  "pending_time_millis": 1185,
                  "execution_time_millis": 29352
              }
          },
          "next_uri": "https://api.dune.com/api/v1/execution/01HR8AGD6CWGHGP1BN3Z1SJ4MD/results?columns=block_time%2Ctx_from%2Ctx_to%2Ctx_hash%2Camount_usd&filters=block_time+%3E+%272024-03-01%27&limit=10&offset=10",
          "next_offset": 10
      }
  ```
</Accordion>


# Pagination
Source: https://docs.dune.com/api-reference/executions/pagination



Our API supports pagination on all `/results` endpoints  to facilitate efficient data retrieval by dividing large datasets into smaller, manageable chunks. This feature helps prevent overload, ensures smoother performance, and enhances the user experience by making it easier to navigate through data, thus avoiding limit errors. Pagination is available for the following endpoints:

* [Get Execution Results](./endpoint/get-execution-result)
* [Get Execution Results CSV](./endpoint/get-execution-result-csv)
* [Get Query Results](./endpoint/get-query-result)
* [Get Query Results CSV](./endpoint/get-query-result-csv)

Pagination can be effectively combined with [filtering](./filtering) and [sorting](./sorting) to optimize data fetching.

#### Example Paginating Request

<Tabs>
  <Tab title="Python SDK">
    ```python theme={null}
    # When using higher level functions like `get_latest_result_dataframe`, 
    # pagination via `limit` param is done automatically behind the scenes 
    # to get all rows in the result set.
    # 
    # To actually paginate manually, i.e., 
    # limit the number of rows each call returns, 
    # use a lower level function like `get_execution_results_csv`.

    from dune_client.client import DuneClient

    # setup Dune Python client
    dune = DuneClient()

    # Higher level function, let pagination be handled automatically and get full query result
    query = QueryBase(
        query_id=3567562 # https://dune.com/queries/3568055 -> DEX Pair Stats
    )

    query_result = dune.get_latest_result_dataframe(
        query=query
        , filters="overtip_amount > 0"
        , sort_by=["overall_tip_given_amount desc"]
    ) 

    print(query_result)

    # Lower level function, paginate manually to actually get a subset of results one chunk at a time 
    query_result2 = dune.get_execution_results(
        job_id = '01HTJ5J9R1D366ZQ08S5B40P0W'
        , limit = 100
        , filters="overtip_amount > 0"
        , sort_by=["overall_tip_given_amount desc"]
    ) 

    print("next_uri = " + query_result2.next_uri + "\n")
    print("next_offset = " + str(query_result2.next_offset) + "\n")
    print(query_result2.result.rows)

    ```
  </Tab>

  <Tab title="cURL">
    ```bash theme={null}
    curl -X GET 'https://api.dune.com/api/v1/query/{{query_id}}/results?limit=1000' -H 'x-dune-api-key: {{api_key}}'
    ```
  </Tab>

  <Tab title="Python">
    ```python theme={null}
    import requests

    url = "https://api.dune.com/api/v1/query/{query_id}/results"

    headers = {"X-DUNE-API-KEY": "<x-dune-api-key>"}

    params = {"limit": 1000, "offset": 0}  # Define limit and offset parameters

    response = requests.request("GET", url, headers=headers, params=params)

    print(response.text)

    ```
  </Tab>

  <Tab title="Javascript">
    ```javascript theme={null}

    const options = {
        method: 'GET',
        headers: {
            'X-DUNE-API-KEY': '<x-dune-api-key>'
        }
    };

    const queryParams = new URLSearchParams({limit: 1000, offset: 0});  // Define limit and offset parameters
    const url = `https://api.dune.com/api/v1/query/{query_id}/results?${queryParams}`;

    fetch(url, options)
        .then(response => response.json())
        .then(response => console.log(response))
        .catch(err => console.error(err));


    ```
  </Tab>

  <Tab title="Go">
    ```go theme={null}

    package main

    import (
        "fmt"
        "net/http"
        "io/ioutil"
        "net/url"
    )

    func main() {
        url := "https://api.dune.com/api/v1/query/{query_id}/results"

        // Create query parameters
        params := url.Values{}
        params.Set("limit", "1000")

        // Add parameters to URL
        fullURL := fmt.Sprintf("%s?%s", url, params.Encode())

        req, _ := http.NewRequest("GET", fullURL, nil)

        req.Header.Add("X-DUNE-API-KEY", "<x-dune-api-key>")

        res, _ := http.DefaultClient.Do(req)

        defer res.Body.Close()
        body, _ := ioutil.ReadAll(res.Body)

        fmt.Println(res)
        fmt.Println(string(body))
    }
    ```
  </Tab>

  <Tab title="PHP">
    ```php theme={null}
    <?php

    $curl = curl_init();

    $url = "https://api.dune.com/api/v1/query/{query_id}/results";
    $queryParams = http_build_query([
        'limit' => 1000,
        'offset' => 0
    ]);
    $url .= '?' . $queryParams;

    curl_setopt_array($curl, [
        CURLOPT_URL => $url,
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_ENCODING => "",
        CURLOPT_MAXREDIRS => 10,
        CURLOPT_TIMEOUT => 30,
        CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
        CURLOPT_CUSTOMREQUEST => "GET",
        CURLOPT_HTTPHEADER => [
            "X-DUNE-API-KEY: <x-dune-api-key>"
        ],
    ]);

    $response = curl_exec($curl);
    $err = curl_error($curl);

    curl_close($curl);

    if ($err) {
        echo "cURL Error #:" . $err;
    } else {
        echo $response;
    }
    ?>
    ```
  </Tab>

  <Tab title="Java">
    ```java theme={null}

    import kong.unirest.HttpResponse;
    import kong.unirest.Unirest;

    public class Main {
        public static void main(String[] args) {
            HttpResponse<String> response = Unirest.get("https://api.dune.com/api/v1/query/{query_id}/results")
                    .header("X-DUNE-API-KEY", "<x-dune-api-key>")
                    .queryString("limit", 1000)
                    .queryString("offset", 0)
                    .asString();

            System.out.println(response.getBody());
        }
    }
    ```
  </Tab>
</Tabs>

To paginate through results:

1. Use the `limit` parameter to set the maximum number of results per request.
2. The `offset` parameter defines the starting point for the data retrieval, with a default value of 0 (the first row).
3. For JSON responses, the `next_offset` and `next_uri` fields in the response body indicate how to fetch the next page. For CSV responses, look for the `X-Dune-Next-Offset` and `X-Dune-Next-Uri` headers. The server may adjust the provided limit if deemed too large, ensuring efficient data handling. Follow these indicators to navigate through the dataset seamlessly.

### Pagination Parameters

#### `limit` (required)

* **Type:** `integer`
* **Description:** Specifies the maximum number of rows to return in a single request, controlling the page size for pagination.

#### `offset`

* **Type:** `integer`
* **Description:** Determines the starting point for data retrieval, allowing for sequential access through the dataset.
* **Default:** 0 (the first row)
* **Usage:** Use in conjunction with `limit` to navigate through results in an efficient, incremental manner.

### Pagination in Response

The following fields in the response body are related to pagination and can be utilized when doing paginated get results request. If they are available, you can use them to paginate the next page. If they are not available, that means there are no more results to be fetched.

<Tabs>
  <Tab title="JSON response endpoints">
    **`next_offset`**

    * Type: Integer
    * Description: Provides the offset to use for retrieving the next page of results, if available.

    **`next_uri`**

    * Type: String (URL)
    * Description: Specifies the complete URI to retrieve the next page of results, if available.
  </Tab>

  <Tab title="CSV response endpoints">
    **`x-dune-next-offset`**

    * Type: Integer
    * Description: Provides the offset to use for retrieving the next page of results, if available.

    **`x-dune-next-uri`**

    * Type: String (URL)
    * Description: Specifies the complete URI to retrieve the next page of results, if available.
  </Tab>
</Tabs>

<Note>
  If you pass in an invalid `offset` parameter value, you will get an empty result set. For example, if there are only 25 rows of result data, and you pass in `offset=30`, you will **not** receive an error, but rather an empty result with metadata like this. Note the response field `result.total_row_count`, indicating this result has only 25 rows.

  <Accordion title="Example empty response">
    ```json theme={null}
        {
            "execution_id": "01HPF1299EV69Z08DBKW1B6MJR",
            "query_id": 2616430,
            "is_execution_finished": true,
            "state": "QUERY_STATE_COMPLETED",
            "submitted_at": "2024-02-12T16:05:40.270193Z",
            "expires_at": "2024-05-12T16:05:40.654018Z",
            "execution_started_at": "2024-02-12T16:05:40.312207906Z",
            "execution_ended_at": "2024-02-12T16:05:40.654017085Z",
            "result": {
                "rows": [],
                "metadata": {
                "column_names": [
                    "foo"
                ],
                "row_count": 0,
                "result_set_bytes": 0,
                "total_row_count": 25,
                "total_result_set_bytes": 28,
                "datapoint_count": 0,
                "pending_time_millis": 42,
                "execution_time_millis": 341
                }
            }
        }
    ```
  </Accordion>
</Note>

<Accordion title="Example paginated response">
  ```json theme={null}
      {
          "execution_id": "01HPFJ7VSFXPTA8WPMDKBXE167",
          "query_id": 3426636,
          "is_execution_finished": true,
          "state": "QUERY_STATE_COMPLETED",
          "submitted_at": "2024-02-12T21:05:48.848069Z",
          "expires_at": "2024-05-12T21:05:50.199443Z",
          "execution_started_at": "2024-02-12T21:05:48.863094766Z",
          "execution_ended_at": "2024-02-12T21:05:50.199442351Z",
          "result": {
              "rows": [
                  {
                      "amount_usd": null,
                      "block_date": "2021-06-07 00:00:00.000 UTC",
                      "block_month": "2021-06-01T00:00:00Z",
                      "block_time": "2021-06-07 13:21:10.000 UTC",
                      "blockchain": "bnb",
                      "evt_index": 432,
                      "maker": null,
                      "project": "pancakeswap",
                      "project_contract_address": "0xa41e57459f09a126f358e118b693789d088ea8a0",
                      "taker": "0x88bf5a2e82510847e5dcbf33f44a9f611f1c1df5",
                      "token_bought_address": "0x85e76cbf4893c1fbcb34dcf1239a91ce2a4cf5a7",
                      "token_bought_amount": 2985.646787349244,
                      "token_bought_amount_raw": "2985646787349243786078",
                      "token_bought_symbol": "USDG",
                      "token_pair": "GMT-USDG",
                      "token_sold_address": "0x99e92123eb77bc8f999316f622e5222498438784",
                      "token_sold_amount": 192.8996462242313,
                      "token_sold_amount_raw": "192899646224231304314",
                      "token_sold_symbol": "GMT",
                      "tx_from": "0x88bf5a2e82510847e5dcbf33f44a9f611f1c1df5",
                      "tx_hash": "0xcee1e51083f28655fd9cc434238e2a243aa8f9bad20e717d145f246b5e73e231",
                      "tx_to": "0x10ed43c718714eb63d5aa57b78b54704e256024e"
                  },
                  {
                      "amount_usd": 0.0038254393551350966,
                      "block_date": "2021-06-27 00:00:00.000 UTC",
                      "block_month": "2021-06-01T00:00:00Z",
                      "block_time": "2021-06-27 19:21:48.000 UTC",
                      "blockchain": "bnb",
                      "evt_index": 38,
                      "maker": null,
                      "project": "pancakeswap",
                      "project_contract_address": "0x73c6542f8a529bf7bf0ac27a1d232a8525748738",
                      "taker": "0x10ed43c718714eb63d5aa57b78b54704e256024e",
                      "token_bought_address": "0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c",
                      "token_bought_amount": 0.00001404037053195,
                      "token_bought_amount_raw": "14040370531950",
                      "token_bought_symbol": "WBNB",
                      "token_pair": null,
                      "token_sold_address": "0x3da1fd918a4c56b1cf6280ba37018c211db0d943",
                      "token_sold_amount": null,
                      "token_sold_amount_raw": "23274980840704048977780",
                      "token_sold_symbol": null,
                      "tx_from": "0xc0ffee00d263df1ecb44ece29f63a1e7479b7420",
                      "tx_hash": "0xa37ab410b4802e4d4aab950d1c3ce186abf4dbc98f7d7dbc54af17cf23519444",
                      "tx_to": "0x17f07d78e432b91ccfbed98f0617a83a4bfcc446"
                  },
                  {
                      "amount_usd": 229.4023072060263,
                      "block_date": "2021-06-29 00:00:00.000 UTC",
                      "block_month": "2021-06-01T00:00:00Z",
                      "block_time": "2021-06-29 23:23:56.000 UTC",
                      "blockchain": "bnb",
                      "evt_index": 51,
                      "maker": null,
                      "project": "pancakeswap",
                      "project_contract_address": "0x58f876857a02d6762e0101bb5c46a8c1ed44dc16",
                      "taker": "0xd7d116d7535aa724f8be9c482d2c768bc425a23c",
                      "token_bought_address": "0xe9e7cea3dedca5984780bafc599bd69add087d56",
                      "token_bought_amount": 229.23954712756574,
                      "token_bought_amount_raw": "229239547127565734569",
                      "token_bought_symbol": "BUSD",
                      "token_pair": "BUSD-WBNB",
                      "token_sold_address": "0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c",
                      "token_sold_amount": 0.761872346852129,
                      "token_sold_amount_raw": "761872346852129018",
                      "token_sold_symbol": "WBNB",
                      "tx_from": "0xd7d116d7535aa724f8be9c482d2c768bc425a23c",
                      "tx_hash": "0x21429506dd0323b9ec40f4cf9314e58579aa25620bf95130f3a275a356ecd64c",
                      "tx_to": "0x10ed43c718714eb63d5aa57b78b54704e256024e"
                  },
                  {
                      "amount_usd": 2.668233112736453,
                      "block_date": "2021-06-04 00:00:00.000 UTC",
                      "block_month": "2021-06-01T00:00:00Z",
                      "block_time": "2021-06-04 00:11:44.000 UTC",
                      "blockchain": "bnb",
                      "evt_index": 384,
                      "maker": null,
                      "project": "pancakeswap",
                      "project_contract_address": "0x16b9a82891338f9ba80e2d6970fdda79d1eb0dae",
                      "taker": "0x452c012e55f7a27d3c25caf15fddfc5d63004cd5",
                      "token_bought_address": "0x55d398326f99059ff775485246999027b3197955",
                      "token_bought_amount": 2.662657507914879,
                      "token_bought_amount_raw": "2662657507914878729",
                      "token_bought_symbol": "USDT",
                      "token_pair": "USDT-WBNB",
                      "token_sold_address": "0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c",
                      "token_sold_amount": 0.00632140891710662,
                      "token_sold_amount_raw": "6321408917106620",
                      "token_sold_symbol": "WBNB",
                      "tx_from": "0x452c012e55f7a27d3c25caf15fddfc5d63004cd5",
                      "tx_hash": "0x540ae87272f0fcce54595e7c2b67b9ef32cf2d0b5ccfa23c73a21727ae3350ba",
                      "tx_to": "0x10ed43c718714eb63d5aa57b78b54704e256024e"
                  },
                  {
                      "amount_usd": 46.95293131078031,
                      "block_date": "2021-06-25 00:00:00.000 UTC",
                      "block_month": "2021-06-01T00:00:00Z",
                      "block_time": "2021-06-25 18:24:20.000 UTC",
                      "blockchain": "bnb",
                      "evt_index": 105,
                      "maker": null,
                      "project": "pancakeswap",
                      "project_contract_address": "0x446f87f15d9a9f15b39d1b24d1d6d7e606e9d32d",
                      "taker": "0x10ed43c718714eb63d5aa57b78b54704e256024e",
                      "token_bought_address": "0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c",
                      "token_bought_amount": 0.16652337675833562,
                      "token_bought_amount_raw": "166523376758335622",
                      "token_bought_symbol": "WBNB",
                      "token_pair": null,
                      "token_sold_address": "0x384f5a9b720349015a27251684c7a1510dd151ba",
                      "token_sold_amount": null,
                      "token_sold_amount_raw": "299011495590365081887",
                      "token_sold_symbol": null,
                      "tx_from": "0x60e028a06d04ecfd041ba415c3b8a63258a6506e",
                      "tx_hash": "0xf5e24e5024ff047210127c87cd12b475354ff84afc4bebc159066f9522daac73",
                      "tx_to": "0x10ed43c718714eb63d5aa57b78b54704e256024e"
                  }
              ],
              "metadata": {
                  "column_names": [
                      "amount_usd",
                      "block_date",
                      "token_bought_symbol",
                      "token_pair",
                      "block_time",
                      "blockchain",
                      "evt_index",
                      "block_month",
                      "maker",
                      "project",
                      "project_contract_address",
                      "taker",
                      "token_bought_address",
                      "token_bought_amount",
                      "token_bought_amount_raw",
                      "token_sold_address",
                      "token_sold_amount",
                      "token_sold_amount_raw",
                      "token_sold_symbol",
                      "tx_from",
                      "tx_hash",
                      "tx_to"
                  ],
                  "row_count": 5,
                  "result_set_bytes": 0,
                  "total_row_count": 10,
                  "total_result_set_bytes": 5639,
                  "datapoint_count": 110,
                  "pending_time_millis": 15,
                  "execution_time_millis": 1336
              }
          },
          "next_uri": "https://api.dune.com/api/v1/execution/01HPFJ7VSFXPTA8WPMDKBXE167/results?limit=1000&offset=5",
          "next_offset": 5
      }
  ```
</Accordion>

<Tip>
  **Data Returned Limit**

  When using pagination, our intention is to use sizes that work well on mobile, with lower data and ram consumption. For this, and to avoid more work on the developer, when the client specifies a very large limit value (for example 500000 rows), instead of returning an error, the server will override this limit to a lower, safer value (for example 30000 rows) and *will always provide* the correct next `offset` and `limit` value to use on the next paginated requests. The exact maximum limit value is subject to change.

  **Data Size Limit**

  Dune internally has a maximum query result size limit (which currently is 32GB). If your query yields more than 32GB of data, the result will be truncated in storage. In such cases, pulling the result data (using pagination) but without specifying `allow_partial_results` set to true will trigger an error message: "error": "Partial Result, please request with 'allows\_partial\_results=true'". If you wish to retrieve partial results, you can pass the parameter `allow_partial_results=true`. But please make sure you indeed want to fetch the truncated result.

  So what? Related to pagination, this means that

  * For query results under 32GB, use the API as normal.
  * When your query results exceed 32GB, in addition to `limit` and `offset` parameters in order to read the partial result (the first 32GB of data), set `allow_partial_results=true`
  * You can use the [Get Status API](./endpoint/get-execution-status) to check the size of your result, `result.result_set_size`
</Tip>


# Sampling
Source: https://docs.dune.com/api-reference/executions/sampling



Our API supports sampling on all `/results` endpoints to provide a uniform sample of the dataset for efficient data analysis and visualization. This feature is particularly useful for use cases like charting (if you only have 4 000 pixels on the chart, then 10 000 datapoints are plenty), where analyzing a full dataset isn't necessary. Sampling returns a subset (with a uniform distribution) of data, optimizing usage of very large results with reduced latency and costs. You can apply sampling to the following endpoints:

* [Get Execution Results](./endpoint/get-execution-result)
* [Get Execution Results CSV](./endpoint/get-execution-result-csv)
* [Get Query Results](./endpoint/get-query-result)
* [Get Query Results CSV](./endpoint/get-query-result-csv)

#### Example Sampling Request

<Tabs>
  <Tab title="Python SDK">
    ```python theme={null}
    from dune_client.client import DuneClient

    # setup Dune Python client
    dune = DuneClient()

    query_result = dune.get_latest_result_dataframe(
        query=3582296 # https://dune.com/queries/3582296 -> OHLC Price
        , sample_count = 5000
    ) 

    print(query_result)

    ```
  </Tab>

  <Tab title="cURL">
    ```bash theme={null}
    curl -X GET "https://api.dune.com/api/v1/query/{{query_id}}/results?sample_count=10000" -H "x-dune-api-key: {{api_key}}"
    ```
  </Tab>

  <Tab title="Python">
    ```python theme={null}
    import requests

    url = "https://api.dune.com/api/v1/query/{query_id}/results"

    headers = {"X-DUNE-API-KEY": "<x-dune-api-key>"}

    params = {"sample_count": 10_000}

    response = requests.request("GET", url, headers=headers, params=params)

    print(response.text)

    ```
  </Tab>

  <Tab title="Javascript">
    ```javascript theme={null}

    const options = {
        method: 'GET',
        headers: {
            'X-DUNE-API-KEY': '<x-dune-api-key>'
        }
    };

    const queryParams = new URLSearchParams({
        sample_count: 10000
    });
    const url = `https://api.dune.com/api/v1/query/{query_id}/results?${queryParams}`;

    fetch(url, options)
        .then(response => response.json())
        .then(response => console.log(response))
        .catch(err => console.error(err));


    ```
  </Tab>
</Tabs>

### Sampling Parameters

#### `sample_count`

* **Type:** `integer`
* **Description:** Determines the number of rows to return as a sample from the result set. If the available dataset contains fewer rows than the specified `sample_count`, the entire dataset is returned.

<Note>
  - Sampling is designed to provide a randomized subset of data, with each request potentially producing different outcomes.
  - When specifying `sample_count` (e.g., `sample_count = 10000`), the number is approximate. The actual number of rows returned may vary slightly (e.g., 10013, 10017), reflecting the probabilistic nature of the sampling process.
  - `sample_count` is incompatible with `offset`, `limit`, and `filters` parameters.
  - `sample_count` can be used with `columns` to specify which data fields to include in the sample.
  - Specifying a low `sample_count` relative to total rows, being probabilistic, may return 0 rows due to the probability based sampling calculation (e.g., 10 in 100,000, means each row has \~0.01% chance to be included)
</Note>

### Sampling Response

<Accordion title="Example sampling response">
  *Showing trimmed response for `sample_count=200` instead of specified `sample_count=10000` in example request to not overwhelm the doc.*

  ```json theme={null}
      {
          "execution_id": "01HR8D39V7N8WM653SVDW2G9WB",
          "query_id": 3494402,
          "is_execution_finished": true,
          "state": "QUERY_STATE_COMPLETED",
          "submitted_at": "2024-03-05T22:52:39.144099Z",
          "expires_at": "2024-06-03T22:54:03.004092Z",
          "execution_started_at": "2024-03-05T22:52:39.348798256Z",
          "execution_ended_at": "2024-03-05T22:54:03.00409093Z",
          "result": {
              "rows": [
                  {
                      "amount_usd": 28.517144710689454,
                      "block_time": "2024-03-02 12:51:19.000 UTC",
                      "blockchain": "bnb"
                  },
                  {
                      "amount_usd": 4892.433,
                      "block_time": "2024-03-05 13:42:59.000 UTC",
                      "blockchain": "ethereum"
                  },
                  {
                      "amount_usd": 31.579160400723985,
                      "block_time": "2024-03-04 20:17:56.000 UTC",
                      "blockchain": "bnb"
                  },
                  {
                      "amount_usd": 84.162,
                      "block_time": "2024-03-05 07:26:54.000 UTC",
                      "blockchain": "bnb"
                  },
                  {
                      "amount_usd": 1.5276341414539407,
                      "block_time": "2024-03-03 12:32:44.000 UTC",
                      "blockchain": "bnb"
                  },
                  {
                      "amount_usd": 876.1714568508686,
                      "block_time": "2024-03-05 02:14:47.000 UTC",
                      "blockchain": "fantom"
                  },
                  {
                      "amount_usd": 4529.057,
                      "block_time": "2024-03-04 00:18:11.000 UTC",
                      "blockchain": "ethereum"
                  },
                  {
                      "amount_usd": 201.94357555355361,
                      "block_time": "2024-02-25 22:33:23.000 UTC",
                      "blockchain": "ethereum"
                  },
                  {
                      "amount_usd": 145.27394384575086,
                      "block_time": "2024-03-04 10:54:32.000 UTC",
                      "blockchain": "bnb"
                  },
                  {
                      "amount_usd": 1070.7173780527592,
                      "block_time": "2024-03-04 13:57:21.000 UTC",
                      "blockchain": "bnb"
                  },
                  {
                      "amount_usd": 223.82524240905198,
                      "block_time": "2024-03-02 08:31:15.000 UTC",
                      "blockchain": "polygon"
                  },
                  {
                      "amount_usd": 1950.3639893741088,
                      "block_time": "2024-03-03 05:09:47.000 UTC",
                      "blockchain": "ethereum"
                  },
                  {
                      "amount_usd": 719.5529722030446,
                      "block_time": "2024-03-05 09:27:23.000 UTC",
                      "blockchain": "bnb"
                  },
                  {
                      "amount_usd": 6.89141479932381,
                      "block_time": "2024-03-01 03:35:39.000 UTC",
                      "blockchain": "bnb"
                  },
                  {
                      "amount_usd": 368.6550396139464,
                      "block_time": "2024-03-04 11:05:35.000 UTC",
                      "blockchain": "bnb"
                  },
                  {
                      "amount_usd": 105.21798800684901,
                      "block_time": "2024-03-05 16:04:47.000 UTC",
                      "blockchain": "bnb"
                  },
                  {
                      "amount_usd": 31.17956089030626,
                      "block_time": "2024-03-05 18:17:05.000 UTC",
                      "blockchain": "polygon"
                  },
                  {
                      "amount_usd": 43.21002361278373,
                      "block_time": "2024-03-03 14:40:21.000 UTC",
                      "blockchain": "bnb"
                  },
                  {
                      "amount_usd": 1448.8800596106462,
                      "block_time": "2024-03-02 12:47:21.000 UTC",
                      "blockchain": "base"
                  },
                  {
                      "amount_usd": 0.01001462,
                      "block_time": "2024-03-03 02:18:02.000 UTC",
                      "blockchain": "bnb"
                  },
                  {
                      "amount_usd": 43.94295029931569,
                      "block_time": "2024-03-02 13:25:28.000 UTC",
                      "blockchain": "bnb"
                  },
                  {
                      "amount_usd": 608.562,
                      "block_time": "2024-02-25 13:13:11.000 UTC",
                      "blockchain": "ethereum"
                  },
                  {
                      "amount_usd": 85.02994808708173,
                      "block_time": "2024-02-25 15:36:48.000 UTC",
                      "blockchain": "bnb"
                  },
                  {
                      "amount_usd": 2849.089609803931,
                      "block_time": "2024-02-25 21:21:23.000 UTC",
                      "blockchain": "ethereum"
                  },
                  {
                      "amount_usd": 742.1382966435165,
                      "block_time": "2024-02-26 09:23:10.000 UTC",
                      "blockchain": "bnb"
                  },
                  {
                      "amount_usd": 1523.857600998093,
                      "block_time": "2024-02-26 21:29:40.000 UTC",
                      "blockchain": "bnb"
                  },
                  {
                      "amount_usd": 1.000853,
                      "block_time": "2024-02-25 22:25:16.000 UTC",
                      "blockchain": "bnb"
                  },
                  {
                      "amount_usd": 187.32483603639648,
                      "block_time": "2024-02-26 05:38:59.000 UTC",
                      "blockchain": "ethereum"
                  },
                  {
                      "amount_usd": 9.365232080867631,
                      "block_time": "2024-03-04 21:59:33.000 UTC",
                      "blockchain": "polygon"
                  },
                  {
                      "amount_usd": 7.85318483149416,
                      "block_time": "2024-02-28 02:39:53.000 UTC",
                      "blockchain": "bnb"
                  },
                  {
                      "amount_usd": 62.43033115744735,
                      "block_time": "2024-02-27 06:40:47.000 UTC",
                      "blockchain": "base"
                  },
                  {
                      "amount_usd": 245.49353625178662,
                      "block_time": "2024-02-27 08:02:35.000 UTC",
                      "blockchain": "bnb"
                  },
                  {
                      "amount_usd": 2.1101359357968,
                      "block_time": "2024-02-28 17:24:20.000 UTC",
                      "blockchain": "polygon"
                  },
                  {
                      "amount_usd": 887.988462523146,
                      "block_time": "2024-02-29 08:56:34.000 UTC",
                      "blockchain": "polygon"
                  },
                  {
                      "amount_usd": null,
                      "block_time": "2024-02-27 16:20:57.000 UTC",
                      "blockchain": "optimism"
                  },
                  {
                      "amount_usd": 0.9971501669140281,
                      "block_time": "2024-03-05 20:28:38.000 UTC",
                      "blockchain": "polygon"
                  },
                  {
                      "amount_usd": 16.03705776420069,
                      "block_time": "2024-03-03 23:27:03.000 UTC",
                      "blockchain": "base"
                  },
                  {
                      "amount_usd": 5.38636576521727,
                      "block_time": "2024-03-01 23:00:13.000 UTC",
                      "blockchain": "base"
                  },
                  {
                      "amount_usd": 30.130297357061917,
                      "block_time": "2024-02-27 02:20:07.000 UTC",
                      "blockchain": "bnb"
                  }
              ],
              "metadata": {
                  "column_names": [
                      "blockchain",
                      "block_time",
                      "amount_usd"
                  ],
                  "row_count": 213,
                  "result_set_bytes": 12119,
                  "total_row_count": 22325371,
                  "total_result_set_bytes": 1175314615,
                  "datapoint_count": 639,
                  "pending_time_millis": 204,
                  "execution_time_millis": 83655
              }
          }
      }
  ```
</Accordion>


# Sorting
Source: https://docs.dune.com/api-reference/executions/sorting



Our API allows for sorting on all `/results` endpoints to organize query results in a specified order. This sorting functionality enables users to retrieve data in a manner that best suits their needs, whether ascending or descending. The feature is designed to work in a similar fashion to a SQL `ORDER BY` clause and is available for the following endpoints:

* [Get Execution Results](./endpoint/get-execution-result)
* [Get Execution Results CSV](./endpoint/get-execution-result-csv)
* [Get Query Results](./endpoint/get-query-result)
* [Get Query Results CSV](./endpoint/get-query-result-csv)

Sorting can be effectively combined with [pagination](./pagination), [filtering](./filtering) and [sampling](./sampling) to optimize data retrieval.

#### Example Sorting Request

<Tabs>
  <Tab title="Python SDK">
    ```python theme={null}
    from dune_client.client import DuneClient

    # setup Dune Python client
    dune = DuneClient()

    query_result = dune.get_latest_result_dataframe(
        query=3567562 # https://dune.com/queries/3567562
        , filters="overtip_amount > 0"
        , columns=["donor_fname","overtip_amount","days_overtipped","overall_tip_given_amount","overall_avg_tip_amount"]
        , sort_by=["overall_tip_given_amount desc"]
    ) 

    print(query_result)

    ```
  </Tab>

  <Tab title="cURL">
    ```bash theme={null}
    curl -X GET 'https://api.dune.com/api/v1/query/{{query_id}}/results?limit=100&filters=chain%20in%20(%27base%27%2C%20%27optimism%27)%20and%20token_pair%20like%20%27%USDC%%27&sort_by=thirty_day_volume%20desc' \
    -H 'x-dune-api-key:{{api_key}}’
    ```
  </Tab>

  <Tab title="Python">
    ```python theme={null}
    import requests

    url = "https://api.dune.com/api/v1/query/{query_id}/results"

    headers = {"X-DUNE-API-KEY": "<x-dune-api-key>"}

    params = {
        "limit": 10, 
        "filters": "block_time > '2024-03-01'",
        "columns": "tx_from,tx_to,tx_hash,amount_usd",
        "sort_by": "amount_usd desc, block_time"
        }

    response = requests.request("GET", url, headers=headers, params=params)

    print(response.text)

    ```
  </Tab>

  <Tab title="Javascript">
    ```javascript theme={null}

    const options = {
        method: 'GET',
        headers: {
            'X-DUNE-API-KEY': '<x-dune-api-key>'
        }
    };

    const queryParams = new URLSearchParams({
        limit: 10, 
        filters: "block_time > '2024-03-01'",
        columns: "tx_from,tx_to,tx_hash,amount_usd",
        sort_by: "amount_usd desc, block_time"
    });
    const url = `https://api.dune.com/api/v1/query/{query_id}/results?${queryParams}`;

    fetch(url, options)
        .then(response => response.json())
        .then(response => console.log(response))
        .catch(err => console.error(err));


    ```
  </Tab>

  <Tab title="Go">
    ```go theme={null}

    package main

    import (
        "fmt"
        "net/http"
        "io/ioutil"
        "net/url"
    )

    func main() {
        url := "https://api.dune.com/api/v1/query/{query_id}/results"

        // Create query parameters
        params := url.Values{}
        params.Set("limit", 10)
        params.Set("filters", "block_time > '2024-03-01'")
        params.Set("columns", "tx_from,tx_to,tx_hash,amount_usd")
        params.Set("sort_by", "amount_usd desc, block_time")

        // Add parameters to URL
        fullURL := fmt.Sprintf("%s?%s", url, params.Encode())

        req, _ := http.NewRequest("GET", fullURL, nil)

        req.Header.Add("X-DUNE-API-KEY", "<x-dune-api-key>")

        res, _ := http.DefaultClient.Do(req)

        defer res.Body.Close()
        body, _ := ioutil.ReadAll(res.Body)

        fmt.Println(res)
        fmt.Println(string(body))
    }
    ```
  </Tab>

  <Tab title="PHP">
    ```php theme={null}
    <?php

    $curl = curl_init();

    $url = "https://api.dune.com/api/v1/query/{query_id}/results";
    $queryParams = http_build_query([
        'limit' => 10,
        'filters' => "block_time > '2024-03-01'",
        'columns' => "tx_from,tx_to,tx_hash,amount_usd",
        'sort_by' => "amount_usd desc, block_time",
    ]);
    $url .= '?' . $queryParams;

    curl_setopt_array($curl, [
        CURLOPT_URL => $url,
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_ENCODING => "",
        CURLOPT_MAXREDIRS => 10,
        CURLOPT_TIMEOUT => 30,
        CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
        CURLOPT_CUSTOMREQUEST => "GET",
        CURLOPT_HTTPHEADER => [
            "X-DUNE-API-KEY: <x-dune-api-key>"
        ],
    ]);

    $response = curl_exec($curl);
    $err = curl_error($curl);

    curl_close($curl);

    if ($err) {
        echo "cURL Error #:" . $err;
    } else {
        echo $response;
    }
    ?>
    ```
  </Tab>

  <Tab title="Java">
    ```java theme={null}

    import kong.unirest.HttpResponse;
    import kong.unirest.Unirest;

    public class Main {
        public static void main(String[] args) {
            HttpResponse<String> response = Unirest.get("https://api.dune.com/api/v1/query/{query_id}/results")
                    .header("X-DUNE-API-KEY", "<x-dune-api-key>")
                    .queryString("limit", 10)
                    .queryString("filters", "block_time > '2024-03-01'")
                    .queryString("columns", "tx_from,tx_to,tx_hash,amount_usd")
                    .queryString("sort_by", "amount_usd desc, block_time")
                    .asString();

            System.out.println(response.getBody());
        }
    }
    ```
  </Tab>
</Tabs>

### Sorting Parameters

#### `sort_by`

* **Type:** `string`
* **Description:** Specifies the order in which query results are returned. It directly mirrors the functionality of an SQL `ORDER BY` clause.

<Note>
  - Specify the sorting criteria using the format `<column_name> asc|desc`. For example, `block_time desc`.
  - If a column name contains special characters, enclose it in double quotes, e.g., `"special,column" asc`.
  - You can sort by multiple columns by separating them with a comma, exactly like in SQL. For instance, `amount_usd desc, block_time`.
  - By default, sorting is in ascending order if not explicitly specified. Explicitly include `asc` or `desc` to define the sorting order.
</Note>

### Sorted Response

<Accordion title="Example sorted response">
  ```json theme={null}
      {
          "execution_id": "01HR8AGD6CWGHGP1BN3Z1SJ4MD",
          "query_id": 3493826,
          "is_execution_finished": true,
          "state": "QUERY_STATE_COMPLETED",
          "submitted_at": "2024-03-05T22:07:22.828653Z",
          "expires_at": "2024-06-03T22:07:53.36647Z",
          "execution_started_at": "2024-03-05T22:07:24.013663281Z",
          "execution_ended_at": "2024-03-05T22:07:53.366469062Z",
          "result": {
              "rows": [
                  {
                      "amount_usd": null,
                      "block_time": "2024-03-05 20:50:59.000 UTC",
                      "tx_from": "0x38032f326436fdb9c7a9b359e90010f86b8ab482",
                      "tx_hash": "0xce6f59cf2f0b395d8fc33e49d1f5db5686be95555135fd8126bc7c59327cd9be",
                      "tx_to": "0x061b87122ed14b9526a813209c8a59a633257bab"
                  },
                  {
                      "amount_usd": null,
                      "block_time": "2024-03-05 20:49:33.000 UTC",
                      "tx_from": "0xb46b909be665d75f833be22c6e6285ba5ad74dfa",
                      "tx_hash": "0x1f1725ebe374b1ffb50047055b793b2be6a8cb07ab75fd685b95e842953da4ca",
                      "tx_to": "0x1111111254eeb25477b68fb85ed929f73a960582"
                  },
                  {
                      "amount_usd": null,
                      "block_time": "2024-03-05 20:48:53.000 UTC",
                      "tx_from": "0x40014275b332f38423fa0de39939d26c7294ffc0",
                      "tx_hash": "0xb4364656c20007fb1d7bfa93d87fc6fe345a91b10661835d1a54d1ac7761a244",
                      "tx_to": "0x1111111254eeb25477b68fb85ed929f73a960582"
                  },
                  {
                      "amount_usd": 1397.903560808159,
                      "block_time": "2024-03-05 20:48:03.000 UTC",
                      "tx_from": "0xb46b909be665d75f833be22c6e6285ba5ad74dfa",
                      "tx_hash": "0x818f701a6c7dcf78a090cfd8324da5896005c2a6d8e3ec5ac2c29cfa5e67f5d9",
                      "tx_to": "0x1111111254eeb25477b68fb85ed929f73a960582"
                  },
                  {
                      "amount_usd": null,
                      "block_time": "2024-03-05 20:47:55.000 UTC",
                      "tx_from": "0x50758bdc1735e94401ed73eb7e8bde482766819c",
                      "tx_hash": "0x1dc342dc397ffa7b433fa64280fe9f4a7e0b51409e9abc9fde61bc9b85c938be",
                      "tx_to": "0x4c4af8dbc524681930a27b2f1af5bcc8062e6fb7"
                  },
                  {
                      "amount_usd": null,
                      "block_time": "2024-03-05 20:47:55.000 UTC",
                      "tx_from": "0x50758bdc1735e94401ed73eb7e8bde482766819c",
                      "tx_hash": "0x1dc342dc397ffa7b433fa64280fe9f4a7e0b51409e9abc9fde61bc9b85c938be",
                      "tx_to": "0x4c4af8dbc524681930a27b2f1af5bcc8062e6fb7"
                  },
                  {
                      "amount_usd": null,
                      "block_time": "2024-03-05 20:47:53.000 UTC",
                      "tx_from": "0xfa3dc8db10e7c2f7dfa87e86bba6257066731bc1",
                      "tx_hash": "0x0d34634a9438ce241e2870b23e70a008c8db839ba38daadc1074c9b1a52be7c7",
                      "tx_to": "0xba12222222228d8ba445958a75a0704d566bf2c8"
                  },
                  {
                      "amount_usd": 2.753641952846242,
                      "block_time": "2024-03-05 20:47:53.000 UTC",
                      "tx_from": "0xfa3dc8db10e7c2f7dfa87e86bba6257066731bc1",
                      "tx_hash": "0x0d34634a9438ce241e2870b23e70a008c8db839ba38daadc1074c9b1a52be7c7",
                      "tx_to": "0xba12222222228d8ba445958a75a0704d566bf2c8"
                  },
                  {
                      "amount_usd": null,
                      "block_time": "2024-03-05 20:47:53.000 UTC",
                      "tx_from": "0xfa3dc8db10e7c2f7dfa87e86bba6257066731bc1",
                      "tx_hash": "0x0d34634a9438ce241e2870b23e70a008c8db839ba38daadc1074c9b1a52be7c7",
                      "tx_to": "0xba12222222228d8ba445958a75a0704d566bf2c8"
                  },
                  {
                      "amount_usd": 1798.8186143812122,
                      "block_time": "2024-03-05 20:47:49.000 UTC",
                      "tx_from": "0xb46b909be665d75f833be22c6e6285ba5ad74dfa",
                      "tx_hash": "0xcf8d9873f017a8ba9e624c3bb61bede8e11c194965690026cd394f20c55f896a",
                      "tx_to": "0x1111111254eeb25477b68fb85ed929f73a960582"
                  }
              ],
              "metadata": {
                  "column_names": [
                      "block_time",
                      "tx_from",
                      "tx_to",
                      "tx_hash",
                      "amount_usd"
                  ],
                  "row_count": 10,
                  "result_set_bytes": 2042,
                  "total_row_count": 100,
                  "total_result_set_bytes": 56496,
                  "datapoint_count": 50,
                  "pending_time_millis": 1185,
                  "execution_time_millis": 29352
              }
          },
          "next_uri": "https://api.dune.com/api/v1/execution/01HR8AGD6CWGHGP1BN3Z1SJ4MD/results?columns=block_time%2Ctx_from%2Ctx_to%2Ctx_hash%2Camount_usd&filters=block_time+%3E+%272024-03-01%27&limit=10&offset=10",
          "next_offset": 10
      }
  ```
</Accordion>


# Upsert Materialized View
Source: https://docs.dune.com/api-reference/materialized-views/create

POST /v1/materialized-views
This upserts a materialized view from an existing query. If the materialized view with the given name

<Info>
  Minimum required API key scope: `Read/Write`
</Info>

<Note>
  * This endpoint will create a new matview if none exists for the given query ID, or update an existing one if the query ID matches.
  * It will fail to create a matview with the same name as an existing one, but for a different query ID
  * The name of the matview is just the last part of the matview, not including `dune.<your_team>.` and must be prefixed with `result_`
  * The `cron_expression` parameter must be passed in as a valid 5 section cron expression. [See here](https://crontab.guru/) for how to write them.
</Note>

<Tip>
  * The cron expression interval must be at least 15 minutes and at most weekly
</Tip>


# Delete Materialized View
Source: https://docs.dune.com/api-reference/materialized-views/delete

DELETE /v1/materialized-views/{name}
This deletes a materialized view given a full name

<Info>
  Minimum required API key scope: `Read/Write`
</Info>

<Note>
  * The name must be the full name qualifier for the materialized view, i.e. `dune.<your_team>.<name>`
</Note>


# Get Materialized View
Source: https://docs.dune.com/api-reference/materialized-views/get

GET /v1/materialized-views/{name}
This fetches a materialized view given a name

<Info>
  Minimum required API key scope: `Read`
</Info>

<Note>
  * The name must be the full name qualifier for the materialized view, i.e. `dune.<your_team>.<name>`
</Note>


# List Materialized Views
Source: https://docs.dune.com/api-reference/materialized-views/list

GET /v1/materialized-views
This lists all materialized view owned by the account tied to the API key

<Info>
  Minimum required API key scope: `Read`
</Info>

<Note>
  * This endpoint will list all the materialized views under the ownership of the account tied to the API key used
</Note>


# Overview
Source: https://docs.dune.com/api-reference/materialized-views/overview



The materialized views endpoints allow you to create, manage, and refresh materialized views programmatically via the API.

<Info>
  Materialized views store the results of a query as a table that can be queried like any other table, enabling you to build data pipelines within Dune. To learn more about how materialized views work, see the [Materialized Views page](/query-engine/materialized-views).
</Info>

<Note>
  Materialized views contribute to your storage quota. On the free tier you can only create a 1MB materialized view. Learn more at [dune.com/pricing](https://dune.com/pricing)
</Note>

## Naming Convention

Materialized view names must follow these rules:

* The full name qualifier is `dune.<your_team>.<name>`
* The name (last part) must be prefixed with `result_`
* Example: `dune.myteam.result_daily_volume`

## Endpoints

Below is an overview of each endpoint for managing materialized views.

| Endpoint Title                         | Endpoint                                     | Description                                                         |
| -------------------------------------- | -------------------------------------------- | ------------------------------------------------------------------- |
| [Get Materialized View](./get)         | `GET /v1/materialized-views/{name}`          | Retrieves details about a specific materialized view                |
| [Upsert Materialized View](./create)   | `POST /v1/materialized-views`                | Creates a new materialized view or updates an existing one          |
| [Delete Materialized View](./delete)   | `DELETE /v1/materialized-views/{name}`       | Removes a materialized view                                         |
| [List Materialized Views](./list)      | `GET /v1/materialized-views`                 | Lists all materialized views for your account                       |
| [Refresh Materialized View](./refresh) | `POST /v1/materialized-views/{name}/refresh` | Triggers a refresh to update the materialized view with latest data |

## Refresh and Performance Tiers

Each refresh of a materialized view triggers a query execution and consumes credits based on the performance level:

* **Medium**: Extended timeout, 1x compute, priority queue. Best for most queries.
* **Large**: Extended timeout, 2x compute, priority queue. For complex queries with joins across large tables.

You can set a refresh schedule using cron expressions (minimum 15 minutes, maximum weekly) when creating or updating a materialized view.


# Refresh Materialized View
Source: https://docs.dune.com/api-reference/materialized-views/refresh

POST /v1/materialized-views/{name}/refresh
This refreshes a materialized view

<Info>
  Minimum required API key scope: `Read`
</Info>

This endpoint refreshes a materialized view, triggering a new execution to update its data.

<Note>
  * By default, the refresh runs on the `medium` engine. To boost performance, pass in a JSON body with `{{"performance": "large"}}`. Credits are consumed based on actual compute resources used for the refresh operation.
  * If you prefer `medium` performance, you can omit the `performance` parameter.
  * You must own the materialized view to refresh it.
</Note>

## Path Parameters

<ParamField type="string">
  The name of the materialized view to refresh
</ParamField>

## Request Body

<ParamField type="string">
  Performance level of the refresh. Available options: `medium`, `large`. Defaults to `medium`.

  * `medium`: Extended timeout, 1x compute, priority queue. Best for most queries.
  * `large`: Extended timeout, 2x compute, priority queue. For complex queries.
</ParamField>

## Response

<ResponseField name="execution_id" type="string">
  Unique identifier for the execution triggered to refresh the materialized view

  Example: `01HZ065JVE23C23FM2HKWQP2RT`
</ResponseField>

<ResponseField name="sql_id" type="string">
  Unique identifier for the materialized view

  Example: `dune.dune.result_erc_20_token_summary`
</ResponseField>

<RequestExample>
  ```bash cURL theme={null}
  curl -X POST "https://api.dune.com/api/v1/materialized-views/my_matview/refresh" \
    -H "X-Dune-Api-Key: YOUR_API_KEY" \
    -H "Content-Type: application/json" \
    -d '{
      "performance": "medium"
    }'
  ```

  ```python Python theme={null}
  import requests

  url = "https://api.dune.com/api/v1/materialized-views/my_matview/refresh"
  headers = {
      "X-Dune-Api-Key": "YOUR_API_KEY",
      "Content-Type": "application/json"
  }
  data = {
      "performance": "medium"
  }

  response = requests.post(url, headers=headers, json=data)
  print(response.json())
  ```

  ```javascript JavaScript theme={null}
  const response = await fetch(
    'https://api.dune.com/api/v1/materialized-views/my_matview/refresh',
    {
      method: 'POST',
      headers: {
        'X-Dune-Api-Key': 'YOUR_API_KEY',
        'Content-Type': 'application/json'
      },
      body: JSON.stringify({
        performance: 'medium'
      })
    }
  );

  const data = await response.json();
  console.log(data);
  ```
</RequestExample>

<ResponseExample>
  ```json 200 OK theme={null}
  {
    "execution_id": "01HZ065JVE23C23FM2HKWQP2RT",
    "sql_id": "dune.dune.result_erc_20_token_summary"
  }
  ```

  ```json 400 Bad Request theme={null}
  {
    "error": "Bad Request"
  }
  ```

  ```json 401 Unauthorized theme={null}
  {
    "error": "Invalid API Key"
  }
  ```

  ```json 404 Not Found theme={null}
  {
    "error": "Object not found"
  }
  ```

  ```json 500 Internal Server Error theme={null}
  {
    "error": "Internal error"
  }
  ```
</ResponseExample>

## Notes

* Refreshing a materialized view triggers a query execution to update the view with the latest data
* Use the returned `execution_id` to check the status of the refresh operation
* Credits are consumed based on actual compute resources used, the performance tier selected, and the amount of data written (e.g., table creation and data insertion)


# Authentication
Source: https://docs.dune.com/api-reference/overview/authentication



The Dune API relies on API keys for authentication. Your API key grants access and determines billing details for private queries, so safeguard it diligently!

## Generate an API key

In order to generate a new API key, go to settings -> API -> create new API key.

<Note>
  * Dune has two types of account: `user` account and `team` account. A team can have many users. A user can join many teams.
  * Each user or team account has its own context. Queries created under a team account can only be managed within the team account context.
  * An API key belongs to a specific context, and is either associated with a user account or a team account.
</Note>

<Tabs>
  <Tab title="Create key for user account">
    <div>
      <iframe title="Generate a New API Key in Dune" />
    </div>
  </Tab>

  <Tab title="Create key for team account">
    <div>
      <iframe title="Create a New API Key in Dune" />
    </div>
  </Tab>
</Tabs>

<br />

<Warning>
  Never share your secret API keys in public repositories or other accessible areas.
</Warning>

## API key scopes

Each Dune API key is issued with a **scope** that controls what it can do. Endpoints in this reference list the **minimum required API key scope** — keys with broader scopes can also call them.

| Scope        | Access                                                                                                                            |
| ------------ | --------------------------------------------------------------------------------------------------------------------------------- |
| `Read`       | Read-only endpoints (query results, datasets, usage, status checks).                                                              |
| `Read/Write` | Everything `Read` allows, plus mutating endpoints (create/update/archive queries, manage uploads, materialized views, pipelines). |

## Authentication & making API calls

You can authenticate either with the API header or with query parameter to start making API calls. We illustrate below with [execute query endpoint](../executions/endpoint/execute-query) as an example.

<Tabs>
  <Tab title="Header Authentication">
    To authenticate via the API header, include an `x-dune-api-key` property in your request header.

    <Tabs>
      <Tab title="cURL (bash)">
        ```bash theme={null}
        curl -X POST -H x-dune-api-key:{{api_key}} "https://api.dune.com/api/v1/query/{{query_id}}/execute"
        ```
      </Tab>

      <Tab title="Python">
        ```python theme={null}
        import requests

        url = "https://api.dune.com/api/v1/query/{{query_id}}/execute"

        headers = {"X-DUNE-API-KEY": "<x-dune-api-key>"}

        response = requests.request("POST", url, headers=headers)

        print(response.text)
        ```
      </Tab>

      <Tab title="JavaScript">
        ```javascript theme={null}
        const options = {method: 'POST', headers: {'X-DUNE-API-KEY': '<x-dune-api-key>'}};

        fetch('https://api.dune.com/api/v1/query/{{query_id}}/execute', options)
        .then(response => response.json())
        .then(response => console.log(response))
        .catch(err => console.error(err));
        ```
      </Tab>

      <Tab title="Go">
        ```go theme={null}
        package main

        import (
            "fmt"
            "net/http"
            "io/ioutil"
        )

        func main() {

            url := "https://api.dune.com/api/v1/query/{{query_id}}/execute"

            req, _ := http.NewRequest("POST", url, nil)

            req.Header.Add("X-DUNE-API-KEY", "<x-dune-api-key>")

            res, _ := http.DefaultClient.Do(req)

            defer res.Body.Close()
            body, _ := ioutil.ReadAll(res.Body)

            fmt.Println(res)
            fmt.Println(string(body))

        }
        ```
      </Tab>

      <Tab title="PHP">
        ```php theme={null}
        <?php

        $curl = curl_init();

        curl_setopt_array($curl, [
        CURLOPT_URL => "https://api.dune.com/api/v1/query/{{query_id}}/execute",
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_ENCODING => "",
        CURLOPT_MAXREDIRS => 10,
        CURLOPT_TIMEOUT => 30,
        CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
        CURLOPT_CUSTOMREQUEST => "POST",
        CURLOPT_HTTPHEADER => [
            "X-DUNE-API-KEY: <x-dune-api-key>"
        ],
        ]);

        $response = curl_exec($curl);
        $err = curl_error($curl);

        curl_close($curl);

        if ($err) {
        echo "cURL Error #:" . $err;
        } else {
        echo $response;
        }
        ?>
        ```
      </Tab>

      <Tab title="Java">
        ```java theme={null}
        HttpResponse<String> response = Unirest.post("https://api.dune.com/api/v1/query/{{query_id}}/execute")
        .header("X-DUNE-API-KEY", "<x-dune-api-key>")
        .asString();
        ```
      </Tab>
    </Tabs>
  </Tab>

  <Tab title="Query Parameter Authentication">
    Alternatively, use an `api_key` query parameter for authentication.

    <Tabs>
      <Tab title="cURL (bash)">
        ```bash theme={null}
        curl -X POST "https://api.dune.com/api/v1/query/{{query_id}}/execute?api_key={{api_key}}"
        ```
      </Tab>

      <Tab title="Python">
        ```python theme={null}
        import requests

        url = "https://api.dune.com/api/v1/query/{{query_id}}/execute"

        querystring = {"api_key": "<api_key>"}

        response = requests.request("POST", url, params=querystring)

        print(response.text)
        ```
      </Tab>

      <Tab title="JavaScript">
        ```javascript theme={null}
        const options = {
        method: 'POST',
        };

        const apiKey = '<api_key>';
        const queryId = '{{query_id}}';
        const url = `https://api.dune.com/api/v1/query/${queryId}/execute?api_key=${apiKey}`;

        fetch(url, options)
        .then(response => response.json())
        .then(response => console.log(response))
        .catch(err => console.error(err));
        ```
      </Tab>

      <Tab title="Go">
        ```go theme={null}
        package main

        import (
            "fmt"
            "net/http"
            "io/ioutil"
        )

        func main() {
            url := "https://api.dune.com/api/v1/query/{{query_id}}/execute?api_key=<api_key>"

            req, _ := http.NewRequest("POST", url, nil)

            res, _ := http.DefaultClient.Do(req)

            defer res.Body.Close()
            body, _ := ioutil.ReadAll(res.Body)

            fmt.Println(res)
            fmt.Println(string(body))
        }
        ```
      </Tab>

      <Tab title="PHP">
        ```php theme={null}
        <?php

        $curl = curl_init();

        curl_setopt_array($curl, [
            CURLOPT_URL => "https://api.dune.com/api/v1/query/{{query_id}}/execute?api_key=<api_key>",
            CURLOPT_RETURNTRANSFER => true,
            CURLOPT_ENCODING => "",
            CURLOPT_MAXREDIRS => 10,
            CURLOPT_TIMEOUT => 30,
            CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
            CURLOPT_CUSTOMREQUEST => "POST",
        ]);

        $response = curl_exec($curl);
        $err = curl_error($curl);

        curl_close($curl);

        if ($err) {
            echo "cURL Error #:" . $err;
        } else {
            echo $response;
        }
        ?>
        ```
      </Tab>

      <Tab title="Java">
        ```java theme={null}
        HttpResponse<String> response = Unirest.post("https://api.dune.com/api/v1/query/{{query_id}}/execute?api_key=<api_key>")
        .asString();
        ```
      </Tab>
    </Tabs>
  </Tab>
</Tabs>


# Billing
Source: https://docs.dune.com/api-reference/overview/billing



Pricing for API is charged along several dimensions. All details can be found at [dune.com/pricing](https://dune.com/pricing).

<Note>
  Failed executions are charged. If you execute a query but never pull the results, you are only charged for the execution.
</Note>

## Executions

Credits are consumed based on actual compute resources used for each query execution. The performance tier you select affects credit consumption.

## Data Export

Credits are consumed when exporting query results via API or CSV.

| Plan       | Credits per MB Exported |
| ---------- | ----------------------- |
| Free       | 20                      |
| Analyst    | 10                      |
| Plus       | 2                       |
| Enterprise | Custom                  |

## Data Writes

Credits are consumed when writing data (table creation, data insertion, uploads).

| Plan       | Credits per GB Written |
| ---------- | ---------------------- |
| Free       | 3                      |
| Analyst    | 3                      |
| Plus       | 3                      |
| Enterprise | Custom                 |

<Note>
  Minimum charge is 1 credit per write operation.
</Note>

## Storage

Storage limits are per-plan caps, not charged per-credit.

| Plan       | Storage Limit |
| ---------- | ------------- |
| Free       | 100 MB        |
| Analyst    | 1 GB          |
| Plus       | 15 GB         |
| Enterprise | Unlimited     |

## Webhooks (Alerts)

| Plan       | Webhooks |
| ---------- | -------- |
| Free       | 1        |
| Analyst    | 5        |
| Plus       | 5        |
| Enterprise | Custom   |

## Queries Endpoint

Available on Plus and Enterprise plans.

## Data Transformations Billing

Data Transformations is an Enterprise-only feature with usage-based credit consumption.

### Credit Consumption

#### Compute Credits

* Same as Fluid Engine credits for query execution
* Charged based on actual compute resources used
* Depends on query complexity and execution time

#### Write Operations

* **Minimum 1 credit** per write operation
* Scales with data volume (GB written)
* Applied to INSERT, MERGE, CREATE TABLE AS SELECT, etc.

#### Maintenance Operations

* OPTIMIZE, VACUUM, and ANALYZE operations consume credits
* Based on compute resources and data written during maintenance
* Can be automated with dbt post-hooks

See [dbt Connector documentation](/api-reference/connectors/dbt/overview) for more details.


# FAQ
Source: https://docs.dune.com/api-reference/overview/faq



#### What are the differences between the Dune API and the Dune web app?

There are no major performance differences within a specific performance tier when used through the Dune API or Dune web app.

The Dune API gives you programmatic access to the capabilities and data sets that can already be accessed from the Dune web app. The same queries and results exist in the web app, even if created/executed from the API (and vice versa).

#### What are Sim APIs  and how do they differ from the Dune API?

Sim APIs, formerly Echo, are a separate, developer-focused product by Dune, providing realtime access to EVM and SVM blockchain data.
They are designed for building apps like realtime wallets and AI agents.

[Sim APIs](https://sim.dune.com/) have their own documentation at [docs.sim.dune.com](https://docs.sim.dune.com), use a separate API key (`X-Sim-Api-Key`), and are optimized for low latency, realtime use cases.

The Dune API primarily focuses on executing SQL queries you've written on Dune, managing those queries, and uploading data.

#### How many Requests Per Minute can I make?

The API rate limit currently varies by [subscription plan](https://dune.com/pricing). It's currently 40 per minute on Free, 200 per minute on Plus, and custom limits on Enterprise plans.

#### Does Dune support GraphQL on endpoints?

No, we currently don't support GraphQL queries.

#### How do I paginate on my query results?

You currently cannot paginate through the API, we are working on enabling this soon. For now, try and use LIMIT and OFFSET in your query with parameters to paginate manually.

#### Are there specified SLAs?

SLAs are only available on Enterprise pricing plans.

#### How do I find a query id?

When navigating to a query, it’s the first number after “/queries/” in the URL. For example in `https://dune.com/queries/241/388`, "241" is the query id.

#### Does the API support Query Parameters?

Yes, check out [this page](../queries/endpoint/query-object).

#### What is the execution timeout limit and can I request a longer limit?

The query execution timeout limit matches the Dune web app - 30 minutes. You can't request a longer limit.

#### What is the difference between the states “Executing” and “Pending”?

Pending means, the execution is waiting for an available execution connection slot.

Executing means the query is currently executing against the database.

#### Can I ingest data by getting a direct connection to the database instead?

Not currently.

#### Are query results data saved for faster retrieval?

Yes!

#### How long are the results data from an execution stored for?

The results storage period can be found on the API response on the “expires\_at” field in the execution status and results body.

#### How do I import Dune data into a google sheet?

Use "Import Data" to import your CSV results into a google sheet using "api\_key" as a param. (We advise against doing this any public document where your API key can be viewed and compromised.)
`=importData("https://api.dune.com/api/v1/query/{{query_id}}/results/csv?api_key={{api_key}}")`. Then, [schedule a query execution](https://dune.com/docs/app/query-editor/query-scheduler/?h=scheduling) to have your results regularly updated on a set schedule.


# Getting Started
Source: https://docs.dune.com/api-reference/overview/getting-started

Learn how to authenticate and make your first API request to Dune

This guide will walk you through everything you need to get started with Dune's APIs, from creating an API key to making your first request.

## 1. Sign Up

Create your account at [dune.com/auth/register](https://dune.com/auth/register)

New accounts come with free credits to get you started.

## 2. Generate API Key

1. Navigate to [API settings page](https://dune.com/apis?tab=keys)
2. Click **Create API Key**
3. Give your key a descriptive name (e.g., "Production API", "Development")
4. Copy and securely store your API key

<Note>
  * Dune has two types of account: **user** account and **team** account. A team can have many users. A user can join many teams.
  * Each user or team account has its own context. Queries created under a team account can only be managed within the team account context.
  * An API key belongs to a specific context, and is either associated with a user account or a team account.
</Note>

<div>
  <iframe title="Create a New API Key in Dune" />
</div>

<Note>
  **Keep your API key secure!** Treat it like a password. Never commit it to version control or share it publicly. Anyone with your API key can make requests on your behalf and consume your credits.
</Note>

## 3. Authenticate

Use your API key to authenticate requests to Dune's APIs. Include it in your request headers:

```bash theme={null}
X-DUNE-API-KEY: your-api-key-here
```

### Initialize the SDK

<CodeGroup>
  ```python Python theme={null}
  from dune_client import DuneClient

  # DuneClient will read the DUNE_API_KEY environment variable
  dune = DuneClient()
  ```

  ```typescript TypeScript theme={null}
  import { DuneClient } from '@duneanalytics/client-sdk';

  // Use environment variable for security
  const dune = new DuneClient(process.env.DUNE_API_KEY);
  ```

  ```go Go theme={null}
  import "github.com/duneanalytics/duneapi-client-go"
  import "os"

  // Use environment variable for security
  client := duneapi.New(os.Getenv("DUNE_API_KEY"))
  ```
</CodeGroup>

<Tip>
  **Best practices:**

  * Store API keys in environment variables
  * Create separate keys for development and production
  * Rotate keys periodically
  * Revoke keys immediately if compromised
</Tip>

## 4. Get Started

Use your API key to make requests to Dune's APIs. Here's a simple example to get recent DEX trades:

<CodeGroup>
  ```bash cURL theme={null}
  # Execute a SQL query
  curl -X POST "https://api.dune.com/api/v1/sql/execute" \
    -H "Content-Type: application/json" \
    -H "X-DUNE-API-KEY: YOUR_API_KEY" \
    -d '{
      "sql": "SELECT * FROM dex.trades WHERE block_time > now() - interval '\''1'\'' day LIMIT 10",
      "performance": "medium"
    }'
  ```

  ```python Python theme={null}
  from dune_client import DuneClient

  dune = DuneClient(api_key="YOUR_API_KEY")

  # Execute a SQL query
  sql = """
  SELECT * FROM dex.trades 
  WHERE block_time > now() - interval '1' day 
  LIMIT 10
  """

  results = dune.run_sql(query_sql=sql)
  print(results.get_rows())
  ```

  ```typescript TypeScript theme={null}
  import { DuneClient } from '@duneanalytics/client-sdk';

  const dune = new DuneClient('YOUR_API_KEY');

  // Execute a saved query
  const executionResult = await dune.runQuery({ queryId: 3493826 });
  console.log(executionResult.result?.rows);
  ```
</CodeGroup>

### Understanding the Response

The API returns an execution object with your query status:

```json theme={null}
{
  "execution_id": "01K9AHMWSJZD59KAGB3WY45895",
  "state": "QUERY_STATE_EXECUTING",
  "submitted_at": "2025-11-05T17:39:48.146829Z",
  "expires_at": "2026-02-03T17:39:48.329665Z"
}
```

<Note>
  Queries execute asynchronously. Use the `execution_id` to check status and retrieve results. Our SDKs handle polling automatically.
</Note>

### Getting Results

Once execution completes, fetch the results:

```bash theme={null}
curl "https://api.dune.com/api/v1/execution/{execution_id}/results" \
  -H "X-DUNE-API-KEY: YOUR_API_KEY"
```

***

## Next Steps

Now that you've made your first request, explore common use cases:

<CardGroup>
  <Card title="Analyze onchain data" icon="chart-line" href="/api-reference/apis/quickstart-analyze">
    Build custom analytics pipelines and reports
  </Card>

  <Card title="Use connectors" icon="server" href="/api-reference/connectors/overview">
    Connect with Trino Connector or DBT Connector for maximum flexibility
  </Card>
</CardGroup>

## Additional Resources

<CardGroup>
  <Card title="API Reference" icon="book" href="/api-reference/executions/execution-object">
    Complete endpoint documentation
  </Card>

  <Card title="Rate Limits" icon="gauge" href="/api-reference/overview/rate-limits">
    Understand API rate limits
  </Card>

  <Card title="Troubleshooting" icon="triangle-exclamation" href="/api-reference/overview/troubleshooting">
    Common issues and solutions
  </Card>
</CardGroup>

## Getting Help

<CardGroup>
  <Card title="Community Discord" icon="discord" href="https://discord.gg/duneanalytics">
    Get help from the Dune community
  </Card>

  <Card title="Support" icon="life-ring" href="mailto:support@dune.com">
    Contact our support team
  </Card>

  <Card title="Status Page" icon="signal" href="https://status.dune.com">
    Check API status and uptime
  </Card>
</CardGroup>


# Overview
Source: https://docs.dune.com/api-reference/overview/introduction



Build blockchain analytics workflows with Dune's comprehensive API suite. Access the same data that powers thousands of Dune dashboards, available programmatically for your data pattern needs.

Dune API provides a variety of endpoints for **analysts**, **data engineers**, and **data scientists**, ranging from low-level, customizable options to connectors ready for immediate use.

Queries saved in the Dune App UI can be executed via API and results retrieved in your environment, enabling bulk data extraction and automated workflows.

<Note>
  <span>**New to Dune?** **[Create a free account](https://dune.com/auth/register)** or **[get your API key](https://dune.com/apis?tab=keys)** to get started.</span>
</Note>

## What do you want to build?

<CardGroup>
  <Card title="Analyze onchain data programmatically" icon="chart-line" href="/api-reference/apis/quickstart-analyze">
    Execute SQL queries, retrieve results, and build custom analytics pipelines with Dune's query execution engine. Perfect for data teams and analysts.

    → Start with query execution
  </Card>

  <Card title="Run queries in your environment" icon="server" href="/api-reference/connectors/overview">
    Connect directly to Dune's data warehouse using Trino Connector for maximum flexibility. Perfect for enterprise teams with existing BI tools.

    → Set up Trino connector
  </Card>

  <Card title="Build custom dashboards & reports" icon="desktop" href="/api-reference/apis/quickstart-dashboards">
    Fetch query results, manage executions, and create dynamic visualizations in your own applications. Perfect for teams embedding analytics.

    → Create your first dashboard
  </Card>

  <Card title="Build real-time applications" icon="bolt" href="https://docs.sim.dune.com/evm/build-a-realtime-wallet">
    Create a multichain wallet with realtime balances, transactions, and NFTs using Sim by Dune. Perfect for mobile developers and DeFi applications.

    → Build a realtime wallet with Sim
  </Card>

  <Card title="Transform data with dbt" icon="code-branch" href="/api-reference/connectors/dbt/overview">
    Build production-grade data transformation pipelines with write access to DuneSQL. Perfect for data engineering teams using dbt.

    → Set up dbt connector
  </Card>

  <Card title="BI Visualization Tools" icon="chart-bar" href="/api-reference/connectors/trino/overview">
    Connect Dune to your favorite BI tools like Hex, Metabase, and DBeaver using the Trino/Presto connector.

    → Connect BI tools
  </Card>
</CardGroup>

<Card title="Get started with the basics" icon="rocket" href="/api-reference/overview/getting-started">
  New to APIs? Start here to make your first request and see results in minutes.

  Learn how to execute a simple SQL query, authenticate your requests, and retrieve blockchain data programmatically.

  → Make your first request
</Card>

## Quick Start with SDKs

Our SDKs handle authentication, polling, pagination, and error handling automatically. The new `execute()` function manages the entire workflow for you.

<CardGroup>
  <Card title="Python" icon="python" href="/api-reference/overview/sdks#python">
    ```bash theme={null}
    pip install dune-client
    ```

    ```python theme={null}
    from dune_client import DuneClient

    dune = DuneClient(api_key="your-key")
    results = dune.execute(query_id=3493826)
    ```

    [Full Python documentation →](/api-reference/overview/sdks#python)
  </Card>

  <Card title="TypeScript" icon="js" href="/api-reference/overview/sdks#typescript">
    ```bash theme={null}
    npm install @duneanalytics/client
    ```

    ```typescript theme={null}
    import { DuneClient } from '@duneanalytics/client';

    const dune = new DuneClient('your-key');
    const results = await dune.execute({ queryId: 3493826 });
    ```

    [Full TypeScript documentation →](/api-reference/overview/sdks#typescript)
  </Card>

  <Card title="Go" icon="golang" href="/api-reference/overview/sdks#go">
    ```bash theme={null}
    go get github.com/duneanalytics/duneapi-client-go
    ```

    ```go theme={null}
    client := duneapi.New("your-key")
    results := client.Execute(3493826)
    ```

    [Full Go documentation →](/api-reference/overview/sdks#go)
  </Card>
</CardGroup>

<Note>
  **New:** All SDKs now include an `execute()` function that handles polling and pagination automatically. No more managing multiple API calls!
</Note>

## Additional Resources

<CardGroup>
  <Card title="API Reference" icon="book" href="/api-reference/api-overview">
    Complete documentation for all endpoints, parameters, response formats, and status codes.

    * Execute & Results endpoints
    * Query management
    * Dataset metadata
    * Usage & billing
    * Webhooks
  </Card>

  <Card title="Troubleshooting Errors" icon="triangle-exclamation" href="/api-reference/overview/troubleshooting">
    Common API errors and how to resolve them.

    * Authentication issues
    * Rate limit errors
    * Query execution failures
    * Response format errors
  </Card>

  <Card title="API Pricing" icon="credit-card" href="/api-reference/overview/billing">
    Understand credit consumption and costs for different endpoints.

    * Execution endpoints: Credit-based
    * Metadata endpoints: Free
    * Usage tracking available via API
  </Card>

  <Card title="Authentication" icon="key" href="/api-reference/overview/authentication">
    Get started with API keys and authentication.

    * Auto-generated keys for new teams
    * Manage keys in settings
    * Best practices for key security
  </Card>
</CardGroup>

## Getting Help

<CardGroup>
  <Card title="Quickstarts" icon="rocket" href="/api-reference/overview/getting-started">
    Step-by-step guides for common use cases
  </Card>

  <Card title="Community" icon="discord" href="https://discord.gg/duneanalytics">
    Get help from the Dune community
  </Card>

  <Card title="Support" icon="life-ring" href="mailto:support@dune.com">
    Contact our support team
  </Card>
</CardGroup>


# Rate Limits
Source: https://docs.dune.com/api-reference/overview/rate-limits



**Rate Limits**

Our rate limits are implemented in three ways: IP, low vs. high limit endpoints and [subscription plan](https://dune.com/pricing).

* Low limit endpoints *(write-heavy operations)*
  * [create query](../queries/endpoint/create)
  * [update query](../queries/endpoint/update)
  * [private query](../queries/endpoint/private)
  * [unprivate query](../queries/endpoint/unprivate)
  * [archive query](../queries/endpoint/archive)
  * [unarchive query](../queries/endpoint/unarchive)
  * [execute query](../executions/endpoint/execute-query)
  * [create table](../tables/endpoint/create)
  * [insert into table](../tables/endpoint/insert)
  * [upload CSV](../tables/endpoint/upload)
  * [delete table](../tables/endpoint/delete)
* High limit endpoints *(read-heavy operations)*
  * [read query](../queries/endpoint/read)
  * [get execution result](../executions/endpoint/get-execution-result)
  * [get execution result CSV](../executions/endpoint/get-execution-result-csv)
  * [get execution status](../executions/endpoint/get-execution-status)
  * [cancel execution](../executions/endpoint/cancel-execution)

| Dimension  |            | Limit                          |
| ---------- | ---------- | ------------------------------ |
| Per IP     |            | 1000 requests per second (rps) |
| Free       | Low limit  | 15 requests per minute (rpm)   |
| Free       | High limit | 40 rpm                         |
| Plus       | Low limit  | 70 rpm                         |
| Plus       | High limit | 200 rpm                        |
| Enterprise | Low limit  | 350+ rpm                       |
| Enterprise | High limit | 1000+ rpm                      |
| Enterprise |            | Please contact us!             |

<Note>
  Rate limits for different dimensions are separate but can be utilized independently.
  For example, on the Free plan, you have a low limit of 15 requests per minute and a high limit of 40 requests per minute. You can use both types of requests in the same minute, effectively having a combined limit of 55.
</Note>

**Data Return Limit**

Dune internally has a maximum query result size limit (which currently is 32GB). If your query yields more than 32GB of data, the result will be truncated in storage. In such cases, pulling the result data (using pagination) but without specifying `allow_partial_results` set to true will trigger an error message: "error": "Partial Result, please request with 'allow\_partial\_results=true'". If you wish to retrieve partial results, you can pass the parameter `allow_partial_results=true`. But please make sure you indeed want to fetch the truncated result.


# Troubleshooting Errors
Source: https://docs.dune.com/api-reference/overview/troubleshooting



Dune uses conventional HTTP response codes to indicate the success or failure of an API request. In general: Codes in the `2xx` range indicate success. Codes in the `4xx` range indicate an error that failed given the information provided. Codes in the `5xx` range indicate an error with Dune's servers.

| HTTP Status Code | Status            | Description                                                              |
| ---------------- | ----------------- | ------------------------------------------------------------------------ |
| 200              | OK                | Everything worked as expected.                                           |
| 400              | Bad Request       | The request was unacceptable, often due to missing a required parameter. |
| 401              | Unauthorized      | No valid API key provided.                                               |
| 402              | Payment Required  | This request would exceed your configured limits per billing cycle.      |
| 403              | Forbidden         | The API key doesn’t have permissions to perform the request.             |
| 404              | Not Found         | The requested resource doesn’t exist.                                    |
| 409              | Conflict          | The request conflicts with another request.                              |
| 429              | Too Many Requests | Too many requests hit the API too quickly (rate limited).                |
| 500              | Server Errors     | Generic internal server error.                                           |

For specific error code information, please refer to each of the endpoints themselves. Here we list some common errors and suggest possible solutions:

#### Invalid API key

```json theme={null}
{
  "error": "invalid API Key"
}
```

You did not input a valid API key. You can go generate a new key and make sure you save it in a safe place and paste the key over.

#### Permission error

```json theme={null}
{
  "error": "not found: Query not found or private"
}
```

When you perform an action on a private query your API key doesn't have access to, you will get this error. If you indeed own this query, please check that the context of the API key and the query owner are the same.

#### Credit limit error

```json theme={null}
{
  "error": "This api request would exceed your configured limits per billing cycle. Please visit your settings on dune.com and adjust your limits to continue usage."
}
```

You are trying to make a request but don't have enough credits (configured) on your account. If you'd like to incur extra credits, head over to settings -> subscription and adjust the limit you have set within "limit extra credits" toggle.


# Execute Pipeline
Source: https://docs.dune.com/api-reference/pipelines/endpoint/execute-pipeline

POST /v1/pipelines/execute
Executes a specified pipeline. A pipeline allows you to chain multiple queries and materialized view refreshes together and execute them as a single unit.

<Info>
  Minimum required API key scope: `Read`
</Info>

This endpoint builds an execution pipeline from a specified query and executes it. The pipeline will automatically include all materialized views in the query's lineage, ensuring coordinated execution of dependent queries.

## How It Works

When you execute a pipeline using this endpoint:

1. **Lineage Detection**: Dune analyzes the query to identify all materialized views it depends on
2. **Pipeline Construction**: A pipeline is automatically built that includes all dependencies in the correct order
3. **Coordinated Execution**: All queries and materialized view refreshes are executed as a single unit
4. **Status Tracking**: Returns a `pipeline_execution_id` for monitoring progress

## Key Differences from Query Pipeline Execute

This endpoint differs from the [Execute Query Pipeline](/api-reference/executions/endpoint/execute-query-pipeline) endpoint:

| Feature      | Execute Pipeline                              | Execute Query Pipeline                       |
| ------------ | --------------------------------------------- | -------------------------------------------- |
| **Endpoint** | `POST /v1/pipelines/execute`                  | `POST /v1/query/{query_id}/pipeline/execute` |
| **Query ID** | In request body                               | In URL path                                  |
| **Lineage**  | Automatically includes all materialized views | Executes predefined pipeline                 |
| **Use Case** | Dynamic pipeline based on query dependencies  | Predefined pipeline execution                |

## Request Body

The request body accepts:

* `query_id` (required): The unique identifier of the query to execute
* `performance` (optional): Execution tier - `medium` (default) or `large`
* `query_parameters` (optional): SQL query parameters as JSON key-value pairs

## Use Cases

This endpoint is ideal for:

* **Dependency Management**: Automatically refreshing all materialized views a query depends on
* **Consistent Updates**: Ensuring all dependent data is fresh before query execution
* **Dynamic Pipelines**: When you want to execute based on runtime query dependencies
* **Simplified Workflow**: No need to manually define pipeline structure

## Monitoring Pipeline Execution

After executing the pipeline:

1. Save the returned `pipeline_execution_id`
2. Use the [Get Pipeline Execution Status](/api-reference/pipelines/endpoint/get-pipeline-status) endpoint to monitor progress
3. Track the status of each materialized view refresh and query execution
4. Retrieve results once the pipeline completes

## Example Workflow

```bash theme={null}
# 1. Execute pipeline for query ID 1234567
curl -X POST "https://api.dune.com/api/v1/pipelines/execute" \
  -H "X-Dune-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query_id": 1234567,
    "performance": "medium",
    "query_parameters": {
      "start_date": "2024-01-01",
      "end_date": "2024-12-31"
    }
  }'

# Response: { "pipeline_execution_id": "01HZABC123..." }

# 2. Check pipeline status
curl "https://api.dune.com/api/v1/pipelines/executions/01HZABC123.../status" \
  -H "X-Dune-Api-Key: YOUR_API_KEY"
```

<Note>
  This endpoint automatically determines which materialized views need to be refreshed based on the query's lineage. You don't need to manually specify dependencies.
</Note>

## Performance Considerations

* **Medium tier**: Best for most queries with standard dependencies
* **Large tier**: Use for complex queries with many dependencies or large materialized views
* Credits are consumed based on actual compute resources used for each node in the pipeline

<Tip>
  If your query depends on multiple materialized views, this endpoint will refresh all of them in the correct order before executing your query, ensuring data consistency.
</Tip>


# Get Pipeline Execution Status
Source: https://docs.dune.com/api-reference/pipelines/endpoint/get-pipeline-status

GET /v1/pipelines/executions/{pipeline_execution_id}/status
Retrieves the status of a pipeline execution, including the status of each node in the pipeline.

<Info>
  Minimum required API key scope: `Read`
</Info>

This endpoint retrieves the status of a pipeline execution, including the status of each node (query or materialized view refresh) in the pipeline.

## Understanding Pipeline Status

A pipeline execution contains multiple nodes, each representing either:

* **Query Execution**: A query that's part of the pipeline
* **Materialized View Refresh**: A materialized view that's refreshed as part of the pipeline

Each node has its own status and can be tracked independently.

## Pipeline States

The overall pipeline can be in one of the following states:

* `pending`: Pipeline execution has been queued but not yet started
* `executing`: Pipeline is currently running
* `completed`: All nodes in the pipeline have completed successfully

## Node Status

Each node in the pipeline includes:

* `node_id`: Unique identifier for the node
* `status`: Current state of the node execution
* `query_execution_status` or `materialized_view_refresh_status`: Detailed status information

## Response Structure

The 200 response includes:

* `status`: Overall pipeline execution status (pending, executing, or completed)
* `node_executions`: Array of individual node executions with their status and results

## Example Usage

```bash theme={null}
# Check pipeline status
curl "https://api.dune.com/api/v1/pipelines/executions/01HZABC123.../status" \
  -H "X-Dune-Api-Key: YOUR_API_KEY"
```

<Tip>
  Poll this endpoint periodically to monitor pipeline execution progress. Each node's status will update as the pipeline progresses through its execution.
</Tip>

## Monitoring Pipeline Progress

You can use this endpoint to:

* Track which nodes have completed and which are still running
* Identify any nodes that have failed
* Retrieve execution IDs for individual queries to fetch their results
* Monitor overall pipeline health

<Note>
  Once a pipeline execution completes, you can retrieve the results of individual queries using their respective execution IDs from the node status.
</Note>


# Overview
Source: https://docs.dune.com/api-reference/pipelines/overview



The pipeline endpoints enable you to execute and monitor query pipelines - a powerful feature that allows you to chain multiple queries together and execute them as a coordinated workflow.

## What are Query Pipelines?

Query pipelines are sequences of related queries that execute in a specific order based on their dependencies. Instead of executing individual queries separately, pipelines allow you to:

* **Define Dependencies**: Specify which queries depend on the results of other queries
* **Atomic Execution**: Execute all queries in the pipeline as a single unit
* **Coordinated Updates**: Ensure related queries are always executed together
* **Track Progress**: Monitor the status of each query in the pipeline

## How Pipelines Work

1. **Inspect Pipeline**: Use the [Get Query Pipeline](/api-reference/queries/endpoint/get-query-pipeline) endpoint to view the pipeline structure
2. **Execute Pipeline**: Use the [Execute Pipeline](./endpoint/execute-pipeline) endpoint or [Execute Query Pipeline](/api-reference/executions/endpoint/execute-query-pipeline) endpoint
3. **Monitor Progress**: Poll the [Get Pipeline Execution Status](./endpoint/get-pipeline-status) endpoint to track execution
4. **Retrieve Results**: Once complete, access results for each query using their individual execution IDs

## Pipeline Components

A pipeline execution consists of multiple **nodes**, where each node can be:

* **Query Execution**: A DuneSQL query that runs as part of the pipeline
* **Materialized View Refresh**: A materialized view that gets refreshed during pipeline execution

Each node has its own execution status and can be tracked independently.

## Common Use Cases

### Data Transformation Pipelines

Build multi-stage data processing workflows where each stage depends on the previous one:

* Stage 1: Extract raw data
* Stage 2: Transform and clean data
* Stage 3: Aggregate results
* Stage 4: Generate final metrics

### Coordinated Dashboard Updates

Ensure all queries powering a dashboard are executed together with fresh data:

* Execute all dependent queries in the correct order
* Maintain consistency across related metrics
* Update materialized views that feed into dashboard queries

### Incremental Data Processing

Process data incrementally through multiple dependent steps:

* Process new transactions
* Update aggregated tables
* Refresh summary statistics
* Update trend indicators

## Endpoints

| Endpoint                                                        | Method                                                        | Description                                                                            |
| --------------------------------------------------------------- | ------------------------------------------------------------- | -------------------------------------------------------------------------------------- |
| [Execute Pipeline](./endpoint/execute-pipeline)                 | `POST /v1/pipelines/execute`                                  | Builds and executes a pipeline including all materialized views in the query's lineage |
| [Get Pipeline Execution Status](./endpoint/get-pipeline-status) | `GET /v1/pipelines/executions/{pipeline_execution_id}/status` | Retrieves the status of a pipeline execution including all nodes                       |

## Related Endpoints

| Endpoint                                                                            | Method                                       | Description                                                                                   |
| ----------------------------------------------------------------------------------- | -------------------------------------------- | --------------------------------------------------------------------------------------------- |
| [Get Query Pipeline](/api-reference/queries/endpoint/get-query-pipeline)            | `GET /v1/query/{query_id}/pipeline`          | Retrieves the pipeline definition for a query, including all dependencies and execution order |
| [Execute Query Pipeline](/api-reference/executions/endpoint/execute-query-pipeline) | `POST /v1/query/{query_id}/pipeline/execute` | Executes a predefined query pipeline starting from the specified query                        |

## Pipeline vs. Regular Query Execution

| Feature          | Regular Execution    | Pipeline Execution         |
| ---------------- | -------------------- | -------------------------- |
| **Queries**      | Single query         | Multiple dependent queries |
| **Coordination** | Manual               | Automatic                  |
| **Dependencies** | None                 | Enforced by pipeline       |
| **Monitoring**   | Per-query            | Unified view of all nodes  |
| **Use Case**     | Independent analysis | Complex workflows          |

<Tip>
  Use [Execute Pipeline](./endpoint/execute-pipeline) for automatic lineage-based execution or [Execute Query Pipeline](/api-reference/executions/endpoint/execute-query-pipeline) for predefined pipelines. Then monitor progress with the [Get Pipeline Execution Status](./endpoint/get-pipeline-status) endpoint using the returned `pipeline_execution_id`.
</Tip>

## Credits and Performance

Pipeline executions consume credits based on:

* The performance tier selected (medium or large)
* Actual compute resources used by each query in the pipeline
* Number of queries and complexity of operations

You can specify the performance tier when executing the pipeline to optimize for speed or cost.

<Note>
  Pipelines are created and configured in the Dune web application. The API endpoints allow you to execute and monitor existing pipelines programmatically.
</Note>


# Archive Query
Source: https://docs.dune.com/api-reference/queries/endpoint/archive

POST /v1/query/{queryId}/archive
This API allows for anyone to archive a query. Only the API key
generated under the context of the owner of that query will work.
This does not delete the query, but will make
it uneditable/unexecutable

<Info>
  Minimum required API key scope: `Read/Write`
</Info>

<Tip>
  In Dune context, delete action is replaced by archive as deletion of queries is not possible.
</Tip>

<Note>
  To access Query endpoints, an [Analyst plan](https://dune.com/pricing) or higher is required.
</Note>

<RequestExample>
  ```bash cURL theme={null}
  curl --request POST \
    --url https://api.dune.com/api/v1/query/{queryId}/archive \
    --header 'X-DUNE-API-KEY: <x-dune-api-key>'
  ```

  ```python Python SDK theme={null}
  from dune_client.client import DuneClient

  dune = DuneClient()

  query = dune.archive_query(1252207)
  ```

  ```python Python theme={null}
  import requests

  url = "https://api.dune.com/api/v1/query/{queryId}/archive"

  headers = {"X-DUNE-API-KEY": "<x-dune-api-key>"}

  response = requests.request("POST", url, headers=headers)

  print(response.text)

  ```

  ```javascript JavaScript theme={null}
  const options = {method: 'POST', headers: {'X-DUNE-API-KEY': '<x-dune-api-key>'}};

  fetch('https://api.dune.com/api/v1/query/{queryId}/archive', options)
    .then(response => response.json())
    .then(response => console.log(response))
    .catch(err => console.error(err));
  ```

  ```go Go theme={null}
  package main

  import (
  	"fmt"
  	"net/http"
  	"io/ioutil"
  )

  func main() {

  	url := "https://api.dune.com/api/v1/query/{queryId}/archive"

  	req, _ := http.NewRequest("POST", url, nil)

  	req.Header.Add("X-DUNE-API-KEY", "<x-dune-api-key>")

  	res, _ := http.DefaultClient.Do(req)

  	defer res.Body.Close()
  	body, _ := ioutil.ReadAll(res.Body)

  	fmt.Println(res)
  	fmt.Println(string(body))

  }
  ```

  ```php PHP theme={null}
  <?php

  $curl = curl_init();

  curl_setopt_array($curl, [
    CURLOPT_URL => "https://api.dune.com/api/v1/query/{queryId}/archive",
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_ENCODING => "",
    CURLOPT_MAXREDIRS => 10,
    CURLOPT_TIMEOUT => 30,
    CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
    CURLOPT_CUSTOMREQUEST => "POST",
    CURLOPT_HTTPHEADER => [
      "X-DUNE-API-KEY: <x-dune-api-key>"
    ],
  ]);

  $response = curl_exec($curl);
  $err = curl_error($curl);

  curl_close($curl);

  if ($err) {
    echo "cURL Error #:" . $err;
  } else {
    echo $response;
  }
  ```

  ```java Java theme={null}
  HttpResponse<String> response = Unirest.post("https://api.dune.com/api/v1/query/{queryId}/archive")
    .header("X-DUNE-API-KEY", "<x-dune-api-key>")
    .asString();
  ```
</RequestExample>


# Create Query
Source: https://docs.dune.com/api-reference/queries/endpoint/create

POST /v1/query
This API allows for anyone to create a query.
The owner of the query will be under the context of the API key.

<Info>
  Minimum required API key scope: `Read/Write`
</Info>

<Note>
  To access Query endpoints, an [Analyst plan](https://dune.com/pricing) or higher is required.
</Note>

<RequestExample>
  ```bash cURL theme={null}
  curl --request POST \
    --url https://api.dune.com/api/v1/query \
    --header 'Content-Type: application/json' \
    --header 'X-DUNE-API-KEY: <x-dune-api-key>' \
    --data '{
    "name": "erc20 balances (user address) API",
    "description": "Example Blockchain Query",
    "parameters": [
      {
        "key": "address",
        "value": "0x2ae8c972fb2e6c00dded8986e2dc672ed190da06",
        "type": "text"
      },
      {
        "key": "blocknumber",
        "value": "0",
        "type": "number"
      },
      {
        "key": "chain",
        "value": "ethereum",
        "type": "enum",
        "enumOptions": [
          "ethereum",
          "polygon",
          "optimism",
          "arbitrum",
          "avalanche_c",
          "gnosis",
          "bnb"
        ]
      }
    ],
    "query_sql": "SELECT * FROM {{blockchain}}.transactions WHERE to = {{address}} AND block_number > {{blocknumber}}",
    "is_private": true
  }'
  ```

  ```python Python SDK theme={null}
  from dune_client.types import QueryParameter
  from dune_client.client import DuneClient
  from dune_client.query import QueryBase

  dune = DuneClient()

  query = dune.create_query(
      name="Example Blockchain Query",
      query_sql="SELECT * FROM {{blockchain}}.transactions WHERE to = {{address}} AND block_number > {{blocknumber}}",
      params=[
          QueryParameter.number_type(name="blocknumber", value=0),
          QueryParameter.text_type(name="address", value="0x2ae8c972fb2e6c00dded8986e2dc672ed190da06"),
          QueryParameter.text_type(name="blockchain", value="ethereum"),
      ],
      is_private=False
  )
  ```

  ```python Python theme={null}
  import requests

  url = "https://api.dune.com/api/v1/query"

  payload = {
      "name": "erc20 balances (user address) API",
      "description": "Example Blockchain Query",
      "parameters": [
          {
              "key": "address",
              "value": "0x2ae8c972fb2e6c00dded8986e2dc672ed190da06",
              "type": "text"
          },
          {
              "key": "blocknumber",
              "value": "0",
              "type": "number"
          },
          {
              "key": "chain",
              "value": "ethereum",
              "type": "enum",
              "enumOptions": ["ethereum", "polygon", "optimism", "arbitrum", "avalanche_c", "gnosis", "bnb"]
          }
      ],
      "query_sql": "SELECT * FROM {{blockchain}}.transactions WHERE to = {{address}} AND block_number > {{blocknumber}}",
      "is_private": True
  }
  headers = {
      "X-DUNE-API-KEY": "<x-dune-api-key>",
      "Content-Type": "application/json"
  }

  response = requests.request("POST", url, json=payload, headers=headers)

  print(response.text)
  ```

  ```javascript JavaScript theme={null}
  const options = {
    method: 'POST',
    headers: {'X-DUNE-API-KEY': '<x-dune-api-key>', 'Content-Type': 'application/json'},
    body: '{"name":"erc20 balances (user address) API","description":"Example Blockchain Query","parameters":[{"key":"address","value":"0x2ae8c972fb2e6c00dded8986e2dc672ed190da06","type":"text"},{"key":"blocknumber","value":"0","type":"number"},{"key":"chain","value":"ethereum","type":"enum","enumOptions":["ethereum","polygon","optimism","arbitrum","avalanche_c","gnosis","bnb"]}],"query_sql":"SELECT * FROM {{blockchain}}.transactions WHERE to = {{address}} AND block_number > {{blocknumber}}","is_private":true}'
  };

  fetch('https://api.dune.com/api/v1/query', options)
    .then(response => response.json())
    .then(response => console.log(response))
    .catch(err => console.error(err));
  ```

  ```go Go theme={null}
  package main

  import (
  	"fmt"
  	"strings"
  	"net/http"
  	"io"
  )

  func main() {

  	url := "https://api.dune.com/api/v1/query"

  	payload := strings.NewReader("{\n  \"name\": \"erc20 balances (user address) API\",\n  \"description\": \"Example Blockchain Query\",\n  \"parameters\": [\n    {\n      \"key\": \"address\",\n      \"value\": \"0x2ae8c972fb2e6c00dded8986e2dc672ed190da06\",\n      \"type\": \"text\"\n    },\n    {\n      \"key\": \"blocknumber\",\n      \"value\": \"0\",\n      \"type\": \"number\"\n    },\n    {\n      \"key\": \"chain\",\n      \"value\": \"ethereum\",\n      \"type\": \"enum\",\n      \"enumOptions\": [\n        \"ethereum\",\n        \"polygon\",\n        \"optimism\",\n        \"arbitrum\",\n        \"avalanche_c\",\n        \"gnosis\",\n        \"bnb\"\n      ]\n    }\n  ],\n  \"query_sql\": \"SELECT * FROM {{blockchain}}.transactions WHERE to = {{address}} AND block_number > {{blocknumber}}\",\n  \"is_private\": true\n}")

  	req, _ := http.NewRequest("POST", url, payload)

  	req.Header.Add("X-DUNE-API-KEY", "<x-dune-api-key>")
  	req.Header.Add("Content-Type", "application/json")

  	res, _ := http.DefaultClient.Do(req)

  	defer res.Body.Close()
  	body, _ := io.ReadAll(res.Body)

  	fmt.Println(res)
  	fmt.Println(string(body))

  }
  ```

  ```php PHP theme={null}
  <?php

  $curl = curl_init();

  curl_setopt_array($curl, [
    CURLOPT_URL => "https://api.dune.com/api/v1/query",
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_ENCODING => "",
    CURLOPT_MAXREDIRS => 10,
    CURLOPT_TIMEOUT => 30,
    CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
    CURLOPT_CUSTOMREQUEST => "POST",
    CURLOPT_POSTFIELDS => "{\n  \"name\": \"erc20 balances (user address) API\",\n  \"description\": \"Example Blockchain Query\",\n  \"parameters\": [\n    {\n      \"key\": \"address\",\n      \"value\": \"0x2ae8c972fb2e6c00dded8986e2dc672ed190da06\",\n      \"type\": \"text\"\n    },\n    {\n      \"key\": \"blocknumber\",\n      \"value\": \"0\",\n      \"type\": \"number\"\n    },\n    {\n      \"key\": \"chain\",\n      \"value\": \"ethereum\",\n      \"type\": \"enum\",\n      \"enumOptions\": [\n        \"ethereum\",\n        \"polygon\",\n        \"optimism\",\n        \"arbitrum\",\n        \"avalanche_c\",\n        \"gnosis\",\n        \"bnb\"\n      ]\n    }\n  ],\n  \"query_sql\": \"SELECT * FROM {{blockchain}}.transactions WHERE to = {{address}} AND block_number > {{blocknumber}}\",\n  \"is_private\": true\n}",
    CURLOPT_HTTPHEADER => [
      "Content-Type: application/json",
      "X-DUNE-API-KEY: <x-dune-api-key>"
    ],
  ]);

  $response = curl_exec($curl);
  $err = curl_error($curl);

  curl_close($curl);

  if ($err) {
    echo "cURL Error #:" . $err;
  } else {
    echo $response;
  }
  ```

  ```java Java theme={null}
  HttpResponse<String> response = Unirest.post("https://api.dune.com/api/v1/query")
    .header("X-DUNE-API-KEY", "<x-dune-api-key>")
    .header("Content-Type", "application/json")
    .body("{\n  \"name\": \"erc20 balances (user address) API\",\n  \"description\": \"Example Blockchain Query\",\n  \"parameters\": [\n    {\n      \"key\": \"address\",\n      \"value\": \"0x2ae8c972fb2e6c00dded8986e2dc672ed190da06\",\n      \"type\": \"text\"\n    },\n    {\n      \"key\": \"blocknumber\",\n      \"value\": \"0\",\n      \"type\": \"number\"\n    },\n    {\n      \"key\": \"chain\",\n      \"value\": \"ethereum\",\n      \"type\": \"enum\",\n      \"enumOptions\": [\n        \"ethereum\",\n        \"polygon\",\n        \"optimism\",\n        \"arbitrum\",\n        \"avalanche_c\",\n        \"gnosis\",\n        \"bnb\"\n      ]\n    }\n  ],\n  \"query_sql\": \"SELECT * FROM {{blockchain}}.transactions WHERE to = {{address}} AND block_number > {{blocknumber}}\",\n  \"is_private\": true\n}")
    .asString();
  ```
</RequestExample>


# Get Query Pipeline
Source: https://docs.dune.com/api-reference/queries/endpoint/get-query-pipeline

GET /v1/query/{query_id}/pipeline
Builds a query pipeline from the specified query and returns the pipeline definition containing all the nested materialized views that the query depends on. A pipeline allows you to chain multiple queries together and execute them as a single unit.

<Info>
  Minimum required API key scope: `Read`
</Info>

Retrieve the pipeline definition for a specific query, including all nested materialized views that the query depends on.

## Overview

This endpoint returns the pipeline structure that would be executed for a given query, allowing you to inspect the lineage and execution order before running the pipeline. This is useful for understanding dependencies and planning pipeline executions.

The pipeline definition contains all the nodes (queries and materialized view refreshes) in the correct dependency order.

<Note>
  The `query_parameters` should be passed as a URL-encoded JSON string in the query parameter, where keys are parameter names and values are parameter values.
</Note>

## Use Cases

### Inspect Pipeline Before Execution

Check what queries and materialized views will be executed:

```bash theme={null}
curl "https://api.dune.com/api/v1/query/3493826/pipeline?performance=medium" \
  -H "X-Dune-Api-Key: $DUNE_API_KEY"
```

### Validate Dependencies with Parameters

Understand query dependencies before running a pipeline with specific parameters:

```bash theme={null}
# Query parameters as JSON string
curl "https://api.dune.com/api/v1/query/3493826/pipeline?performance=large&query_parameters=%7B%22blockchain%22%3A%22ethereum%22%7D" \
  -H "X-Dune-Api-Key: $DUNE_API_KEY"
```

## Response Structure

The response contains a `pipeline` object with a `nodes` array. Each node represents either a query execution or materialized view refresh, along with its dependencies.

Example response:

```json theme={null}
{
  "pipeline": {
    "nodes": [
      {
        "id": 1,
        "dependencies": [],
        "materialized_view_refresh": {
          "name": "dune.analyst.mv_base_data",
          "performance": "medium"
        }
      },
      {
        "id": 2,
        "dependencies": [1],
        "query_execution": {
          "query_id": 3493826,
          "performance": "medium"
        }
      }
    ]
  }
}
```

## Best Practices

<AccordionGroup>
  <Accordion title="Use Before Pipeline Execution">
    Call this endpoint before executing a pipeline to understand what will be executed and in what order. This helps with planning and cost estimation.
  </Accordion>

  <Accordion title="Validate Complex Dependencies">
    For queries with many dependencies, use this endpoint to visualize the execution graph and identify potential bottlenecks.
  </Accordion>

  <Accordion title="Test with Parameters">
    When using query parameters, test the pipeline structure with different parameter values to ensure the lineage is resolved correctly.
  </Accordion>
</AccordionGroup>

## Related Endpoints

* [Execute Query Pipeline](/api-reference/executions/endpoint/execute-query-pipeline) - Execute a query's pipeline
* [Execute Pipeline](/api-reference/pipelines/endpoint/execute-pipeline) - Execute a pipeline based on lineage
* [Get Pipeline Status](/api-reference/pipelines/endpoint/get-pipeline-status) - Check pipeline execution status


# List Queries
Source: https://docs.dune.com/api-reference/queries/endpoint/list

GET /v1/queries
Retrieve a paginated list of queries owned by the account tied to the API key

<Info>
  Minimum required API key scope: `Read`
</Info>

<Note>
  To access Query endpoints, an [Analyst plan](https://dune.com/pricing) or higher is required.
</Note>

Retrieve a paginated list of queries owned by the account associated with the API key. This endpoint is useful for:

* Discovering all queries in your account
* Building custom query management interfaces
* Auditing query ownership and metadata
* Syncing query information to external systems

## Response

The endpoint returns a list of query overview objects containing:

* `id`: Unique identifier of the query
* `name`: Name of the query
* `description`: Description of the query
* `owner`: Owner handle (username or team handle)
* `tags`: Tags associated with the query
* `created_at`: Timestamp of when the query was created
* `updated_at`: Timestamp of when the query was last updated
* `total`: Total number of queries available (for pagination)

## Pagination

Use the `limit` and `offset` parameters to paginate through large result sets:

* `limit`: Number of queries to return per page (default: 20)
* `offset`: Number of queries to skip (default: 0)

<RequestExample>
  ```bash cURL theme={null}
  curl --request GET \
    --url 'https://api.dune.com/api/v1/queries?limit=20&offset=0' \
    --header 'X-DUNE-API-KEY: <x-dune-api-key>'
  ```

  ```python Python SDK theme={null}
  from dune_client.client import DuneClient

  dune = DuneClient()

  # List all queries (first page)
  queries = dune.list_queries(limit=20, offset=0)

  print(f"Total queries: {queries['total']}")
  for query in queries['queries']:
      print(f"Query {query['id']}: {query['name']}")
  ```

  ```python Python theme={null}
  import requests

  url = "https://api.dune.com/api/v1/queries"
  params = {
      "limit": 20,
      "offset": 0
  }

  headers = {"X-DUNE-API-KEY": "<x-dune-api-key>"}

  response = requests.get(url, headers=headers, params=params)

  data = response.json()
  print(f"Total queries: {data['total']}")
  for query in data['queries']:
      print(f"Query {query['id']}: {query['name']}")
  ```

  ```javascript JavaScript theme={null}
  const url = new URL('https://api.dune.com/api/v1/queries');
  url.searchParams.append('limit', '20');
  url.searchParams.append('offset', '0');

  const options = {
    method: 'GET',
    headers: {'X-DUNE-API-KEY': '<x-dune-api-key>'}
  };

  fetch(url, options)
    .then(response => response.json())
    .then(data => {
      console.log(`Total queries: ${data.total}`);
      data.queries.forEach(query => {
        console.log(`Query ${query.id}: ${query.name}`);
      });
    })
    .catch(err => console.error(err));
  ```

  ```go Go theme={null}
  package main

  import (
  	"fmt"
  	"net/http"
  	"io/ioutil"
  )

  func main() {
  	url := "https://api.dune.com/api/v1/queries?limit=20&offset=0"

  	req, _ := http.NewRequest("GET", url, nil)

  	req.Header.Add("X-DUNE-API-KEY", "<x-dune-api-key>")

  	res, _ := http.DefaultClient.Do(req)

  	defer res.Body.Close()
  	body, _ := ioutil.ReadAll(res.Body)

  	fmt.Println(res)
  	fmt.Println(string(body))
  }
  ```

  ```php PHP theme={null}
  <?php

  $curl = curl_init();

  curl_setopt_array($curl, [
    CURLOPT_URL => "https://api.dune.com/api/v1/queries?limit=20&offset=0",
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_ENCODING => "",
    CURLOPT_MAXREDIRS => 10,
    CURLOPT_TIMEOUT => 30,
    CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
    CURLOPT_CUSTOMREQUEST => "GET",
    CURLOPT_HTTPHEADER => [
      "X-DUNE-API-KEY: <x-dune-api-key>"
    ],
  ]);

  $response = curl_exec($curl);
  $err = curl_error($curl);

  curl_close($curl);

  if ($err) {
    echo "cURL Error #:" . $err;
  } else {
    echo $response;
  }
  ```

  ```java Java theme={null}
  HttpResponse<String> response = Unirest.get("https://api.dune.com/api/v1/queries?limit=20&offset=0")
    .header("X-DUNE-API-KEY", "<x-dune-api-key>")
    .asString();
  ```
</RequestExample>


# Private Query
Source: https://docs.dune.com/api-reference/queries/endpoint/private

POST /v1/query/{queryId}/private
This API allows for anyone to private a query. Only the API key
generated under the context of the owner of that query will work.

<Info>
  Minimum required API key scope: `Read/Write`
</Info>

<Note>
  To access Query endpoints, an [Analyst plan](https://dune.com/pricing) or higher is required.
</Note>

<RequestExample>
  ```bash cURL theme={null}
  curl --request POST \
    --url https://api.dune.com/api/v1/query/{queryId}/private \
    --header 'X-DUNE-API-KEY: <x-dune-api-key>'
  ```

  ```python Python SDK theme={null}
  from dune_client.client import DuneClient

  dune = DuneClient()

  query = dune.private_query(1252207)
  ```

  ```python Python theme={null}
  import requests

  url = "https://api.dune.com/api/v1/query/{queryId}/private"

  headers = {"X-DUNE-API-KEY": "<x-dune-api-key>"}

  response = requests.request("POST", url, headers=headers)

  print(response.text)

  ```

  ```javascript JavaScript theme={null}
  const options = {method: 'POST', headers: {'X-DUNE-API-KEY': '<x-dune-api-key>'}};

  fetch('https://api.dune.com/api/v1/query/{queryId}/private', options)
    .then(response => response.json())
    .then(response => console.log(response))
    .catch(err => console.error(err));
  ```

  ```go Go theme={null}
  package main

  import (
  	"fmt"
  	"net/http"
  	"io/ioutil"
  )

  func main() {

  	url := "https://api.dune.com/api/v1/query/{queryId}/private"

  	req, _ := http.NewRequest("POST", url, nil)

  	req.Header.Add("X-DUNE-API-KEY", "<x-dune-api-key>")

  	res, _ := http.DefaultClient.Do(req)

  	defer res.Body.Close()
  	body, _ := ioutil.ReadAll(res.Body)

  	fmt.Println(res)
  	fmt.Println(string(body))

  }
  ```

  ```php PHP theme={null}
  <?php

  $curl = curl_init();

  curl_setopt_array($curl, [
    CURLOPT_URL => "https://api.dune.com/api/v1/query/{queryId}/private",
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_ENCODING => "",
    CURLOPT_MAXREDIRS => 10,
    CURLOPT_TIMEOUT => 30,
    CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
    CURLOPT_CUSTOMREQUEST => "POST",
    CURLOPT_HTTPHEADER => [
      "X-DUNE-API-KEY: <x-dune-api-key>"
    ],
  ]);

  $response = curl_exec($curl);
  $err = curl_error($curl);

  curl_close($curl);

  if ($err) {
    echo "cURL Error #:" . $err;
  } else {
    echo $response;
  }
  ```

  ```java Java theme={null}
  HttpResponse<String> response = Unirest.post("https://api.dune.com/api/v1/query/{queryId}/private")
    .header("X-DUNE-API-KEY", "<x-dune-api-key>")
    .asString();
  ```
</RequestExample>


# Overview
Source: https://docs.dune.com/api-reference/queries/endpoint/query-object



These query management endpoints help you programmatically create and manage Dune SQL queries via the API, ideal for integration with GitHub or other CI/CD pipelines.

### Queries

Queries all have a `query id` which is returned when you read/create a query. You can also find it within a url, i.e. `https://dune.com/queries/<query_id>/<visualization_id>`.

Each query comes with fields you can edit such as:

* `name`: query name text
* `description`: query description text
* `query_sql`: the raw sql text
* `params`: parameters within the query, using the `{{ foo }}` syntax. See the section below for more details.
* `is_private`: boolean for if query is private or not. Private queries cannot be found or queried by others.
* `archived`: boolean for if query is archived or not. Archived queries cannot be run or edited by anyone.

### Query Parameters

There are four kinds of parameters you can use in a Dune query (these are not API parameters).

* number
* text
* date
* enum (called a list in the UI)

For passing these parameters through the API request body, you can use the following format for executions:

```json theme={null}
{
"foo": "value",
"bar":1000, 
"baz": "2020-12-01T01:20:30Z"
}
```

Where "foo", "bar", and "baz" are three params in a query. If you leave one out, it goes with the default param value.

For Queries endpoints, you'll need to define the type and more:

```json theme={null}
[
    {
        "key": "block_time_start",
        "type": "datetime",
        "value": "2017-01-01 00:00:00"
    },
    {
        "key": "from",
        "type": "text",
        "value": "0xae2fc483527b8ef99eb5d9b44875f005ba1fae13"
    },
    {
        "key": "limit",
        "type": "number",
        "value": "20"
    },
    {
        "key": "type",
        "type": "enum",
        "value": "DynamicFee",
        "enumOptions": [
            "DynamicFee",
            "Legacy"
        ]
    }
]
```

Note that the `datetime` parameter type requires you use the syntax `timestamp '{{block_time_start}}'` to cast the parameter to a timestamp.

If you are using bytearrays/binary (`0x1234...`), then you will still pass it as text through the API but ensure your SQL text puts the parameter without any quotes around it.

<Tip>
  If you're using the Dune Python SDK, check out the [sdk doc page](/api-reference/overview/sdks) for an example.
</Tip>

## Endpoints

| Endpoint Title                             | Endpoint                               | Description                                                                               |
| ------------------------------------------ | -------------------------------------- | ----------------------------------------------------------------------------------------- |
| [List Queries](./list)                     | `GET /v1/queries`                      | Retrieves a paginated list of queries                                                     |
| [Get Query Pipeline](./get-query-pipeline) | `GET /v1/query/{query_id}/pipeline`    | Retrieves the pipeline definition for a query, including dependencies and execution order |
| [Read Query](./read)                       | `GET /v1/query/{query_id}`             | Fetches details of a specific query by ID                                                 |
| [Create Query](./create)                   | `POST /v1/query`                       | Creates a new query with specified parameters                                             |
| [Update Query](./update)                   | `PATCH /v1/query/{query_id}`           | Updates an existing query's properties                                                    |
| [Archive Query](./archive)                 | `PATCH /v1/query/{query_id}/archive`   | Archives a query, preventing it from being run or edited                                  |
| [Unarchive Query](./unarchive)             | `PATCH /v1/query/{query_id}/unarchive` | Unarchives a previously archived query                                                    |
| [Make Query Private](./private)            | `PATCH /v1/query/{query_id}/private`   | Makes a query private, restricting access                                                 |
| [Make Query Public](./unprivate)           | `PATCH /v1/query/{query_id}/unprivate` | Makes a private query public                                                              |


# Read Query
Source: https://docs.dune.com/api-reference/queries/endpoint/read

GET /v1/query/{queryId}
This API allows for anyone to read the sql text,
parameters, name, tags, and state of a query.
For private queries, only the API key generated
under the context of the owner of that query will work.

<Info>
  Minimum required API key scope: `Read`
</Info>

<Note>
  To access Query endpoints, an [Analyst plan](https://dune.com/pricing) or higher is required.
</Note>

<RequestExample>
  ```bash cURL theme={null}
  curl --request GET \
    --url https://api.dune.com/api/v1/query/{queryId} \
    --header 'X-DUNE-API-KEY: <x-dune-api-key>'
  ```

  ```python Python SDK theme={null}
  from dune_client.client import DuneClient

  dune = DuneClient()

  query = dune.get_query(1252207)
  ```

  ```python Python theme={null}
  import requests

  url = "https://api.dune.com/api/v1/query/{queryId}"

  headers = {"X-DUNE-API-KEY": "<x-dune-api-key>"}

  response = requests.request("GET", url, headers=headers)

  print(response.text)

  ```

  ```javascript JavaScript theme={null}
  const options = {method: 'GET', headers: {'X-DUNE-API-KEY': '<x-dune-api-key>'}};

  fetch('https://api.dune.com/api/v1/query/{queryId}', options)
    .then(response => response.json())
    .then(response => console.log(response))
    .catch(err => console.error(err));
  ```

  ```go Go theme={null}
  package main

  import (
  	"fmt"
  	"net/http"
  	"io/ioutil"
  )

  func main() {

  	url := "https://api.dune.com/api/v1/query/{queryId}"

  	req, _ := http.NewRequest("GET", url, nil)

  	req.Header.Add("X-DUNE-API-KEY", "<x-dune-api-key>")

  	res, _ := http.DefaultClient.Do(req)

  	defer res.Body.Close()
  	body, _ := ioutil.ReadAll(res.Body)

  	fmt.Println(res)
  	fmt.Println(string(body))

  }
  ```

  ```php PHP theme={null}
  <?php

  $curl = curl_init();

  curl_setopt_array($curl, [
    CURLOPT_URL => "https://api.dune.com/api/v1/query/{queryId}",
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_ENCODING => "",
    CURLOPT_MAXREDIRS => 10,
    CURLOPT_TIMEOUT => 30,
    CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
    CURLOPT_CUSTOMREQUEST => "GET",
    CURLOPT_HTTPHEADER => [
      "X-DUNE-API-KEY: <x-dune-api-key>"
    ],
  ]);

  $response = curl_exec($curl);
  $err = curl_error($curl);

  curl_close($curl);

  if ($err) {
    echo "cURL Error #:" . $err;
  } else {
    echo $response;
  }
  ```

  ```java Java theme={null}
  HttpResponse<String> response = Unirest.get("https://api.dune.com/api/v1/query/{queryId}")
    .header("X-DUNE-API-KEY", "<x-dune-api-key>")
    .asString();
  ```
</RequestExample>


# Unarchive Query
Source: https://docs.dune.com/api-reference/queries/endpoint/unarchive

POST /v1/query/{queryId}/unarchive
This API allows for anyone to unarchive a query. Only the API key
generated under the context of the owner of that query will work.

<Info>
  Minimum required API key scope: `Read/Write`
</Info>

<Note>
  To access Query endpoints, an [Analyst plan](https://dune.com/pricing) or higher is required.
</Note>

<Tip>
  In Dune context, delete action is replaced by archive as deletion of queries is not possible.
</Tip>

<RequestExample>
  ```bash cURL theme={null}
  curl --request GET \
    --url https://api.dune.com/api/v1/query/{queryId}/unarchive \
    --header 'X-DUNE-API-KEY: <x-dune-api-key>'
  ```

  ```python Python SDK theme={null}
  from dune_client.client import DuneClient

  dune = DuneClient()

  query = dune.unarchive_query(1252207)
  ```

  ```python Python theme={null}
  import requests

  url = "https://api.dune.com/api/v1/query/{queryId}/unarchive"

  headers = {"X-DUNE-API-KEY": "<x-dune-api-key>"}

  response = requests.request("GET", url, headers=headers)

  print(response.text)

  ```

  ```javascript JavaScript theme={null}
  const options = {method: 'GET', headers: {'X-DUNE-API-KEY': '<x-dune-api-key>'}};

  fetch('https://api.dune.com/api/v1/query/{queryId}/unarchive', options)
    .then(response => response.json())
    .then(response => console.log(response))
    .catch(err => console.error(err));
  ```

  ```go Go theme={null}
  package main

  import (
  	"fmt"
  	"net/http"
  	"io/ioutil"
  )

  func main() {

  	url := "https://api.dune.com/api/v1/query/{queryId}/unarchive"

  	req, _ := http.NewRequest("GET", url, nil)

  	req.Header.Add("X-DUNE-API-KEY", "<x-dune-api-key>")

  	res, _ := http.DefaultClient.Do(req)

  	defer res.Body.Close()
  	body, _ := ioutil.ReadAll(res.Body)

  	fmt.Println(res)
  	fmt.Println(string(body))

  }
  ```

  ```php PHP theme={null}
  <?php

  $curl = curl_init();

  curl_setopt_array($curl, [
    CURLOPT_URL => "https://api.dune.com/api/v1/query/{queryId}/unarchive",
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_ENCODING => "",
    CURLOPT_MAXREDIRS => 10,
    CURLOPT_TIMEOUT => 30,
    CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
    CURLOPT_CUSTOMREQUEST => "GET",
    CURLOPT_HTTPHEADER => [
      "X-DUNE-API-KEY: <x-dune-api-key>"
    ],
  ]);

  $response = curl_exec($curl);
  $err = curl_error($curl);

  curl_close($curl);

  if ($err) {
    echo "cURL Error #:" . $err;
  } else {
    echo $response;
  }
  ```

  ```java Java theme={null}
  HttpResponse<String> response = Unirest.get("https://api.dune.com/api/v1/query/{queryId}/unarchive")
    .header("X-DUNE-API-KEY", "<x-dune-api-key>")
    .asString();
  ```
</RequestExample>


# Unprivate Query
Source: https://docs.dune.com/api-reference/queries/endpoint/unprivate

POST /v1/query/{queryId}/unprivate
This API allows for anyone to unprivate a query. Only the API key
generated under the context of the owner of that query will work.

<Info>
  Minimum required API key scope: `Read/Write`
</Info>

<Note>
  To access Query endpoints, an [Analyst plan](https://dune.com/pricing) or higher is required.
</Note>

<RequestExample>
  ```bash cURL theme={null}
  curl --request POST \
    --url https://api.dune.com/api/v1/query/{queryId}/unprivate \
    --header 'X-DUNE-API-KEY: <x-dune-api-key>'
  ```

  ```python Python SDK theme={null}
  from dune_client.client import DuneClient

  dune = DuneClient()

  query = dune.unprivate_query(1252207)
  ```

  ```python Python theme={null}
  import requests

  url = "https://api.dune.com/api/v1/query/{queryId}/unprivate"

  headers = {"X-DUNE-API-KEY": "<x-dune-api-key>"}

  response = requests.request("POST", url, headers=headers)

  print(response.text)

  ```

  ```javascript JavaScript theme={null}
  const options = {method: 'POST', headers: {'X-DUNE-API-KEY': '<x-dune-api-key>'}};

  fetch('https://api.dune.com/api/v1/query/{queryId}/unprivate', options)
    .then(response => response.json())
    .then(response => console.log(response))
    .catch(err => console.error(err));
  ```

  ```go Go theme={null}
  package main

  import (
  	"fmt"
  	"net/http"
  	"io/ioutil"
  )

  func main() {

  	url := "https://api.dune.com/api/v1/query/{queryId}/unprivate"

  	req, _ := http.NewRequest("POST", url, nil)

  	req.Header.Add("X-DUNE-API-KEY", "<x-dune-api-key>")

  	res, _ := http.DefaultClient.Do(req)

  	defer res.Body.Close()
  	body, _ := ioutil.ReadAll(res.Body)

  	fmt.Println(res)
  	fmt.Println(string(body))

  }
  ```

  ```php PHP theme={null}
  <?php

  $curl = curl_init();

  curl_setopt_array($curl, [
    CURLOPT_URL => "https://api.dune.com/api/v1/query/{queryId}/unprivate",
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_ENCODING => "",
    CURLOPT_MAXREDIRS => 10,
    CURLOPT_TIMEOUT => 30,
    CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
    CURLOPT_CUSTOMREQUEST => "POST",
    CURLOPT_HTTPHEADER => [
      "X-DUNE-API-KEY: <x-dune-api-key>"
    ],
  ]);

  $response = curl_exec($curl);
  $err = curl_error($curl);

  curl_close($curl);

  if ($err) {
    echo "cURL Error #:" . $err;
  } else {
    echo $response;
  }
  ```

  ```java Java theme={null}
  HttpResponse<String> response = Unirest.post("https://api.dune.com/api/v1/query/{queryId}/unprivate")
    .header("X-DUNE-API-KEY", "<x-dune-api-key>")
    .asString();
  ```
</RequestExample>


# Update Query
Source: https://docs.dune.com/api-reference/queries/endpoint/update

PATCH /v1/query/{queryId}
This API allows for anyone to update the sql text,
parameters, name, tags, and state of a query. Only the API key
generated under the context of the owner of that query will work.

<Info>
  Minimum required API key scope: `Read/Write`
</Info>

<Note>
  To access Query endpoints, an [Analyst plan](https://dune.com/pricing) or higher is required.
</Note>

<RequestExample>
  ```bash cURL theme={null}
  curl --request PATCH \
    --url https://api.dune.com/api/v1/query/{queryId} \
    --header 'Content-Type: application/json' \
    --header 'X-DUNE-API-KEY: <x-dune-api-key>' \
    --data '{
    "query_id": 1252207,
    "query_sql": "SELECT * FROM {{blockchain}}.transactions WHERE to = {{address}} AND block_number > {{blocknumber}}",
  }'
  ```

  ```python Python SDK theme={null}
  from dune_client.types import QueryParameter
  from dune_client.client import DuneClient
  from dune_client.query import QueryBase

  dune = DuneClient()

  query = dune.update_query(
      query_sql="SELECT * FROM {{blockchain}}.transactions WHERE to = {{address}} AND block_number > {{blocknumber}}"
  )
  ```

  ```python Python theme={null}
  curl --request PATCH \
    --url https://api.dune.com/api/v1/query/{queryId} \
    --header 'Content-Type: application/json' \
    --header 'X-DUNE-API-KEY: <x-dune-api-key>' \
    --data '{
    "query_id": 1252207,
    "query_sql": "{{blockchain}}.transactions WHERE to = {{address}} AND block_number > {{blocknumber}}"
  }'
  ```

  ```javascript JavaScript theme={null}
  const options = {
    method: 'PATCH',
    headers: {'X-DUNE-API-KEY': '<x-dune-api-key>', 'Content-Type': 'application/json'},
    body: '{"query_id":1252207,"query_sql":"{{blockchain}}.transactions WHERE to = {{address}} AND block_number > {{blocknumber}}"}'
  };

  fetch('https://api.dune.com/api/v1/query/{queryId}', options)
    .then(response => response.json())
    .then(response => console.log(response))
    .catch(err => console.error(err));
  ```

  ```go Go theme={null}
  package main

  import (
  	"fmt"
  	"strings"
  	"net/http"
  	"io/ioutil"
  )

  func main() {

  	url := "https://api.dune.com/api/v1/query/{queryId}"

  	payload := strings.NewReader("{\n  \"query_id\": 1252207,\n  ,\n  \"query_sql\": \"{{blockchain}}.transactions WHERE to = {{address}} AND block_number > {{blocknumber}}\"}")

  	req, _ := http.NewRequest("PATCH", url, payload)

  	req.Header.Add("X-DUNE-API-KEY", "<x-dune-api-key>")
  	req.Header.Add("Content-Type", "application/json")

  	res, _ := http.DefaultClient.Do(req)

  	defer res.Body.Close()
  	body, _ := ioutil.ReadAll(res.Body)

  	fmt.Println(res)
  	fmt.Println(string(body))

  }
  ```

  ```php PHP theme={null}
  <?php

  $curl = curl_init();

  curl_setopt_array($curl, [
    CURLOPT_URL => "https://api.dune.com/api/v1/query/{queryId}",
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_ENCODING => "",
    CURLOPT_MAXREDIRS => 10,
    CURLOPT_TIMEOUT => 30,
    CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
    CURLOPT_CUSTOMREQUEST => "PATCH",
    CURLOPT_POSTFIELDS => "{\n  \"query_id\": 1252207,\n  \"query_sql\": \"{{blockchain}}.transactions WHERE to = {{address}} AND block_number > {{blocknumber}}\"}",
    CURLOPT_HTTPHEADER => [
      "Content-Type: application/json",
      "X-DUNE-API-KEY: <x-dune-api-key>"
    ],
  ]);

  $response = curl_exec($curl);
  $err = curl_error($curl);

  curl_close($curl);

  if ($err) {
    echo "cURL Error #:" . $err;
  } else {
    echo $response;
  }
  ```

  ```java Java theme={null}
  HttpResponse<String> response = Unirest.patch("https://api.dune.com/api/v1/query/{queryId}")
    .header("X-DUNE-API-KEY", "<x-dune-api-key>")
    .header("Content-Type", "application/json")
    .body("{\n  \"query_id\": 1252207,\n  \"query_sql\": \"{{blockchain}}.transactions WHERE to = {{address}} AND block_number > {{blocknumber}}\"}")
    .asString();
  ```
</RequestExample>


# Query Management
Source: https://docs.dune.com/api-reference/quickstart/queries-eg



In this quickstart, we will walk through how to turn any dashboard (or set of queries) into a GitHub repository that uses our query management API.

### Set up a new repo from the GitHub template

Use [this GitHub template](https://github.com/duneanalytics/DuneQueryRepo) to create your own repository, then follow these steps:

1. Generate an API key from your Dune account and put that in both your `.env` file and [github action secrets](https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#creating-secrets-for-a-repository) (name it `DUNE_API_KEY`). You can create a key under your Dune team settings. *The api key must be from a plus plan for this repo to work.*

2. Type your intended query ids into the `queries.yml` file. The id can be found from the link `https://dune.com/queries/<query_id>/...`. If you're creating this for a dashboard, go to the dashboard you want to create a repo and click on the "github" button in the top right of your dashboard to see the query ids.

3. Then, run `pull_from_dune.py` to bring in all queries into `/query_{id}.sql` files within the `/queries` folder. Directions to setup and run this python script are below.

### Updating Queries or CSV Tables

1. Make any changes you need to directly in the repo. Any time you push a commit to MAIN branch, `push_to_dune.py` will save your changes into Dune directly. You can run this manually too if you want.

2. For CSVs, update the files in the `/uploads` folder. `upload_to_dune.py` will run on commit, or can be run manually. The table name in Dune will be `dune.team_name.dataset_<filename>`.

<Tip>
  You can press the "github" button on your own dashboard to get a list of query ids, or you can just paste in any query ids yourself. The query id comes from the url, `dune.com/queries/<query_id>/<visualization_id>`.
</Tip>

Anytime you commit a change to the repo, it will now update your queries in the app too. You can run `pull_from_dune.py` anytime to update the repo with any changes from the app.


# Execution & Results
Source: https://docs.dune.com/api-reference/quickstart/results-eg



In this quickstart, we will walk through how to fetch Dune data in Python.

<Note>
  ⌨️ For a quickstart on TypeScript, please [download Dune TypeScript SDK](https://github.com/bh2smith/ts-dune-client?tab=readme-ov-file) and [follow this demo project](https://github.com/bh2smith/demo-ts-dune-client).
</Note>

### Prerequisites

* Python environment set up (check out [uv](https://github.com/astral-sh/uv) if you want somewhere to start.)
* Have a Dune API key from the team/user who's queries you want to manage (to obtain one [follow the steps here](../overview/authentication#generate-an-api-key))

### Step 1: Prepare your Dune query

Have a Dune query you'd like to pull data from. Here, we'll use [this query](https://dune.com/queries/3373921/5660178) to get the DAI token balance for vitalik.eth.

### Step 2: Install Dune Python SDK

Ensure the [Dune Python SDK](https://pypi.org/project/dune-client/) is installed in your environment. You can install it using pip:

```
pip install dune-client
```

### Step 3: Get data from Dune query

#### Set up a Dune Python client

The API key might either be supplied in the constructor or read through environment variables.
The follow env variables might be supplied: `DUNE_API_KEY`, `DUNE_API_BASE_URL`, `DUNE_API_REQUEST_TIMEOUT`.

```python theme={null}
from dune_client.client import DuneClient

dune = DuneClient(
    api_key='<paste your api key here>',
    base_url="https://api.dune.com",
    request_timeout=300
)
```

#### Get query result

You can choose to either get the latest query result without triggering an execution or to trigger an execution and get the result to ensure freshest data.

<Tabs>
  <Tab title="Get latest result without execution">
    ```python theme={null}
      query_result = dune.get_latest_result(3373921) # get latest result in json format
      # query_result = dune.get_latest_result_dataframe(3373921) # get latest result in Pandas dataframe format
    ```
  </Tab>

  <Tab title="Query a query">
    ```python theme={null}
    query = QueryBase(
        query_id=3373921,

        # uncomment and change the parameter values if needed
        # params=[
        #     QueryParameter.text_type(name="contract", value="0x6B175474E89094C44Da98b954EedeAC495271d0F"), # default is DAI
        #     QueryParameter.text_type(name="owner", value="owner"), # default using vitalik.eth's wallet 
        # ],
    )

    query_result = dune.run_query_dataframe(
      query=query
      # , ping_frequency = 10 # uncomment to change the seconds between checking execution status, default is 1 second
      # , performance="large" # uncomment to run query on large engine, default is medium
      # , batch_size = 5_000 # uncomment to change the maximum number of rows to retrieve per batch of results, default is 32_000
    ) 

    # Note: to get the result in csv format, call run_query_csv(); for json format, call run_query().
    ```
  </Tab>
</Tabs>

<Note>
  * To paginate query results, please visit the [pagination page](../executions/pagination) to get more info.
  * If you are using the [Python SDK](https://github.com/duneanalytics/dune-client/tree/main):
    * For [higher level functions](https://github.com/duneanalytics/dune-client/blob/main/dune_client/api/extensions.py) like `run_query()`, pagination is handled for you automatically behind the scene, so you will get the entire dataset as the returned result. You can pass in parameter `batch_size` to define the maximum number of rows per batch or pagination call.
    * For [lower level functions](https://github.com/duneanalytics/dune-client/blob/main/dune_client/api/execution.py) like `get_execution_results()`, you can pass in pagination parameters `limit` and `offset` directly, as instructed [here](../executions/pagination#pagination-parameters).
</Note>

### Putting it all together

```python theme={null}
from dune_client.client import DuneClient
from dune_client.query import QueryBase

# setup Dune Python client
dune = DuneClient()

# get the latest executed result without triggering a new execution
query_result = dune.get_latest_result(3373921) # get latest result in json format


# query the query (execute and get latest result)
query = QueryBase(
    query_id=3373921,

    # uncomment and change the parameter values if needed
    # params=[
    #     QueryParameter.text_type(name="contract", value="0x6B175474E89094C44Da98b954EedeAC495271d0F"), # default is DAI
    #     QueryParameter.text_type(name="owner", value="owner"), # default using vitalik.eth's wallet 
    # ],
)

query_result = dune.run_query_dataframe(
  query=query
  # , ping_frequency = 10 # uncomment to change the seconds between checking execution status, default is 1 second
  # , performance="large" # uncomment to run query on large engine, default is medium
  # , batch_size = 5_000 # uncomment to change the maximum number of rows to retrieve per batch of results, default is 32_000
) 
```


# Tables Management
Source: https://docs.dune.com/api-reference/quickstart/tables-eg



In this quickstart, we will walk through how to upload a CSV file to Dune via Python.

### Upload the CSV

Follow below steps to upload your CSV.

```python theme={null}
from dune_client.client import DuneClient

# setup Dune Python client
dune = DuneClient()

# define path to your CSV file 
csv_file_path = '<CSV_FILE_PATH>'

with open(csv_file_path) as open_file:
    data = open_file.read()

    table = dune.upload_csv(
        data=str(data),
        description="Data about 80 cereals, sourced from https://www.kaggle.com/datasets/crawford/80-cereals",
        table_name="cereal_table", # define your table name here
        is_private=False
    )
```

Once the upload is successful, you will see the data show up under [Your Data](https://dune.com/queries?category=uploaded_data) in the Data Explorer.

You can query your uploaded table under the name `dune.<team or user handle>.dataset_<table name defined>`. For example, here I defined the table name to be "cereal\_table" and my team name is "dune", so to access the uploaded table we will do `select * from dune.dune.dataset_cereal_table`

For more information on upload endpoint, please [visit this page](../tables/endpoint/upload).


# Overview
Source: https://docs.dune.com/api-reference/realtime/overview



Sim APIs are a dedicated, high-performance suite of developer-focused APIs by Dune, designed for building realtime, multichain apps with exceptional developer experience. Sim APIs offer fast and reliable access to EVM and SVM blockchain data.

<CardGroup>
  <Card title="Visit Sim Website" icon="globe" href="https://sim.dune.com">
    Explore the official Sim website to learn more about its features, capabilities, and how it can power your apps.
  </Card>

  <Card title="View Sim Docs" icon="book" href="https://docs.sim.dune.com">
    Dive into the comprehensive Sim API docs, including quickstarts, detailed API references, and guides.
  </Card>
</CardGroup>

<Note>
  **Sim APIs are an upgraded version of what was previously known as Dune Echo.** They offer improved performance and a broader set of features for developers.
</Note>


# Go
Source: https://docs.dune.com/api-reference/sdks/go

Go SDK for Dune Data API

We have a Go client available at [github.com/duneanalytics/duneapi-client-go](https://github.com/duneanalytics/duneapi-client-go).

## Installation

To install the SDK, run the following command:

```bash theme={null}
go get github.com/duneanalytics/duneapi-client-go
```

## Quick Start

Initialize the client and execute a query:

```go theme={null}
package main

import (
    "fmt"
    "os"
    
    "github.com/duneanalytics/duneapi-client-go"
)

func main() {
    // Initialize client with API key
    client := duneapi.New(os.Getenv("DUNE_API_KEY"))
    
    // Execute a query
    queryID := 1215383
    results, err := client.ExecuteQuery(queryID)
    if err != nil {
        panic(err)
    }
    
    // Process results
    fmt.Printf("Got %d rows\n", len(results.Rows))
    for _, row := range results.Rows {
        fmt.Printf("%+v\n", row)
    }
}
```

## Error Handling

The Go client follows idiomatic Go error handling patterns:

```go theme={null}
results, err := client.ExecuteQuery(queryID)
if err != nil {
    // Handle error
    log.Printf("Error executing query: %v", err)
    return
}

// Use results
fmt.Println(results)
```

## Additional Resources

<CardGroup>
  <Card title="GitHub Repository" icon="github" href="https://github.com/duneanalytics/duneapi-client-go">
    View source code and documentation
  </Card>

  <Card title="Go Package" icon="golang" href="https://pkg.go.dev/github.com/duneanalytics/duneapi-client-go">
    View on pkg.go.dev
  </Card>

  <Card title="Report Issues" icon="bug" href="https://github.com/duneanalytics/duneapi-client-go/issues">
    Report bugs or request features
  </Card>

  <Card title="API Reference" icon="book" href="/api-reference/executions/execution-object">
    View full API documentation
  </Card>
</CardGroup>


# Python
Source: https://docs.dune.com/api-reference/sdks/python

Official Python SDK for Dune Data API

We currently support a [Python SDK](https://github.com/duneanalytics/dune-client) for working with our API. You'll find `Python SDK` snippets on all endpoint pages. If you want to go deeper into the code, check out [these files](https://github.com/duneanalytics/dune-client/tree/main/dune_client/api).

## Installation

To install the SDK, run the following command in your terminal:

```bash theme={null}
pip install dune-client
```

<Warning>
  Be sure you are using the latest release. You can find all release versions [here](https://github.com/duneanalytics/dune-client/releases) - there may be code added to the repo that has not been put into a release yet.
</Warning>

## Quick Start

Initialize the client with your API key:

```python theme={null}
from dune_client.client import DuneClient

# Initialize client
dune = DuneClient(api_key="YOUR_API_KEY")
```

## Working with Queries

You will commonly work with the `QueryBase` class which can be created like this:

```python theme={null}
from dune_client.query import QueryBase
from dune_client.types import QueryParameter

query = QueryBase(
    name="Sample Query",
    query_id=1215383,
    params=[
        QueryParameter.text_type(name="TextField", value="Word"),
        QueryParameter.number_type(name="NumberField", value=3.1415926535),
        QueryParameter.date_type(name="DateField", value="2022-05-04 00:00:00"),
        QueryParameter.enum_type(name="EnumField", value="Option 1"),
    ],
)
print("Results available at", query.url())
```

The query object is defined as `QueryBase` and all properties can be found [in this file](https://github.com/duneanalytics/dune-client/blob/main/dune_client/query.py).

## Executing Queries

Execute a query and get results:

```python theme={null}
from dune_client.client import DuneClient
from dune_client.query import QueryBase

dune = DuneClient(api_key="YOUR_API_KEY")

query = QueryBase(
    name="Sample Query",
    query_id=1215383,
)

# Execute the query
results = dune.run_query(query)
```

## Working with Results

Other classes such as execution results can be [found here](https://github.com/duneanalytics/dune-client/blob/main/dune_client/models.py#L244C7-L244C22), detailing operations like `ResultsResponse.get_rows()` for getting the data out of a GET request.

### Using Pandas DataFrames

If you are trying to load data into a Pandas DataFrame, you can use the following function from the SDK:

```python theme={null}
# Get results as a DataFrame
results_df = dune.run_query_dataframe(query)
```

## Additional Resources

<CardGroup>
  <Card title="GitHub Repository" icon="github" href="https://github.com/duneanalytics/dune-client">
    View source code, examples, and full documentation
  </Card>

  <Card title="API Files" icon="code" href="https://github.com/duneanalytics/dune-client/tree/main/dune_client/api">
    Explore the API implementation
  </Card>

  <Card title="Releases" icon="tag" href="https://github.com/duneanalytics/dune-client/releases">
    Check the latest release versions
  </Card>

  <Card title="Report Issues" icon="bug" href="https://github.com/duneanalytics/dune-client/issues">
    Report bugs or request features
  </Card>
</CardGroup>


# TypeScript
Source: https://docs.dune.com/api-reference/sdks/typescript

TypeScript/JavaScript SDK for Dune Data API

We have a community client that can be [found here](https://www.npmjs.com/package/@duneanalytics/client-sdk).

## Installation

To install, run this command:

```bash theme={null}
yarn add @duneanalytics/client-sdk
```

Or with npm:

```bash theme={null}
npm install @duneanalytics/client-sdk
```

<Note>
  Currently this client only supports the execution based endpoints, and not Query Endpoints or uploads.
</Note>

## Quick Start

Initialize the client and run a query:

```typescript theme={null}
import { QueryParameter, DuneClient } from "@duneanalytics/client-sdk";
const { DUNE_API_KEY } = process.env;

const client = new DuneClient(DUNE_API_KEY ?? "");
const queryID = 1215383;
const params = {
  query_parameters: [
    QueryParameter.text("TextField", "Plain Text"),
    QueryParameter.number("NumberField", 3.1415926535),
    QueryParameter.date("DateField", "2022-05-04 00:00:00"),
    QueryParameter.enum("ListField", "Option 1"),
  ]
};

client
  .runQuery(queryID, params)
  .then((executionResult) => console.log(executionResult.result?.rows));
```

## Working with Query Parameters

The SDK provides helper functions for creating typed query parameters:

* `QueryParameter.text(name, value)` - For text parameters
* `QueryParameter.number(name, value)` - For number parameters
* `QueryParameter.date(name, value)` - For date parameters
* `QueryParameter.enum(name, value)` - For enum/list parameters

## Additional Resources

<CardGroup>
  <Card title="NPM Package" icon="npm" href="https://www.npmjs.com/package/@duneanalytics/client-sdk">
    View package on NPM
  </Card>

  <Card title="GitHub Repository" icon="github" href="https://github.com/duneanalytics/ts-dune-client">
    View source code and documentation
  </Card>

  <Card title="Report Issues" icon="bug" href="https://github.com/duneanalytics/ts-dune-client/issues">
    Report bugs or request features
  </Card>

  <Card title="API Reference" icon="book" href="/api-reference/executions/execution-object">
    View full API documentation
  </Card>
</CardGroup>


# Migration Guide
Source: https://docs.dune.com/api-reference/tables/endpoint/migration

Migrate from deprecated /v1/table/* endpoints to /v1/uploads/*

# Endpoint Migration Guide

The table endpoints have been migrated from `/v1/table/*` to `/v1/uploads/*` for better discoverability and consistency. The old endpoints are deprecated but remain functional for backward compatibility.

<Warning>
  **Deprecated endpoints will be removed in a future version.** Please migrate
  to the new endpoints as soon as possible.
</Warning>

## Endpoint Mapping

| Old Endpoint (Deprecated)                      | New Endpoint                                                         |
| ---------------------------------------------- | -------------------------------------------------------------------- |
| `POST /v1/table/create`                        | [`POST /v1/uploads`](./uploads-create)                               |
| `POST /v1/table/:namespace/:table_name/insert` | [`POST /v1/uploads/:namespace/:table_name/insert`](./uploads-insert) |
| `POST /v1/table/upload/csv`                    | [`POST /v1/uploads/csv`](./uploads-csv)                              |
| `POST /v1/table/:namespace/:table_name/clear`  | [`POST /v1/uploads/:namespace/:table_name/clear`](./uploads-clear)   |
| `DELETE /v1/table/:namespace/:table_name`      | [`DELETE /v1/uploads/:namespace/:table_name`](./uploads-delete)      |
| `GET /v1/tables`                               | [`GET /v1/uploads`](./uploads-list)                                  |

## What Changed?

### URL Structure

All table management endpoints now use the `/v1/uploads` base path instead of `/v1/table` or `/v1/tables`. This change makes it clearer that these endpoints are specifically for managing uploaded tables.

## Migration Examples

### Create Table

**Before:**

```bash theme={null}
curl -X POST "https://api.dune.com/api/v1/table/create" \
  -H "X-DUNE-API-KEY: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "namespace": "my_user",
    "table_name": "interest_rates",
    "schema": [
      {"name": "date", "type": "timestamp"},
      {"name": "rate", "type": "double"}
    ]
  }'
```

**After:**

```bash theme={null}
curl -X POST "https://api.dune.com/api/v1/uploads" \
  -H "X-DUNE-API-KEY: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "namespace": "my_user",
    "table_name": "interest_rates",
    "schema": [
      {"name": "date", "type": "timestamp"},
      {"name": "rate", "type": "double"}
    ]
  }'
```

### Insert Data

**Before:**

```bash theme={null}
curl -X POST "https://api.dune.com/api/v1/table/my_user/interest_rates/insert" \
  -H "X-DUNE-API-KEY: YOUR_API_KEY" \
  -H "Content-Type: text/csv" \
  --upload-file data.csv
```

**After:**

```bash theme={null}
curl -X POST "https://api.dune.com/api/v1/uploads/my_user/interest_rates/insert" \
  -H "X-DUNE-API-KEY: YOUR_API_KEY" \
  -H "Content-Type: text/csv" \
  --upload-file data.csv
```

### Upload CSV

**Before:**

```bash theme={null}
curl -X POST "https://api.dune.com/api/v1/table/upload/csv" \
  -H "X-DUNE-API-KEY: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "table_name": "my_table",
    "data": "col1,col2\nval1,val2",
    "is_private": false
  }'
```

**After:**

```bash theme={null}
curl -X POST "https://api.dune.com/api/v1/uploads/csv" \
  -H "X-DUNE-API-KEY: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "table_name": "my_table",
    "data": "col1,col2\nval1,val2",
    "is_private": false
  }'
```

### Clear Table

**Before:**

```bash theme={null}
curl -X POST "https://api.dune.com/api/v1/table/my_user/interest_rates/clear" \
  -H "X-DUNE-API-KEY: YOUR_API_KEY"
```

**After:**

```bash theme={null}
curl -X POST "https://api.dune.com/api/v1/uploads/my_user/interest_rates/clear" \
  -H "X-DUNE-API-KEY: YOUR_API_KEY"
```

### Delete Table

**Before:**

```bash theme={null}
curl -X DELETE "https://api.dune.com/api/v1/table/my_user/interest_rates" \
  -H "X-DUNE-API-KEY: YOUR_API_KEY"
```

**After:**

```bash theme={null}
curl -X DELETE "https://api.dune.com/api/v1/uploads/my_user/interest_rates" \
  -H "X-DUNE-API-KEY: YOUR_API_KEY"
```

### List Tables

**Before:**

```bash theme={null}
curl -X GET "https://api.dune.com/api/v1/tables?limit=10&offset=0" \
  -H "X-DUNE-API-KEY: YOUR_API_KEY"
```

**After:**

```bash theme={null}
curl -X GET "https://api.dune.com/api/v1/uploads?limit=10&offset=0" \
  -H "X-DUNE-API-KEY: YOUR_API_KEY"
```

## SDK Support

### Python SDK

The Dune Python SDK will be updated to support the new endpoints. Check the [Python SDK documentation](https://github.com/duneanalytics/dune-client) for the latest version and migration guidance.

### TypeScript SDK

The Dune TypeScript SDK will be updated to support the new endpoints. Check the [TypeScript SDK documentation](https://github.com/duneanalytics/dune-client-ts) for the latest version and migration guidance.

## Backward Compatibility

All deprecated endpoints continue to function and will remain available for a transition period. However, we strongly recommend migrating to the new endpoints to ensure compatibility with future versions of the API.

## Timeline

* **Backend Migration**: ✅ Complete
* **Documentation Migration**: ✅ Complete
* **Deprecation Period**: 3 months (until March 1, 2026)
* **Old Endpoint Removal**: **March 1, 2026**

## Need Help?

If you encounter any issues during migration, please:

* Check the [current endpoint documentation](./uploads-list)
* Review the [API reference overview](./overview)
* Contact [Dune support](mailto:support@dune.com)


# Overview
Source: https://docs.dune.com/api-reference/tables/endpoint/overview



<Note>
  **Endpoint Migration Notice**: The table upload endpoints have been updated from `/v1/table/*` to `/v1/uploads/*`. The old endpoints are deprecated but still fully functional and **will be removed on March 1, 2026**. **Request parameters and response bodies remain unchanged.**

  | Old Endpoint (Deprecated)                      | New Endpoint                                     |
  | ---------------------------------------------- | ------------------------------------------------ |
  | `POST /v1/table/create`                        | `POST /v1/uploads`                               |
  | `POST /v1/table/:namespace/:table_name/insert` | `POST /v1/uploads/:namespace/:table_name/insert` |
  | `POST /v1/table/upload/csv`                    | `POST /v1/uploads/csv`                           |
  | `POST /v1/table/:namespace/:table_name/clear`  | `POST /v1/uploads/:namespace/:table_name/clear`  |
  | `DELETE /v1/table/:namespace/:table_name`      | `DELETE /v1/uploads/:namespace/:table_name`      |
  | `GET /v1/tables`                               | `GET /v1/uploads`                                |

  For detailed migration examples, see the [Migration Guide](./migration).
</Note>

# Table Upload Methods: Two Approaches

Dune provides two distinct methods for uploading data to create queryable tables. Each method serves different use cases and offers unique advantages and trade-offs.

## Method 1: CSV Upload - Simple but Inflexible

The CSV upload method is the most straightforward way to get data into Dune, designed for users who want quick and easy data uploads without complex setup requirements.

### How It Works

* **UI Upload**: Click "Upload Data" in Dune interface, select CSV file, name your table, add description, and save
* **API Upload**: Use the [`/upload endpoint`](./uploads-csv) to programmatically upload CSV files
* **Schema**: Automatically inferred from CSV data (no manual schema definition required)
* **Table Naming**: Results in `dune.team_name.dataset_name` format

### Key Characteristics

**Advantages:**

* **Simplicity**: Minimal setup required - just upload and go
* **User-Friendly**: Perfect for non-technical users
* **Quick Start**: Immediate data availability for querying
* **Automatic Processing**: Schema inference handles data types automatically
* **Both UI and API**: Available through web interface or programmatic upload

**Limitations:**

* **Size Constraint**: Maximum 200MB file size limit
* **No Incremental Updates**: Must replace entire table to update data
* **Limited Control**: Cannot modify schema after upload
* **File Format**: Only supports CSV format
* **Inflexible Schema**: Stuck with automatically inferred data types
* **No Append Operations**: Cannot add new rows to existing data

### Best Use Cases

* Small to medium datasets (under 200MB)
* One-time data uploads
* Static datasets that don't need frequent updates
* Prototyping and experimentation
* Users without programming experience

### Credit Usage

* Free Plan: 1,000 data points per credit (2,500 credits total)
* Analyst Plan: 1,000 data points per credit (4,000 credits total)
* Plus Plan: 5,000 data points per credit (25,000 credits total)

***

## Method 2: Programmatic Table Management - Flexible but Complex

The programmatic approach uses a combination of four API endpoints ([`create`](./uploads-create), [`insert`](./uploads-insert), [`clear`](./uploads-clear), [`delete`](./uploads-delete)) to provide full control over table lifecycle and data management.

### Core Operations

#### 1. **Create Table** ([`POST /v1/uploads`](./uploads-create))

* Define table schema explicitly with column names, types, and nullability
* Set table as public or private
* Specify namespace and table name
* **Cost**: 10 credits per successful table creation

#### 2. **Insert Data** ([`POST /v1/uploads/:namespace/:table_name/insert`](./uploads-insert))

* Add new rows to existing tables
* Support for incremental data loading
* Append operations without replacing existing data
* JSON payload with structured data

#### 3. **Clear Data** ([`POST /v1/uploads/:namespace/:table_name/clear`](./uploads-clear))

* Remove all data from table while preserving schema
* Useful for complete data refreshes
* Table structure remains intact

#### 4. **Delete Table** ([`DELETE /v1/uploads/:namespace/:table_name`](./uploads-delete))

* Permanently remove table and all its data
* Complete cleanup operation
* Irreversible action

### Key Characteristics

**Advantages:**

* **Full Control**: Complete management of table lifecycle
* **Incremental Updates**: Add data without replacing existing content
* **Large Data Support**: No 200MB size limitation
* **Custom Schema**: Define exact data types, constraints, and structure
* **Append Operations**: Add new rows while keeping existing data
* **Flexible Updates**: Clear and refresh data as needed
* **Programmatic**: Perfect for automated workflows and ETL pipelines
* **Privacy Control**: Set tables as public or private

**Limitations:**

* **Complexity**: Requires more technical knowledge and setup
* **Schema Management**: Must manually define and maintain schema
* **Multiple API Calls**: Requires orchestration of multiple endpoints
* **Higher Learning Curve**: More complex implementation
* **Credit Consumption**: Table creation costs 10 credits

### Typical Workflow

1. **Create** table with defined schema
2. **Insert** initial data batch
3. **Insert** additional data as needed (append operations)
4. **Clear** table when full refresh is needed
5. **Insert** new complete dataset
6. **Delete** table when no longer needed

### Best Use Cases

* Large datasets (over 200MB)
* Frequently updated data requiring incremental loads
* Production ETL pipelines
* Applications needing precise schema control
* Automated data workflows
* Complex data structures with specific type requirements

***

## Comparison Matrix

| Aspect                  | CSV Upload           | Programmatic Management  |
| ----------------------- | -------------------- | ------------------------ |
| **Complexity**          | Low                  | High                     |
| **Setup Time**          | Minutes              | Hours/Days               |
| **Size Limit**          | 200MB                | No limit                 |
| **Schema Control**      | Automatic            | Manual definition        |
| **Update Method**       | Replace entire table | Incremental appends      |
| **API Calls Required**  | 1                    | Multiple (2-4)           |
| **Learning Curve**      | Minimal              | Steep                    |
| **Automation Friendly** | Limited              | Excellent                |
| **Credit Cost**         | Data points only     | 10 credits + data points |
| **Privacy Options**     | Public/Private       | Public/Private           |
| **Error Recovery**      | Limited              | Granular control         |

***

## Decision Framework

### Choose CSV Upload When:

* Dataset is under 200MB
* Data updates are infrequent
* Quick prototyping or one-off analysis
* Non-technical user or minimal programming resources
* Simple data structure with standard types
* Time to market is critical

### Choose Programmatic Management When:

* Dataset exceeds 200MB
* Regular data updates required
* Part of automated data pipeline
* Need precise control over data types
* Building production applications
* Require incremental data loading
* Complex data workflows with dependencies

***

## Implementation Considerations

<Note>
  **Security & Authentication**
  Both methods require:

  * Dune API key authentication
  * Proper credential management
  * Team/user context considerations
</Note>

**Performance & Scalability**

* **CSV Upload**: Limited by file size and processing time
* **Programmatic**: Scalable for large datasets, can handle concurrent operations

**Monitoring & Maintenance**

* **CSV Upload**: Minimal monitoring needed
* **Programmatic**: Requires error handling, retry logic, and workflow orchestration

**Cost Management**

* Both methods consume credits based on data volume
* Programmatic method has additional table creation costs
* Consider credit consumption in high-frequency update scenarios

***

## Recommendation

For most users starting with Dune, CSV upload provides an excellent entry point due to its simplicity and speed for smaller, static datasets. As data complexity and automation requirements grow, migrating to programmatic table management becomes advantageous for maintaining scalable, reliable data pipelines.

The choice ultimately depends on your technical requirements, data volume, and update frequency. CSV upload excels in simplicity, while programmatic management provides the flexibility and control needed for enterprise-scale data operations.


# Clear Data
Source: https://docs.dune.com/api-reference/tables/endpoint/uploads-clear

POST /v1/uploads/{namespace}/{table_name}/clear
Removes all data from the specified uploaded table while preserving the table structure and schema.

<Info>
  Minimum required API key scope: `Read/Write`
</Info>

The `Clear` endpoint removes all the data in the specified table, but does not delete the table.

<Tip>
  **Migrating from the old API?** See the [Migration Guide](./migration) for help updating your code.
</Tip>

<RequestExample>
  ```bash curl theme={null}
  curl --request POST \
    --url https://api.dune.com/api/v1/uploads/my_user/interest_rates/clear \
    --header 'X-DUNE-API-KEY: <x-dune-api-key>'
  ```

  ```python Python theme={null}
  import requests

  url = "https://api.dune.com/api/v1/uploads/my_user/interest_rates/clear"

  headers = {
      "X-DUNE-API-KEY": "<x-dune-api-key>"
  }

  response = requests.request("POST", url, headers=headers)
  ```
</RequestExample>


# Create Table
Source: https://docs.dune.com/api-reference/tables/endpoint/uploads-create

POST /v1/uploads
Creates an empty uploaded table that can be inserted into with the /insert endpoint.
Each successful table creation consumes 10 credits.

<Info>
  Minimum required API key scope: `Read/Write`
</Info>

The resulting table will be empty, and can be inserted into with the [/insert endpoint](./uploads-insert).

<Note>
  * If a table already exists with the same name, the request will fail.
  * Column names in the table can't start with a special character or a digit.
  * Each successful table creation **consumes credits based on the table size created**. Minimum charge is 1 credit.
  * To delete a table, you can go to `user settings (dune.com) -> data -> delete` or use the [/delete endpoint](./uploads-delete).
</Note>

<Tip>
  **Migrating from the old API?** See the [Migration Guide](./migration) for help updating your code.
</Tip>

## Schema

You need to define the schema of your data by providing `schema` array of columns in the request. Each column has three parameters:

**name**: the name of the field

**type**: the data type of the field
<Note> Dune supports [ISO 8601](https://www.iso.org/iso-8601-date-and-time-format.html) timestamp format </Note>

**nullable**: if the column is nullable (true/false, true by default)

<RequestExample>
  ```bash curl theme={null}
  curl --request POST \
    --url https://api.dune.com/api/v1/uploads \
    --header 'X-DUNE-API-KEY: <x-dune-api-key>' \
    --header 'Content-Type: application/json' \
    --data '{
    "namespace":"my_user",
    "table_name":"interest_rates",
    "description": "10 year daily interest rates, sourced from https://fred.stlouisfed.org/series/DGS10",
    "is_private": false,
    "schema": [{"name": "date", "type": "timestamp"}, {"name": "dgs10", "type": "double",  "nullable": true}]
  }'
  ```

  ```python Python SDK theme={null}
  from dune_client.client import DuneClient

  dune = DuneClient()

  table = dune.create_table(
          namespace="my_user",
          table_name="interest_rates",
          description="10 year daily interest rates, sourced from https://fred.stlouisfed.org/series/DGS10",
          schema= [
              {"name": "date", "type": "timestamp"},
              {"name": "dgs10", "type": "double", "nullable": True}
          ],
          is_private=False
  )
  ```

  ```typescript TS SDK theme={null}
  import { DuneClient, ColumnType } from "@duneanalytics/client-sdk";

  client = new DuneClient(process.env.DUNE_API_KEY!);
  const result = await client.table.create({
    namespace: "my_user",
    table_name: "interest_rates",
    schema: [
      {"name": "date", "type": ColumnType.Timestamp},
      {"name": "dgs10", "type": ColumnType.Double}
    ]
  });
  ```

  ```python Python theme={null}
  import requests

  url = "https://api.dune.com/api/v1/uploads"

  payload = {
      "namespace": "my_user",
      "table_name": "interest_rates",
      "description": "10 year daily interest rates, sourced from https://fred.stlouisfed.org/series/DGS10",
      "schema": [{"name": "date", "type": "timestamp"}, {"name": "dgs10", "type": "double", "nullable": True}],
      "is_private": False
  }

  headers = {
      "X-DUNE-API-KEY": "<x-dune-api-key>",
      "Content-Type": "application/json"
  }


  response = requests.request("POST", url, json=payload, headers=headers)
  ```

  ```javascript Javascript theme={null}
  const url = "https://api.dune.com/api/v1/uploads";

  const payload = {
      "namespace": "my_user",
      "table_name": "interest_rates",
      "description": "10 year daily interest rates, sourced from https://fred.stlouisfed.org/series/DGS10",
      "schema": [{"name": "date", "type": "timestamp"}, {"name": "dgs10", "type": "double", "nullable": true}],
      "is_private": false
  };

  const headers = {
      "X-DUNE-API-KEY": "<x-dune-api-key>",
      "Content-Type": "application/json"
  };

  fetch(url, {
      method: 'POST',
      headers: headers,
      body: JSON.stringify(payload)
  })
  .then(response => response.json())
  .then(response => console.log(response))
  .catch(err => console.error(err));
  ```
</RequestExample>


# Upload CSV
Source: https://docs.dune.com/api-reference/tables/endpoint/uploads-csv

POST /v1/uploads/csv
Upload a CSV file to create a table with automatic schema inference.
The size limit per upload is 500MB. Storage limits: 100MB (free), 1GB (analyst), 15GB (plus).

<Info>
  Minimum required API key scope: `Read/Write`
</Info>

<Warning>
  Consider using the [`/create`](./uploads-create) and [`/insert`](./uploads-insert) endpoints if you want more flexibility, performance, and the ability to append.
</Warning>

<Tip>
  You can also upload CSV through the [Dune UI](https://dune.com/) by pressing the "create" dropdown.

  **Migrating from the old API?** See the [Migration Guide](./migration) for help updating your code.
</Tip>

<Note>
  For working with uploads, keep in mind that:

  * File has to be \< 500 MB
  * Column names in the table can't start with a special character or digits.
  * Consumes credits based on the size of data uploaded.
    * Free, Analyst, Plus: 3 credits per GB written, minimum charge is 1 credit
  * If you upload to an existing table name, it will delete the old data and overwite it with your new data. Appends are only supported for the [`/create`](./uploads-create), [`/insert`](./uploads-insert) endpoints.
  * To delete an upload table, you must go to `user settings (dune.com) -> data -> delete`.

  If you have larger datasets you want to upload, please [contact us here](https://docs.google.com/forms/d/e/1FAIpQLSekx61WzIh-MII18zRj1G98aJeLM7U0VEBqaa6pVk_DQ7lq6Q/viewform)
</Note>

<RequestExample>
  ```bash curl theme={null}
  curl --request POST \
    --url https://api.dune.com/api/v1/uploads/csv \
    --header 'Content-Type: application/json' \
    --header 'X-DUNE-API-KEY: <x-dune-api-key>' \
    --data '{
    "data": "DATE,DGS10,\n2023-12-04,4.28,\n2023-12-05,4.18,\n2023-12-06,4.12,\n2023-12-07,4.14,\n2023-12-08,4.23,\n2023-12-11,4.23",
    "description": "10 year daily interest rates, sourced from https://fred.stlouisfed.org/series/DGS10",
    "table_name": "ten_year_us_interest_rates",
    "is_private": false
  }'
  ```

  ```python Python SDK theme={null}
  from dune_client.client import DuneClient

  dune = DuneClient()

  file_path = r'/data/example.csv'
  with open(file_path) as file:
      data = file.read()

  table = dune.upload_csv(
      data=str(data),
      description="10 year daily interest rates, sourced from https://fred.stlouisfed.org/series/DGS10",
      table_name="ten_year_us_interest_rates",
      is_private=False
  )
  ```

  ```typescript TS SDK theme={null}
  import * as fs from "fs/promises";
  import { DuneClient, ContentType } from "@duneanalytics/client-sdk";

  client = new DuneClient(process.env.DUNE_API_KEY!);
  const data = await fs.readFile("./sample_table_insert.csv");

  const result = await client.table.uploadCsv({
    table_name: "ten_year_us_interest_rates",
    description: "10 year daily interest rates, sourced from https://fred.stlouisfed.org/series/DGS10",
    data,
    is_private: false,
  });
  ```

  ```python Python theme={null}
  import requests

  url = "https://api.dune.com/api/v1/uploads/csv"

  payload = {
      "data": "DATE,DGS10,\n2023-12-04,4.28,\n2023-12-05,4.18,\n2023-12-06,4.12,\n2023-12-07,4.14,\n2023-12-08,4.23,\n2023-12-11,4.23",
      "description": "10 year daily interest rates, sourced from https://fred.stlouisfed.org/series/DGS10",
      "table_name": "ten_year_us_interest_rates",
      "is_private": False
  }
  headers = {
      "X-DUNE-API-KEY": "<x-dune-api-key>",
      "Content-Type": "application/json"
  }

  response = requests.request("POST", url, json=payload, headers=headers)

  print(response.text)
  ```

  ```javascript Javascript theme={null}
  const options = {
    method: 'POST',
    headers: {'X-DUNE-API-KEY': '<x-dune-api-key>', 'Content-Type': 'application/json'},
    body: '{"data":"DATE,DGS10,\n2023-12-04,4.28,\n2023-12-05,4.18,\n2023-12-06,4.12,\n2023-12-07,4.14,\n2023-12-08,4.23,\n2023-12-11,4.23","description":"10 year daily interest rates, sourced from https://fred.stlouisfed.org/series/DGS10","table_name":"ten_year_us_interest_rates","is_private":false}'
  };

  fetch('https://api.dune.com/api/v1/uploads/csv', options)
    .then(response => response.json())
    .then(response => console.log(response))
    .catch(err => console.error(err));
  ```

  ```go Go theme={null}
  package main

  import (
  	"fmt"
  	"strings"
  	"net/http"
  	"io/ioutil"
  )

  func main() {

  	url := "https://api.dune.com/api/v1/uploads/csv"

  	payload := strings.NewReader("{\n  \"data\": \"DATE,DGS10,\\n2023-12-04,4.28,\\n2023-12-05,4.18,\\n2023-12-06,4.12,\\n2023-12-07,4.14,\\n2023-12-08,4.23,\\n2023-12-11,4.23\",\n  \"description\": \"10 year daily interest rates, sourced from https://fred.stlouisfed.org/series/DGS10\",\n  \"table_name\": \"ten_year_us_interest_rates\",\n  \"is_private\": false\n}")

  	req, _ := http.NewRequest("POST", url, payload)

  	req.Header.Add("X-DUNE-API-KEY", "<x-dune-api-key>")
  	req.Header.Add("Content-Type", "application/json")

  	res, _ := http.DefaultClient.Do(req)

  	defer res.Body.Close()
  	body, _ := ioutil.ReadAll(res.Body)

  	fmt.Println(res)
  	fmt.Println(string(body))

  }
  ```

  ```php PHP theme={null}
  <?php

  $curl = curl_init();

  curl_setopt_array($curl, [
    CURLOPT_URL => "https://api.dune.com/api/v1/uploads/csv",
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_ENCODING => "",
    CURLOPT_MAXREDIRS => 10,
    CURLOPT_TIMEOUT => 30,
    CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
    CURLOPT_CUSTOMREQUEST => "POST",
    CURLOPT_POSTFIELDS => "{\n  \"data\": \"DATE,DGS10,\\n2023-12-04,4.28,\\n2023-12-05,4.18,\\n2023-12-06,4.12,\\n2023-12-07,4.14,\\n2023-12-08,4.23,\\n2023-12-11,4.23\",\n  \"description\": \"10 year daily interest rates, sourced from https://fred.stlouisfed.org/series/DGS10\",\n  \"table_name\": \"ten_year_us_interest_rates\",\n  \"is_private\": false\n}",
    CURLOPT_HTTPHEADER => [
      "Content-Type: application/json",
      "X-DUNE-API-KEY: <x-dune-api-key>"
    ],
  ]);

  $response = curl_exec($curl);
  $err = curl_error($curl);

  curl_close($curl);

  if ($err) {
    echo "cURL Error #:" . $err;
  } else {
    echo $response;
  }
  ```

  ```java Java theme={null}
  HttpResponse<String> response = Unirest.post("https://api.dune.com/api/v1/uploads/csv")
    .header("X-DUNE-API-KEY", "<x-dune-api-key>")
    .header("Content-Type", "application/json")
    .body("{\n  \"data\": \"DATE,DGS10,\\n2023-12-04,4.28,\\n2023-12-05,4.18,\\n2023-12-06,4.12,\\n2023-12-07,4.14,\\n2023-12-08,4.23,\\n2023-12-11,4.23\",\n  \"description\": \"10 year daily interest rates, sourced from https://fred.stlouisfed.org/series/DGS10\",\n  \"table_name\": \"ten_year_us_interest_rates\",\n  \"is_private\": false\n}")
    .asString();
  ```
</RequestExample>

### Upload via google sheet

To automate the upload of a Google Sheet's contents to Dune via API, use the following Google Apps Script:

```javascript theme={null}
function uploadToDune() {
  var apiKey = "YOUR_DUNE_API_KEY"; // Replace with your actual Dune API key, keep the quotes
  var tableName = "example_table"; // Update with your desired table name
  var description = "Example table description";

  var sheet = SpreadsheetApp.getActiveSpreadsheet().getActiveSheet();
  var range = sheet.getDataRange();
  var values = range.getValues();

  // Convert data to CSV format
  var csvData = "";
  for (var i = 0; i < values.length; i++) {
    csvData += values[i].join(",") + "\n";
  }

  var payload = {
    data: csvData.trim(),
    description: description,
    table_name: tableName,
    is_private: false
  };

  var options = {
    method: "post",
    contentType: "application/json",
    headers: {
      "X-DUNE-API-KEY": apiKey
    },
    payload: JSON.stringify(payload)
  };

  var response = UrlFetchApp.fetch("https://api.dune.com/api/v1/uploads/csv", options);
  Logger.log(response.getContentText());
}
```

Steps to Use:

1. Open your Google Sheet
2. Navigate to Extensions → Apps Script
3. Replace the script with the code above
4. Save and run uploadToDune
5. (Optional) For easier execution, you can assign this script to a button in your Google Sheet:
   * Click "Insert" in the Google Sheets menu
   * Select "Drawing"
   * Create a button shape and add text like "Upload to Dune"
   * Click "Save and Close"
   * Right-click the button and select "Assign script"
   * Enter "uploadToDune" as the function name
6. Clicking the button will now upload your active sheet's data to Dune!


# Delete Table
Source: https://docs.dune.com/api-reference/tables/endpoint/uploads-delete

DELETE /v1/uploads/{namespace}/{table_name}
Permanently deletes the specified uploaded table and all its data.

<Info>
  Minimum required API key scope: `Read/Write`
</Info>

<Note>
  * You must be an admin to delete the table.
  * You can also delete a table through `user settings (dune.com) -> data -> delete`.
  * Deleting a table does not incur credits.
</Note>

<Tip>
  **Migrating from the old API?** See the [Migration Guide](./migration) for help updating your code.
</Tip>

<RequestExample>
  ```bash curl theme={null}
  curl --request DELETE \
    --url https://api.dune.com/api/v1/uploads/my_user/interest_rates \
    --header 'X-DUNE-API-KEY: <x-dune-api-key>'
  ```

  ```python Python SDK theme={null}
  from dune_client.client import DuneClient

  dune = DuneClient()

  table = dune.delete_table(
          namespace="my_user",
          table_name="interest_rates"
  )
  ```

  ```typescript TS SDK theme={null}
  import { DuneClient } from "@duneanalytics/client-sdk";

  client = new DuneClient(process.env.DUNE_API_KEY!);
  const result = await client.table.delete({
    namespace: "my_user",
    table_name: "interest_rates",
  });
  ```

  ```python Python theme={null}
  import requests

  url = "https://api.dune.com/api/v1/uploads/my_user/interest_rates"

  headers = {
      "X-DUNE-API-KEY": "<x-dune-api-key>"
  }

  response = requests.request("DELETE", url, headers=headers)
  ```

  ```javascript Javascript theme={null}
  const url = "https://api.dune.com/api/v1/uploads/my_user/interest_rates";

  const headers = {
      "X-DUNE-API-KEY": "<x-dune-api-key>"
  };

  fetch(url, {
      method: 'DELETE',
      headers: headers
  })
  .then(response => response.json())
  .then(response => console.log(response))
  .catch(err => console.error(err));
  ```
</RequestExample>


# Insert Data
Source: https://docs.dune.com/api-reference/tables/endpoint/uploads-insert

POST /v1/uploads/{namespace}/{table_name}/insert
Inserts data into an existing table. Accepts CSV (text/csv) or
NDJSON (application/x-ndjson) content types.

<Info>
  Minimum required API key scope: `Read/Write`
</Info>

To be able to insert into a table, it must have been created with the [/create endpoint](./uploads-create).

<Note>
  * The data in the files must conform to the schema, and must use the same column names as the schema.
  * One successful `/insert` request consumes credits based on the size of data inserted.
    * Free, Analyst, Plus: 3 credits per GB written, minimum charge is 1 credit
  * The maximum request size is 1.2GB
</Note>

<Tip>
  **Migrating from the old API?** See the [Migration Guide](./migration) for help updating your code.
</Tip>

## Consistency

A request to this endpoint has two possible outcomes: Either all of the data in the request was inserted, or none of it was.
It's not possible for parts of the request data to be inserted, while the rest is not inserted.
In other words, please use and trust the status codes that the endpoint returns.
A status code of 200 means that the data in the request was successfully inserted.
If you get any other status code, you can safely retry your request after addressing the issue that the error message indicated.

## Concurrent requests

A limited number of concurrent insertion requests per table is supported. However, there will be a slight performance penalty as we serialize the writes behind the scenes to ensure data integrity. Larger number of concurrent requests per table may result in an increased number of failures. Therefore, we recommend managing your requests within a 5-10 threshold to maintain optimal performance.

## Supported filetypes

### CSV files (`Content-Type: text/csv`)

CSV files must use a comma as delimiter, and the column names in the header must match the column names of the table.

### JSON files (`Content-Type: application/x-ndjson`)

These are files where each line is a complete JSON object which creates one table row.
Each line must have keys that match the column names of the table.

## Data types

DuneSQL supports a variety of types which are not natively supported in many data exchange formats. Here we provide guidance on how to work with such types.

### Varbinary values

When uploading varbinary data using JSON or CSV formats, you need to convert the binary data into a textual representation. Reason being, JSON or CSV don't natively support binary values. There are many ways to transform binary data to a textual representation. We support **hexadecimal** and **base64** encodings.

#### base64

Base64 is a binary-to-text encoding scheme that transforms binary data into a sequence of characters. All characters are taken from a set of 64 characters.

Example: `{"varbinary_column":"SGVsbG8gd29ybGQK"}`

#### hexadecimal

In the hexadecimal representation input data should contain an even number of characters in the range `[0-9a-fA-F]` always prefixed with `0x`.

Example: `{"varbinary_column":"0x92b7d1031988c7af"}`

<RequestExample>
  ```bash curl theme={null}
  curl --request POST \
    --url https://api.dune.com/api/v1/uploads/my_user/interest_rates/insert \
    --header 'X-DUNE-API-KEY: <x-dune-api-key>' \
    --header 'Content-Type: text/csv' \
    --upload-file interest_rates.csv
  ```

  ```python Python SDK theme={null}
  from dune_client.client import DuneClient

  dune = DuneClient()

  with open("./interest_rates.csv", "rb") as data:
      response = dune.insert_table(
              namespace="my_user",
              table_name="interest_rates",
              data=data,
              content_type="text/csv"
          )
  ```

  ```typescript TS SDK theme={null}
  import * as fs from "fs/promises";
  import { DuneClient, ContentType } from "@duneanalytics/client-sdk";

  client = new DuneClient(process.env.DUNE_API_KEY!);
  const data = await fs.readFile("./sample_table_insert.csv");
  // Or JSON
  // const data: Buffer = await fs.readFile("./sample_table_insert.json");

  const result = await client.table.insert({
    namespace: "my_user",
    table_name: "interest_rates",
    data,
    content_type: ContentType.Csv, // or ContentType.Json
  });
  ```

  ```python Python theme={null}
  import requests

  url = "https://api.dune.com/api/v1/uploads/my_user/interest_rates/insert"

  headers = {
      "X-DUNE-API-KEY": "<x-dune-api-key>",
      "Content-Type": "text/csv"
  }

  with open("./interest_rates.csv", "rb") as data:
    response = requests.request("POST", url, data=data, headers=headers)
  ```

  ```javascript Javascript theme={null}
  const url = "https://api.dune.com/api/v1/uploads/my_user/interest_rates/insert";

  const headers = {
      "X-DUNE-API-KEY": "<x-dune-api-key>",
      "Content-Type": "text/csv"
  };

  fs.readFile('./interest_rates.csv', (err, data) => {
    if (err) {
        console.error(err);
        return;
    }

    fetch(url, {
          method: 'POST',
          headers: headers,
          body: data
      })
      .then(response => response.json())
      .then(response => console.log(response))
      .catch(err => console.error(err));
  });
  ```
</RequestExample>


# List Uploaded Tables
Source: https://docs.dune.com/api-reference/tables/endpoint/uploads-list

GET /v1/uploads
Get a paginated list of uploaded tables

<Info>
  Minimum required API key scope: `Read`
</Info>

## Description

Retrieves a paginated list of tables uploaded by the user or their team.

<Tip>
  **Migrating from the old API?** This endpoint replaces the deprecated `GET /v1/tables`. See the [Migration Guide](./migration) for details.

  For broader dataset discovery including Dune community datasets, use the `/v1/datasets` endpoint.
</Tip>

## Pagination

Use the `limit` and `offset` parameters to paginate through large result sets:

* To get the first 20 tables: `?limit=20&offset=0`
* To get the next 20 tables: `?limit=20&offset=20`
* Continue incrementing `offset` by `limit` to get subsequent pages

## Pricing

This is a metadata endpoint and does not consume credits.

## Related Endpoints

* [Create Table](/api-reference/tables/endpoint/uploads-create) - Create a new table
* [Upload Data](/api-reference/tables/endpoint/uploads-csv) - Upload data to a table
* [Delete Table](/api-reference/tables/endpoint/uploads-delete) - Delete a table

<RequestExample>
  ```bash cURL theme={null}
  curl -X GET "https://api.dune.com/api/v1/uploads?limit=10&offset=0" \
    -H "X-DUNE-API-KEY: YOUR_API_KEY"
  ```

  ```python Python theme={null}
  import requests

  url = "https://api.dune.com/api/v1/uploads"
  params = {
      "limit": 10,
      "offset": 0
  }
  headers = {"X-DUNE-API-KEY": "YOUR_API_KEY"}

  response = requests.get(url, params=params, headers=headers)
  print(response.json())
  ```

  ```javascript JavaScript theme={null}
  const url = 'https://api.dune.com/api/v1/uploads';
  const params = new URLSearchParams({
    limit: 10,
    offset: 0
  });

  const response = await fetch(`${url}?${params}`, {
    headers: {
      'X-DUNE-API-KEY': 'YOUR_API_KEY'
    }
  });

  const data = await response.json();
  console.log(data);
  ```
</RequestExample>

<ResponseExample>
  ```json Example Response theme={null}
  {
    "tables": [
      {
        "full_name": "dune.dune.ai_contract_tags",
        "is_private": true,
        "table_size_bytes": "1152622",
        "created_at": "2024-05-15T20:34:58.585Z",
        "updated_at": "2024-05-16T21:19:02.459Z",
        "purged_at": null,
        "owner": {
          "handle": "dune",
          "type": "team"
        },
        "columns": [
          {
            "name": "blockchain",
            "type": "string",
            "nullable": false,
            "metadata": {
              "description": "Blockchain associated with the record",
              "filtering_column": true
            }
          },
          {
            "name": "contract_address",
            "type": "string",
            "nullable": false,
            "metadata": {
              "description": "Address of the smart contract"
            }
          }
        ]
      }
    ]
  }
  ```
</ResponseExample>


# Get Usage
Source: https://docs.dune.com/api-reference/usage/endpoint/get-usage

POST /v1/usage
Retrieve customer usage data for billing periods

<Info>
  Minimum required API key scope: `Read`
</Info>

## Description

Retrieves customer usage data including credits, queries, dashboards, and storage. Returns the current billing period when no timeframe is specified.

## Pricing

This is a metadata endpoint and does not consume credits.

<RequestExample>
  ```bash cURL theme={null}
  curl -X POST "https://api.dune.com/api/v1/usage" \
    -H "Content-Type: application/json" \
    -H "X-DUNE-API-KEY: YOUR_API_KEY" \
    -d '{
      "start_date": "2025-01-01",
      "end_date": "2025-02-01"
    }'
  ```

  ```python Python theme={null}
  import requests

  url = "https://api.dune.com/api/v1/usage"
  headers = {
      "X-DUNE-API-KEY": "YOUR_API_KEY",
      "Content-Type": "application/json"
  }
  data = {
      "start_date": "2025-01-01",
      "end_date": "2025-02-01"
  }

  response = requests.post(url, json=data, headers=headers)
  print(response.json())
  ```

  ```javascript JavaScript theme={null}
  const url = 'https://api.dune.com/api/v1/usage';

  const response = await fetch(url, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'X-DUNE-API-KEY': 'YOUR_API_KEY'
    },
    body: JSON.stringify({
      start_date: '2025-01-01',
      end_date: '2025-02-01'
    })
  });

  const data = await response.json();
  console.log(data);
  ```
</RequestExample>

<ResponseExample>
  ```json Example Response theme={null}
  {
    "private_queries": 100,
    "private_dashboards": 100,
    "bytes_used": 1000,
    "bytes_allowed": 10101,
    "billingPeriods": [
      {
        "start_date": "2025-01-01",
        "end_date": "2025-02-01",
        "credits_used": 100.10,
        "credits_included": 100000
      }
    ]
  }
  ```
</ResponseExample>


# Overview
Source: https://docs.dune.com/api-reference/usage/overview



The account management endpoints allow you to monitor and track your API usage, credit consumption, and billing information.

## Usage Tracking

The usage endpoint provides detailed information about your account's resource consumption, including:

* Credits consumed
* Query executions
* Dashboard usage
* Storage utilization

This data helps you monitor your usage patterns and manage your billing effectively.

## Billing Periods

Usage data can be retrieved for specific time periods by providing start and end dates. When no timeframe is specified, the endpoint returns data for the current billing period.

<Note>
  The usage endpoint is a metadata endpoint and does not consume credits when called.
</Note>

## Endpoints

Below is an overview of the account management endpoint.

| Endpoint Title                    | Endpoint         | Description                                                                                                     |
| --------------------------------- | ---------------- | --------------------------------------------------------------------------------------------------------------- |
| [Get Usage](./endpoint/get-usage) | `POST /v1/usage` | Retrieves customer usage data including credits, queries, dashboards, and storage for specified billing periods |

## Use Cases

* **Monitor Credit Consumption:** Track how many credits your API calls are consuming
* **Billing Transparency:** Review usage data to understand your monthly charges
* **Usage Analytics:** Analyze patterns in your API usage over time
* **Budget Management:** Set up alerts based on usage thresholds


# Create Webhook
Source: https://docs.dune.com/api-reference/webhooks/webhook

How to receive data into webhooks from Dune queries

You can send Dune data to a webhook by going to any query you own, and pressing the "schedule" button to the left of "Run" in the editor. You'll see the popup below, where you can paste in a webhook url and receive data on a scheduled interval.

<Note>
  A good use case for this is sending data to a Slack webhook, which you can [learn to do here](https://api.slack.com/messaging/webhooks).
</Note>

<Frame>
  <img />
</Frame>

You can quickly test the output with a webhook generator [like this one](https://webhook.site/#!/).

Here is an example schema sent to the webhook from this [Jupiter swap fees query](https://dune.com/queries/3106864):

```
{
  "message": "Query Jupiter Fees was submitted for execution at Wed, 17 Jan 2024 04:18:49 GMT by your query schedule and it was successfully executed with a non-empty result.\nYou can check its latest result here: https://dune.com/queries/3106864?utm_source=webhook&utm_campaign=alerts",
  "query_result": {
    "execution_id": "01HMAT9AB8JRV1NQR1W6NMYQK7",
    "query_id": 3106864,
    "state": "QUERY_STATE_COMPLETED",
    "submitted_at": "2024-01-17T04:18:49Z",
    "expires_at": "2024-04-16T04:20:57Z",
    "execution_started_at": "2024-01-17T04:18:49Z",
    "execution_ended_at": "2024-01-17T04:20:57Z",
    "result": {
      "data_uri": "https://api.dune.com/api/v1/execution/01HMAT9AB8JRV1NQR1W6NMYQK7/results",
      "metadata": {
        "column_names": [
          "week",
          "fee_usd"
        ],
        "result_set_bytes": 1164,
        "total_row_count": 25,
        "datapoint_count": 50,
        "pending_time_millis": 40,
        "execution_time_millis": 127845
      }
    }
  },
  "visualizations": [
    {
      "title": "Chart",
      "image_url": "https://prod-dune-media.s3.eu-west-1.amazonaws.com/screenshots/3106864/01HMAT9AB8JRV1NQR1W6NMYQK7/5222108.png"
    }
  ]
}
```

<Note>
  You'll need to query the `data_uri` with your api key to get the results data. This is the same as passing the `execution_id` into [get execution result](/api-reference/executions/endpoint/get-execution-result).
</Note>

<Warning>
  In the case the query errors out on its scheduled run, you won't receive anything to the webhook.
</Warning>


# Dune Catalyst
Source: https://docs.dune.com/catalyst/overview

Empower Your Blockchain with the Leading Data Platform.

## Why Your Blockchain Should Be on Dune

Join the **largest crypto data community** and unlock unmatched benefits for your project. Dune is the **source of truth** for blockchain data, providing essential tools and community engagement.

* **Community**: Connect with over **550k active analysts**, fostering collaboration and driving insights.
* **Exposure**: Gain visibility with over **1M unique visitors**, boosting your project's reach and credibility.
* **Trusted Data**: Access data from **[100+ chains](/data-catalog/overview)**, **1.5M datasets**, and **750K queries**—transparent, accurate, and composable.
* **Growth**: Scale your ecosystem, attracting **top protocols, developers, and community members**.
* **Industry Leadership**: Leverage Dune’s leading infrastructure and build **trust and transparency** within the crypto world.

## Integration Options

Dune offers flexible integration routes for both EVM and non-EVM chains, allowing you to easily integrate your blockchain data into the platform. Here are the three primary routes for integration:

<CardGroup>
  <Card title="EVM Chains" icon="cube" href="#1-evm-chains">
    * **White-Glove Service** for EVM-data-compatible chains
    * **Integrate** from a node provider
    * Gain access to fully **decoded (protocol) and curated datasets**
  </Card>

  <Card title="Non-EVM Chains (RPC Route)" icon="network-wired" href="#2-non-evm-chains-rpc-route">
    * **Index from nodes**
    * Dune **builds custom tables** for chain analytics
  </Card>

  <Card title="Non-EVM Chains (Database Route)" icon="server" href="#3-non-evm-chains-database-route">
    * **Index and maintain transformed data** from AWS or GCS
    * **Syncs hourly** from AWS S3 or GCS to Dune
  </Card>
</CardGroup>

### 1. EVM Chains

**What it is:**\
For EVM-based chains, Dune provides a fully-managed, white-glove service approach to integrate blockchain data. This involves ingesting raw data, decoding smart contracts, and curating datasets for deeper analytics.

**Technical Requirements:**

* **Node Provider**:\
  Your chain will need a reliable node provider, such as QuickNode, Alchemy, Infura, Chainstack, or Tatum.

* **RPC Node Calls**:\
  The RPC node must support the following methods so Dune can transform raw data into Dune’s standard EVM schema for **transactions, logs, traces, and blocks**:
  * `eth_getBlockByNumber` (for blocks/transactions)
  * `eth_getBlockReceipts` (for logs)
  * `debug_traceBlockByNumber` (for traces)
  * `eth_getTransactionReceipt` (alternative for logs)
  * `trace_block` (alternative for traces)

* **Standardized ABIs**:\
  Your chain should support smart contract definitions with standardized ABIs. This typically includes an API endpoint like `[contract_getsourcecode](https://docs.etherscan.io/api-endpoints/contracts#get-contract-source-code-for-verified-contract-source-codes)`, allowing Dune to pull ABIs for contract addresses. The endpoint should provide:
  * Is it a verified contract?
  * ABI: JSON format (potentially stringified)
  * ContractName: string
  * Proxy: boolean
  * Implementation: address of proxy contract (if proxy)

**Example Chains**\
To get a feel for how data on Dune looks for this integration route, check out examples like [Ethereum](/data-catalog/evm/ethereum/overview), [Base](/data-catalog/evm/base/overview), or [Polygon](/data-catalog/evm/polygon/overview).

***

### 2. Non-EVM Chains: RPC Route

**What it is:**\
For non-EVM chains supporting RPC calls, Dune provides an integration method via node indexing. This setup allows data to flow directly from the blockchain nodes to Dune, transforming it into raw datasets that can be used in analysis and dashboards.

**Technical Requirements:**

* **Node Indexing**: The chain should have a node provider capable of making relevant RPC calls (e.g., `getBlock`, `getTransaction`, or chain-specific alternatives).

**Example Chains**\
To get a feel for how data on Dune looks for this integration route, check out [Solana](/data-catalog/solana/overview), [Bitcoin](/data-catalog/bitcoin/overview), or [Aptos](/data-catalog/aptos/overview).

***

### 3. Non-EVM Chains: Database Route

**What it is:**\
For chains where an RPC approach isn’t applicable, Dune can integrate data through a database route. This method involves indexing chain data into Dune from datasets that are already transformed and stored in cloud solutions such as AWS S3 or Google Cloud Storage (GCS).

**Technical Requirements:**

* **Data Format**: AVRO (preferred) or Parquet format.
* **Folder Structure**: Data should follow the structure `bucket-name/chain/table-name/yyyy-mm-dd/hh-mm-ss-XXX...XXX.avro`.
* **S3 Bucket**: Must have "requester pays" disabled and be located in the EU.
* **Table Management**: Provide a list of tables, their size, and growth rate (daily or monthly).
* **Data Updates**: Tables are indexed and refreshed hourly (append-only, no row-level updates or deletes).
* **Backfills**: Full table replacements can be requested on a case-by-case basis.
* **Storage Costs**: All Dune storage costs are fully covered.

**Example Chains**\
To explore examples of this integration, check out the data for [Polkadot](/data-catalog/substrate/overview) or [Near](/data-catalog/near/overview).

***

### Data Latency

Data latency is important to consider when integrating your chain with Dune. The platform ensures fast data availability, but latency varies based on the integration route:

* **EVM Chains & Non-EVM RPC Chains**: These chains aim to stay synchronized with the latest block, minimizing delays to a few seconds or minutes. Dune’s infrastructure ensures minimal latency, allowing you to access real-time data quickly.

* **Non-EVM Database Route**: Data flows from your cloud database into Dune on an hourly basis. This introduces a bit more delay compared to RPC-based integrations, but the data remains highly reliable.

For more detailed information on data freshness and latency, refer to [Dune’s data freshness documentation](/data-catalog/data-freshness).

## Ready to Integrate?

<CardGroup>
  <Card title="Have Questions? Ready to Get Started?" icon="phone" href="https://dune.com/enterprise">
    Contact our partnership team today to get started with Dune Catalyst integration or to learn more about how we can help power your blockchain data journey.
  </Card>
</CardGroup>


# aptos.blocks
Source: https://docs.dune.com/data-catalog/aptos/blocks

Aptos block metadata — block height, timestamp, epoch, and round information.

## Table description

The `aptos.blocks` table represents the blocks in the Aptos blockchain. A block is a collection of transactions, and is identified by a unique block identifier. Each block contains a timestamp and a reference to the previous block hash, forming a chain of blocks. The block structure is crucial for the blockchain's integrity and security, ensuring a verifiable and tamper-evident ledger.

## Table Schema

| Column                        | Type              | Description                                                                  |
| ----------------------------- | ----------------- | ---------------------------------------------------------------------------- |
| `block_height`                | `BIGINT`          | Sequential number identifying the block's position in the chain              |
| `time`                        | `TIMESTAMP`       | Timestamp when the block was proposed and committed                          |
| `block_date`                  | `DATE`            | Date of the block, truncated from the timestamp for daily aggregations       |
| `block_hash`                  | `VARBINARY`       | Unique cryptographic hash identifying this block                             |
| `first_version`               | `UINT256`         | The first transaction version included in this block                         |
| `last_version`                | `UINT256`         | The last transaction version included in this block                          |
| `proposer`                    | `VARBINARY`       | Address of the validator that proposed this block                            |
| `round`                       | `UINT256`         | Consensus round number in which this block was produced                      |
| `epoch`                       | `UINT256`         | Epoch number during which this block was created                             |
| `metadata_id`                 | `VARBINARY`       | Unique identifier for the block metadata event                               |
| `failed_proposer_indices`     | `ARRAY(INTEGER)`  | Indices of validators that failed to propose before this block was finalized |
| `previous_block_votes_bitvec` | `ARRAY(SMALLINT)` | Bit vector indicating which validators voted on the previous block           |
| `transactions_count`          | `INTEGER`         | Total number of transactions included in this block                          |

## Table Sample

<TableSample />


# aptos.events
Source: https://docs.dune.com/data-catalog/aptos/events

Aptos on-chain events — emitted by Move modules during transaction execution.

## Table description

The `aptos.events` table captures the events that are emitted by smart contracts on the Aptos blockchain. Events are used to log significant actions and changes in smart contracts, such as token transfers or updates to contract states. Each event is linked to the transaction that triggered it, providing a detailed audit trail of contract interactions.

## Table Schema

| Column                              | Type              | Description                                                                         |
| ----------------------------------- | ----------------- | ----------------------------------------------------------------------------------- |
| `block_height`                      | `BIGINT`          | Sequential number identifying the block's position in the chain                     |
| `block_date`                        | `DATE`            | Date of the block for daily aggregations                                            |
| `block_time`                        | `TIMESTAMP`       | Timestamp when the block was committed                                              |
| `block_hash`                        | `VARBINARY`       | Unique cryptographic hash identifying the block                                     |
| `block_first_version`               | `UINT256`         | First transaction version included in the block                                     |
| `block_last_version`                | `UINT256`         | Last transaction version included in the block                                      |
| `block_proposer`                    | `VARBINARY`       | Address of the validator that proposed the block                                    |
| `block_round`                       | `UINT256`         | Consensus round number for the block                                                |
| `block_epoch`                       | `UINT256`         | Epoch number during which the block was created                                     |
| `block_metadata_id`                 | `VARBINARY`       | Unique identifier for the block metadata event                                      |
| `block_failed_proposer_indices`     | `ARRAY(INTEGER)`  | Indices of validators that failed to propose before this block                      |
| `block_previous_block_votes_bitvec` | `ARRAY(SMALLINT)` | Bit vector of validator votes on the previous block                                 |
| `tx_index`                          | `INTEGER`         | Position of the transaction within the block                                        |
| `tx_type`                           | `VARCHAR`         | Type of the transaction (e.g. user\_transaction, block\_metadata)                   |
| `tx_hash`                           | `VARBINARY`       | Unique hash identifying the transaction that emitted this event                     |
| `tx_version`                        | `UINT256`         | Global sequential version number of the transaction                                 |
| `tx_gas_used`                       | `UINT256`         | Amount of gas consumed by the transaction                                           |
| `tx_vm_status`                      | `VARCHAR`         | Detailed status message returned by the Move VM after execution                     |
| `tx_success`                        | `BOOLEAN`         | Whether the transaction executed successfully                                       |
| `tx_state_change_hash`              | `VARBINARY`       | Hash of all state changes produced by the transaction                               |
| `tx_event_root_hash`                | `VARBINARY`       | Merkle root hash of all events emitted by the transaction                           |
| `tx_state_checkpoint_hash`          | `VARBINARY`       | Hash of the state checkpoint after this transaction                                 |
| `tx_accumulator_root_hash`          | `VARBINARY`       | Root hash of the transaction accumulator after this transaction                     |
| `event_index`                       | `INTEGER`         | Position of this event within the transaction's event list                          |
| `event_type`                        | `VARCHAR`         | Fully qualified Move type identifier of the event (e.g. `0x1::coin::WithdrawEvent`) |
| `guid_account_address`              | `VARBINARY`       | Account address associated with the event's globally unique identifier              |
| `guid_creation_number`              | `UINT256`         | Creation number of the event handle, unique per account                             |
| `event_sequence_number`             | `UINT256`         | Sequence number of this event within its event handle                               |
| `data`                              | `VARCHAR`         | JSON-encoded payload of the event containing event-specific fields                  |

## Table Sample

<TableSample />


# aptos.move_modules
Source: https://docs.dune.com/data-catalog/aptos/move_modules

Aptos Move module deployments — published module bytecode, package metadata, and addresses.

## Table description

The `aptos.move_modules` table contains data on Move modules deployed on the Aptos blockchain. Move modules contain the bytecode for smart contracts and define the functionality and types used by Move resources. This table provides insight into the smart contract code running on the network, including the module's author, name, and bytecode.

## Table Schema

| Column                              | Type                                                                                                                                                                                             | Description                                                       |
| ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------- |
| `block_height`                      | `BIGINT`                                                                                                                                                                                         | Sequential number identifying the block's position in the chain   |
| `block_date`                        | `DATE`                                                                                                                                                                                           | Date of the block for daily aggregations                          |
| `block_time`                        | `TIMESTAMP`                                                                                                                                                                                      | Timestamp when the block was committed                            |
| `block_hash`                        | `VARBINARY`                                                                                                                                                                                      | Unique cryptographic hash identifying the block                   |
| `block_first_version`               | `UINT256`                                                                                                                                                                                        | First transaction version included in the block                   |
| `block_last_version`                | `UINT256`                                                                                                                                                                                        | Last transaction version included in the block                    |
| `block_proposer`                    | `VARBINARY`                                                                                                                                                                                      | Address of the validator that proposed the block                  |
| `block_round`                       | `UINT256`                                                                                                                                                                                        | Consensus round number for the block                              |
| `block_epoch`                       | `UINT256`                                                                                                                                                                                        | Epoch number during which the block was created                   |
| `block_metadata_id`                 | `VARBINARY`                                                                                                                                                                                      | Unique identifier for the block metadata event                    |
| `block_failed_proposer_indices`     | `ARRAY(INTEGER)`                                                                                                                                                                                 | Indices of validators that failed to propose before this block    |
| `block_previous_block_votes_bitvec` | `ARRAY(SMALLINT)`                                                                                                                                                                                | Bit vector of validator votes on the previous block               |
| `tx_index`                          | `INTEGER`                                                                                                                                                                                        | Position of the transaction within the block                      |
| `tx_type`                           | `VARCHAR`                                                                                                                                                                                        | Type of the transaction (e.g. user\_transaction, block\_metadata) |
| `tx_hash`                           | `VARBINARY`                                                                                                                                                                                      | Unique hash identifying the transaction                           |
| `tx_version`                        | `UINT256`                                                                                                                                                                                        | Global sequential version number of the transaction               |
| `tx_gas_used`                       | `UINT256`                                                                                                                                                                                        | Amount of gas consumed by the transaction                         |
| `tx_vm_status`                      | `VARCHAR`                                                                                                                                                                                        | Detailed status message returned by the Move VM                   |
| `tx_success`                        | `BOOLEAN`                                                                                                                                                                                        | Whether the transaction executed successfully                     |
| `tx_state_change_hash`              | `VARBINARY`                                                                                                                                                                                      | Hash of all state changes produced by the transaction             |
| `tx_event_root_hash`                | `VARBINARY`                                                                                                                                                                                      | Merkle root hash of all events emitted by the transaction         |
| `tx_state_checkpoint_hash`          | `VARBINARY`                                                                                                                                                                                      | Hash of the state checkpoint after this transaction               |
| `tx_accumulator_root_hash`          | `VARBINARY`                                                                                                                                                                                      | Root hash of the transaction accumulator after this transaction   |
| `write_set_change_index`            | `INTEGER`                                                                                                                                                                                        | Index of this state change within the transaction's write set     |
| `write_set_change_type`             | `VARCHAR`                                                                                                                                                                                        | Type of write set change (e.g. write\_module, delete\_module)     |
| `move_state_key_hash`               | `VARBINARY`                                                                                                                                                                                      | Hash of the state key affected by this change                     |
| `move_is_deletion`                  | `BOOLEAN`                                                                                                                                                                                        | Whether this change represents a deletion of the module           |
| `move_address`                      | `VARBINARY`                                                                                                                                                                                      | Address where the module is deployed                              |
| `move_module_address`               | `VARBINARY`                                                                                                                                                                                      | Address of the module's owner account                             |
| `move_module_bytecode`              | `VARCHAR`                                                                                                                                                                                        | Hex-encoded compiled Move bytecode of the module                  |
| `move_module_module_name`           | `VARCHAR`                                                                                                                                                                                        | Name of the Move module                                           |
| `move_module_friends`               | `ARRAY(ROW(NAME VARCHAR, ADDRESS VARBINARY))`                                                                                                                                                    | List of friend modules that have privileged access                |
| `move_module_exposed_functions`     | `ARRAY(ROW(NAME VARCHAR, VISIBILITY VARCHAR, IS_ENTRY BOOLEAN, IS_VIEW BOOLEAN, GENERIC_TYPE_PARAMS ARRAY(ROW(CONSTRAINTS ARRAY(VARCHAR))), PARAMS ARRAY(VARCHAR), RETURN_TYPE ARRAY(VARCHAR)))` | Public and entry functions exposed by the module                  |
| `move_module_structs`               | `ARRAY(ROW(NAME VARCHAR, IS_NATIVE BOOLEAN, ABILITIES ARRAY(VARCHAR), GENERIC_TYPE_PARAMS ARRAY(VARCHAR), FIELDS ARRAY(ROW(NAME VARCHAR, TYPE VARCHAR))))`                                       | Struct types defined in the module                                |

## Table Sample

<TableSample />


# aptos.move_resources
Source: https://docs.dune.com/data-catalog/aptos/move_resources

Aptos Move resource snapshots — on-chain state stored in Move structs by account.

## Table description

The `aptos.move_resources` table stores information about the Move resources on the Aptos blockchain. Move resources are persistent data structures that are owned by user accounts and can represent various on-chain assets or states. This table includes details on the resource type, the account that owns it, and the resource's data.

## Table Schema

| Column                              | Type              | Description                                                       |
| ----------------------------------- | ----------------- | ----------------------------------------------------------------- |
| `block_height`                      | `BIGINT`          | Sequential number identifying the block's position in the chain   |
| `block_date`                        | `DATE`            | Date of the block for daily aggregations                          |
| `block_time`                        | `TIMESTAMP`       | Timestamp when the block was committed                            |
| `block_hash`                        | `VARBINARY`       | Unique cryptographic hash identifying the block                   |
| `block_first_version`               | `UINT256`         | First transaction version included in the block                   |
| `block_last_version`                | `UINT256`         | Last transaction version included in the block                    |
| `block_proposer`                    | `VARBINARY`       | Address of the validator that proposed the block                  |
| `block_round`                       | `UINT256`         | Consensus round number for the block                              |
| `block_epoch`                       | `UINT256`         | Epoch number during which the block was created                   |
| `block_metadata_id`                 | `VARBINARY`       | Unique identifier for the block metadata event                    |
| `block_failed_proposer_indices`     | `ARRAY(INTEGER)`  | Indices of validators that failed to propose before this block    |
| `block_previous_block_votes_bitvec` | `ARRAY(SMALLINT)` | Bit vector of validator votes on the previous block               |
| `tx_index`                          | `INTEGER`         | Position of the transaction within the block                      |
| `tx_type`                           | `VARCHAR`         | Type of the transaction (e.g. user\_transaction, block\_metadata) |
| `tx_hash`                           | `VARBINARY`       | Unique hash identifying the transaction                           |
| `tx_version`                        | `UINT256`         | Global sequential version number of the transaction               |
| `tx_gas_used`                       | `UINT256`         | Amount of gas consumed by the transaction                         |
| `tx_vm_status`                      | `VARCHAR`         | Detailed status message returned by the Move VM                   |
| `tx_success`                        | `BOOLEAN`         | Whether the transaction executed successfully                     |
| `tx_state_change_hash`              | `VARBINARY`       | Hash of all state changes produced by the transaction             |
| `tx_event_root_hash`                | `VARBINARY`       | Merkle root hash of all events emitted by the transaction         |
| `tx_state_checkpoint_hash`          | `VARBINARY`       | Hash of the state checkpoint after this transaction               |
| `tx_accumulator_root_hash`          | `VARBINARY`       | Root hash of the transaction accumulator after this transaction   |
| `write_set_change_index`            | `INTEGER`         | Index of this state change within the transaction's write set     |
| `write_set_change_type`             | `VARCHAR`         | Type of write set change (e.g. write\_resource, delete\_resource) |
| `move_state_key_hash`               | `VARBINARY`       | Hash of the state key affected by this change                     |
| `move_is_deletion`                  | `BOOLEAN`         | Whether this change represents a deletion of the resource         |
| `move_data`                         | `VARCHAR`         | JSON-encoded data payload of the Move resource                    |
| `move_address`                      | `VARBINARY`       | Address of the account that owns this resource                    |
| `move_module_address`               | `VARBINARY`       | Address of the module that defines this resource type             |
| `move_resource_module`              | `VARCHAR`         | Name of the module that defines this resource type                |
| `move_resource_name`                | `VARCHAR`         | Name of the resource struct type                                  |
| `move_resource_generic_type_params` | `ARRAY(VARCHAR)`  | Generic type parameters applied to this resource instance         |

## Table Sample

<TableSample />


# aptos.move_table_items
Source: https://docs.dune.com/data-catalog/aptos/move_table_items

Aptos Move table operations — key-value store changes during transaction execution.

## Table description

The `aptos.move_table_items` table tracks the items stored in Move's table data structures on the Aptos blockchain. The Move table is a high-performance, typed data structure used for storing and querying on-chain data. This table details the key-value pairs stored, facilitating efficient data access and manipulation within smart contracts.

## Table Schema

| Column                              | Type              | Description                                                             |
| ----------------------------------- | ----------------- | ----------------------------------------------------------------------- |
| `block_height`                      | `BIGINT`          | Sequential number identifying the block's position in the chain         |
| `block_date`                        | `DATE`            | Date of the block for daily aggregations                                |
| `block_time`                        | `TIMESTAMP`       | Timestamp when the block was committed                                  |
| `block_hash`                        | `VARBINARY`       | Unique cryptographic hash identifying the block                         |
| `block_first_version`               | `UINT256`         | First transaction version included in the block                         |
| `block_last_version`                | `UINT256`         | Last transaction version included in the block                          |
| `block_proposer`                    | `VARBINARY`       | Address of the validator that proposed the block                        |
| `block_round`                       | `UINT256`         | Consensus round number for the block                                    |
| `block_epoch`                       | `UINT256`         | Epoch number during which the block was created                         |
| `block_metadata_id`                 | `VARBINARY`       | Unique identifier for the block metadata event                          |
| `block_failed_proposer_indices`     | `ARRAY(INTEGER)`  | Indices of validators that failed to propose before this block          |
| `block_previous_block_votes_bitvec` | `ARRAY(SMALLINT)` | Bit vector of validator votes on the previous block                     |
| `tx_index`                          | `INTEGER`         | Position of the transaction within the block                            |
| `tx_type`                           | `VARCHAR`         | Type of the transaction (e.g. user\_transaction, block\_metadata)       |
| `tx_hash`                           | `VARBINARY`       | Unique hash identifying the transaction                                 |
| `tx_version`                        | `UINT256`         | Global sequential version number of the transaction                     |
| `tx_gas_used`                       | `UINT256`         | Amount of gas consumed by the transaction                               |
| `tx_vm_status`                      | `VARCHAR`         | Detailed status message returned by the Move VM                         |
| `tx_success`                        | `BOOLEAN`         | Whether the transaction executed successfully                           |
| `tx_state_change_hash`              | `VARBINARY`       | Hash of all state changes produced by the transaction                   |
| `tx_event_root_hash`                | `VARBINARY`       | Merkle root hash of all events emitted by the transaction               |
| `tx_state_checkpoint_hash`          | `VARBINARY`       | Hash of the state checkpoint after this transaction                     |
| `tx_accumulator_root_hash`          | `VARBINARY`       | Root hash of the transaction accumulator after this transaction         |
| `write_set_change_index`            | `INTEGER`         | Index of this state change within the transaction's write set           |
| `write_set_change_type`             | `VARCHAR`         | Type of write set change (e.g. write\_table\_item, delete\_table\_item) |
| `move_state_key_hash`               | `VARBINARY`       | Hash of the state key affected by this change                           |
| `move_is_deletion`                  | `BOOLEAN`         | Whether this change represents a deletion of the table item             |
| `move_table_item_handle`            | `VARBINARY`       | Handle identifying the on-chain Move table this item belongs to         |
| `move_table_item_key`               | `VARBINARY`       | Serialized key of the item within the Move table                        |
| `move_table_item_value`             | `VARBINARY`       | Serialized value of the item within the Move table                      |
| `move_data`                         | `VARCHAR`         | JSON-encoded representation of the table item data                      |

## Table Sample

<TableSample />


# Aptos data
Source: https://docs.dune.com/data-catalog/aptos/overview

Aptos is a next-generation blockchain designed for scalability, security, and reliability.

Aptos utilizes the Move programming language, focusing on flexibility, safety, and efficiency in smart contract execution. It employs a ledger model that is built to support highly scalable and reliable decentralized applications and financial infrastructure. Aptos is distinguished by its state-of-the-art consensus protocol, aiming to achieve high transaction throughput without compromising security or decentralization.

You can learn more about Aptos by visiting the [official documentation](https://aptos.dev/).

## Data Available

<CardGroup>
  <Card title="Blocks" icon="cube" href="/data-catalog/aptos/blocks">
    Represents the collection of transactions in a single block within the Aptos
    blockchain.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="/data-catalog/aptos/transactions">
    Includes all user and system transactions processed by the Aptos network.
  </Card>

  <Card title="User Transactions" icon="user" href="/data-catalog/aptos/user_transactions">
    Specifically tracks transactions initiated by users, including smart
    contract interactions.
  </Card>

  <Card title="Events" icon="bolt" href="/data-catalog/aptos/events">
    Captures events emitted by smart contracts, logging significant actions and
    changes.
  </Card>

  <Card title="Move Resources" icon="database" href="/data-catalog/aptos/move_resources">
    Details Move resources, representing structured data owned by accounts on
    the Aptos blockchain.
  </Card>

  <Card title="Move Modules" icon="puzzle-piece" href="/data-catalog/aptos/move_modules">
    Contains metadata and code for Move modules, defining the functionality of
    smart contracts.
  </Card>

  <Card title="Move Table Items" icon="table" href="/data-catalog/aptos/move_table_items">
    Tracks items stored in Move's table data structures, used for efficient data
    access within smart contracts.
  </Card>

  <Card title="Signatures" icon="signature" href="/data-catalog/aptos/signatures">
    Signatures are associated with transactions, which are essential for
    security and authentication.
  </Card>
</CardGroup>


# aptos.signatures
Source: https://docs.dune.com/data-catalog/aptos/signatures

Aptos transaction signatures — authentication data including public keys and signature schemes.

## Table description

The `aptos.signatures` table documents the signatures associated with transactions on the Aptos blockchain. Signatures are critical for securing transactions, proving the identity of the sender, and ensuring data integrity. This table includes the signature type, data, and the transaction it authenticates, offering insights into the security mechanisms at play.

## Table Schema

| Column                              | Type              | Description                                                                  |
| ----------------------------------- | ----------------- | ---------------------------------------------------------------------------- |
| `block_height`                      | `BIGINT`          | Sequential number identifying the block's position in the chain              |
| `block_date`                        | `DATE`            | Date of the block for daily aggregations                                     |
| `block_time`                        | `TIMESTAMP`       | Timestamp when the block was committed                                       |
| `block_hash`                        | `VARBINARY`       | Unique cryptographic hash identifying the block                              |
| `block_first_version`               | `UINT256`         | First transaction version included in the block                              |
| `block_last_version`                | `UINT256`         | Last transaction version included in the block                               |
| `block_proposer`                    | `VARBINARY`       | Address of the validator that proposed the block                             |
| `block_round`                       | `UINT256`         | Consensus round number for the block                                         |
| `block_epoch`                       | `UINT256`         | Epoch number during which the block was created                              |
| `block_metadata_id`                 | `VARBINARY`       | Unique identifier for the block metadata event                               |
| `block_failed_proposer_indices`     | `ARRAY(INTEGER)`  | Indices of validators that failed to propose before this block               |
| `block_previous_block_votes_bitvec` | `ARRAY(SMALLINT)` | Bit vector of validator votes on the previous block                          |
| `tx_index`                          | `INTEGER`         | Position of the transaction within the block                                 |
| `tx_type`                           | `VARCHAR`         | Type of the transaction (e.g. user\_transaction, block\_metadata)            |
| `tx_hash`                           | `VARBINARY`       | Unique hash identifying the transaction                                      |
| `tx_version`                        | `UINT256`         | Global sequential version number of the transaction                          |
| `tx_gas_used`                       | `UINT256`         | Amount of gas consumed by the transaction                                    |
| `tx_vm_status`                      | `VARCHAR`         | Detailed status message returned by the Move VM                              |
| `tx_success`                        | `BOOLEAN`         | Whether the transaction executed successfully                                |
| `tx_state_change_hash`              | `VARBINARY`       | Hash of all state changes produced by the transaction                        |
| `tx_event_root_hash`                | `VARBINARY`       | Merkle root hash of all events emitted by the transaction                    |
| `tx_state_checkpoint_hash`          | `VARBINARY`       | Hash of the state checkpoint after this transaction                          |
| `tx_accumulator_root_hash`          | `VARBINARY`       | Root hash of the transaction accumulator after this transaction              |
| `tx_timestamp`                      | `UINT256`         | Unix timestamp of the transaction in microseconds                            |
| `tx_sender`                         | `VARBINARY`       | Address of the account that submitted the transaction                        |
| `tx_max_gas_amount`                 | `UINT256`         | Maximum gas units the sender is willing to pay                               |
| `tx_gas_unit_price`                 | `UINT256`         | Price per gas unit in octas (1 APT = 10^8 octas)                             |
| `tx_sequence_number`                | `UINT256`         | Sender's account sequence number at the time of this transaction             |
| `tx_expiration_timestamp_secs`      | `UINT256`         | Unix timestamp (seconds) after which the transaction expires                 |
| `type`                              | `VARCHAR`         | Top-level signature scheme type (e.g. ed25519, multi\_ed25519, multi\_agent) |
| `signer_type`                       | `VARCHAR`         | Role of the signer (e.g. sender, secondary\_signer, fee\_payer)              |
| `signer_signature_type`             | `VARCHAR`         | Cryptographic algorithm used by this signer (e.g. ed25519, secp256k1\_ecdsa) |
| `is_single_sender`                  | `BOOLEAN`         | Whether the transaction has a single sender (as opposed to multi-agent)      |
| `signer_address`                    | `VARBINARY`       | Address of this particular signer                                            |
| `secondary_signer_index`            | `INTEGER`         | Index of this signer among secondary signers (-1 for primary sender)         |
| `public_key`                        | `VARBINARY`       | Public key used to create the signature                                      |
| `signature`                         | `VARBINARY`       | Cryptographic signature bytes                                                |
| `bitmap`                            | `VARBINARY`       | Bitmap indicating which keys signed in a multi-key scheme                    |
| `bitmap_public_key_index`           | `INTEGER`         | Index of this public key within the bitmap                                   |
| `threshold`                         | `BIGINT`          | Minimum number of signatures required for multi-key authentication           |

## Table Sample

<TableSample />


# aptos.transactions
Source: https://docs.dune.com/data-catalog/aptos/transactions

Aptos transactions — payload type, gas used, success status, and version number.

## Table description

The `aptos.transactions` table contains information about all transactions on the Aptos blockchain, including both user-initiated and system transactions. Transactions are the actions that modify the state of the blockchain, such as transfers of tokens or the execution of smart contracts. Each transaction is uniquely identified and linked to the block in which it was included.

## Table Schema

| Column                              | Type              | Description                                                                          |
| ----------------------------------- | ----------------- | ------------------------------------------------------------------------------------ |
| `block_height`                      | `BIGINT`          | Sequential number identifying the block's position in the chain                      |
| `block_date`                        | `DATE`            | Date of the block for daily aggregations                                             |
| `block_time`                        | `TIMESTAMP`       | Timestamp when the block was committed                                               |
| `block_hash`                        | `VARBINARY`       | Unique cryptographic hash identifying the block                                      |
| `block_first_version`               | `UINT256`         | First transaction version included in the block                                      |
| `block_last_version`                | `UINT256`         | Last transaction version included in the block                                       |
| `block_proposer`                    | `VARBINARY`       | Address of the validator that proposed the block                                     |
| `block_round`                       | `UINT256`         | Consensus round number for the block                                                 |
| `block_epoch`                       | `UINT256`         | Epoch number during which the block was created                                      |
| `block_metadata_id`                 | `VARBINARY`       | Unique identifier for the block metadata event                                       |
| `block_failed_proposer_indices`     | `ARRAY(INTEGER)`  | Indices of validators that failed to propose before this block                       |
| `block_previous_block_votes_bitvec` | `ARRAY(SMALLINT)` | Bit vector of validator votes on the previous block                                  |
| `tx_index`                          | `INTEGER`         | Position of the transaction within the block                                         |
| `tx_type`                           | `VARCHAR`         | Type of the transaction (e.g. user\_transaction, block\_metadata, state\_checkpoint) |
| `hash`                              | `VARBINARY`       | Unique hash identifying this transaction                                             |
| `version`                           | `UINT256`         | Global sequential version number assigned to this transaction                        |
| `gas_used`                          | `UINT256`         | Amount of gas consumed by the transaction                                            |
| `vm_status`                         | `VARCHAR`         | Detailed status message returned by the Move VM after execution                      |
| `success`                           | `BOOLEAN`         | Whether the transaction executed successfully                                        |
| `state_change_hash`                 | `VARBINARY`       | Hash of all state changes produced by the transaction                                |
| `event_root_hash`                   | `VARBINARY`       | Merkle root hash of all events emitted by the transaction                            |
| `state_checkpoint_hash`             | `VARBINARY`       | Hash of the state checkpoint after this transaction                                  |
| `accumulator_root_hash`             | `VARBINARY`       | Root hash of the transaction accumulator after this transaction                      |
| `events_count`                      | `INTEGER`         | Number of events emitted by this transaction                                         |
| `changes_count`                     | `INTEGER`         | Number of state changes produced by this transaction                                 |

## Table Sample

<TableSample />


# aptos.user_transactions
Source: https://docs.dune.com/data-catalog/aptos/user_transactions

Aptos user-initiated transactions — function calls, gas details, and sender information.

## Table description

The `aptos.user_transactions` table specifically tracks transactions initiated by users of the Aptos blockchain. It includes details such as the sender, the type of transaction, and the gas used, providing insights into how users interact with the network and its smart contracts.

## Table Schema

| Column                              | Type              | Description                                                                  |
| ----------------------------------- | ----------------- | ---------------------------------------------------------------------------- |
| `block_height`                      | `BIGINT`          | Sequential number identifying the block's position in the chain              |
| `block_date`                        | `DATE`            | Date of the block for daily aggregations                                     |
| `block_time`                        | `TIMESTAMP`       | Timestamp when the block was committed                                       |
| `block_hash`                        | `VARBINARY`       | Unique cryptographic hash identifying the block                              |
| `block_first_version`               | `UINT256`         | First transaction version included in the block                              |
| `block_last_version`                | `UINT256`         | Last transaction version included in the block                               |
| `block_proposer`                    | `VARBINARY`       | Address of the validator that proposed the block                             |
| `block_round`                       | `UINT256`         | Consensus round number for the block                                         |
| `block_epoch`                       | `UINT256`         | Epoch number during which the block was created                              |
| `block_metadata_id`                 | `VARBINARY`       | Unique identifier for the block metadata event                               |
| `block_failed_proposer_indices`     | `ARRAY(INTEGER)`  | Indices of validators that failed to propose before this block               |
| `block_previous_block_votes_bitvec` | `ARRAY(SMALLINT)` | Bit vector of validator votes on the previous block                          |
| `tx_index`                          | `INTEGER`         | Position of the transaction within the block                                 |
| `tx_type`                           | `VARCHAR`         | Type of the transaction (always user\_transaction for this table)            |
| `hash`                              | `VARBINARY`       | Unique hash identifying this transaction                                     |
| `version`                           | `UINT256`         | Global sequential version number assigned to this transaction                |
| `gas_used`                          | `UINT256`         | Amount of gas consumed by the transaction                                    |
| `vm_status`                         | `VARCHAR`         | Detailed status message returned by the Move VM after execution              |
| `success`                           | `BOOLEAN`         | Whether the transaction executed successfully                                |
| `state_change_hash`                 | `VARBINARY`       | Hash of all state changes produced by the transaction                        |
| `event_root_hash`                   | `VARBINARY`       | Merkle root hash of all events emitted by the transaction                    |
| `state_checkpoint_hash`             | `VARBINARY`       | Hash of the state checkpoint after this transaction                          |
| `accumulator_root_hash`             | `VARBINARY`       | Root hash of the transaction accumulator after this transaction              |
| `timestamp`                         | `UINT256`         | Unix timestamp of the transaction in microseconds                            |
| `sender`                            | `VARBINARY`       | Address of the account that submitted the transaction                        |
| `max_gas_amount`                    | `UINT256`         | Maximum gas units the sender is willing to pay                               |
| `gas_unit_price`                    | `UINT256`         | Price per gas unit in octas (1 APT = 10^8 octas)                             |
| `sequence_number`                   | `UINT256`         | Sender's account sequence number at the time of this transaction             |
| `expiration_timestamp_secs`         | `UINT256`         | Unix timestamp (seconds) after which the transaction expires                 |
| `events_count`                      | `INTEGER`         | Number of events emitted by this transaction                                 |
| `changes_count`                     | `INTEGER`         | Number of state changes produced by this transaction                         |
| `payload_type`                      | `VARCHAR`         | Type of transaction payload (e.g. entry\_function\_payload, script\_payload) |
| `entry_function_name`               | `VARCHAR`         | Name of the entry function called (empty if script payload)                  |
| `entry_function_module_name`        | `VARCHAR`         | Module containing the entry function called                                  |
| `entry_function_module_address`     | `VARBINARY`       | Address of the module containing the entry function                          |
| `script_bytecode`                   | `VARBINARY`       | Compiled bytecode of the script payload (empty if entry function)            |
| `script_abi`                        | `VARCHAR`         | ABI definition of the script payload                                         |
| `type_arguments`                    | `ARRAY(VARCHAR)`  | Generic type arguments passed to the entry function or script                |
| `arguments`                         | `ARRAY(VARCHAR)`  | Arguments passed to the entry function or script                             |

## Table Sample

<TableSample />


# bitcoin.blocks
Source: https://docs.dune.com/data-catalog/bitcoin/blocks

Bitcoin block headers — height, timestamp, difficulty, nonce, Merkle root, and miner reward.

## Table description

The `bitcoin.blocks` table represents the blocks in the Bitcoin blockchain. A block is a collection of transactions, and is identified by a block hash. Each block contains a reference to the previous block, forming a chain of blocks. The first block in the chain is called the genesis block.

## Table Schema

| Column                | Type        | Description                                                             |
| --------------------- | ----------- | ----------------------------------------------------------------------- |
| `time`                | `TIMESTAMP` | Timestamp when the block was mined                                      |
| `height`              | `BIGINT`    | Sequential block number indicating position in the chain                |
| `date`                | `DATE`      | Date of the block, truncated from the timestamp for daily aggregations  |
| `hash`                | `VARBINARY` | Unique 256-bit hash identifying this block                              |
| `bits`                | `VARBINARY` | Compact representation of the target difficulty threshold               |
| `chainwork`           | `VARBINARY` | Total cumulative proof-of-work performed up to and including this block |
| `difficulty`          | `DOUBLE`    | Mining difficulty target as a floating-point number                     |
| `total_fees`          | `DOUBLE`    | Total transaction fees (in BTC) collected in this block                 |
| `total_reward`        | `DOUBLE`    | Total miner reward (in BTC) including block subsidy and fees            |
| `mint_reward`         | `DOUBLE`    | Block subsidy (in BTC) awarded for mining this block                    |
| `merkle_root`         | `VARBINARY` | Merkle root hash of all transactions in the block                       |
| `transaction_count`   | `BIGINT`    | Number of transactions included in this block                           |
| `nonce`               | `BIGINT`    | Nonce value used by the miner to satisfy the proof-of-work target       |
| `coinbase`            | `VARBINARY` | Arbitrary data included by the miner in the coinbase transaction        |
| `previous_block_hash` | `VARBINARY` | Hash of the preceding block in the chain                                |
| `size`                | `BIGINT`    | Total size of the block in bytes                                        |
| `stripped_size`       | `BIGINT`    | Size of the block in bytes excluding witness data                       |
| `version`             | `BIGINT`    | Block version number indicating supported consensus rules               |
| `weight`              | `BIGINT`    | Block weight in weight units (max 4,000,000 per block)                  |

## Table Sample

<TableSample />


# bitcoin.inputs
Source: https://docs.dune.com/data-catalog/bitcoin/inputs

Bitcoin transaction inputs — spent UTXOs with previous transaction references and script signatures.

## Table description

The `bitcoin.inputs` table represents the inputs of a transaction. An input is a reference to an output of a previous transaction. It is the source of the funds for the transaction. The input contains the hash of the transaction that contains the output, the index of the output in the transaction, the script that unlocks the output, and the sequence number.

## Table Schema

| Column                 | Type               | Description                                                                                 |
| ---------------------- | ------------------ | ------------------------------------------------------------------------------------------- |
| `block_time`           | `TIMESTAMP`        | Timestamp of the block containing this transaction                                          |
| `block_date`           | `DATE`             | Date of the block for daily aggregations                                                    |
| `block_height`         | `BIGINT`           | Height of the block containing this transaction                                             |
| `block_hash`           | `VARBINARY`        | Hash of the block containing this transaction                                               |
| `tx_id`                | `VARBINARY`        | Hash of the transaction this input belongs to                                               |
| `index`                | `INTEGER`          | Position of this input within the transaction's input list                                  |
| `spent_block_height`   | `BIGINT`           | Block height of the transaction whose output is being spent                                 |
| `spent_tx_id`          | `VARBINARY`        | Transaction ID of the previously created output being spent                                 |
| `spent_output_number`  | `BIGINT`           | Index of the output being spent in the source transaction                                   |
| `value`                | `DOUBLE`           | Amount of BTC provided by this input                                                        |
| `address`              | `VARCHAR`          | Bitcoin address that owned the spent output                                                 |
| `type`                 | `VARCHAR`          | Address/script type of the spent output (e.g. pubkeyhash, scripthash, witness\_v0\_keyhash) |
| `coinbase`             | `VARBINARY`        | Coinbase data if this is a coinbase input, otherwise empty                                  |
| `is_coinbase`          | `BOOLEAN`          | Whether this input is a coinbase input (block reward)                                       |
| `script_asm`           | `VARCHAR`          | Script public key of the spent output in human-readable ASM format                          |
| `script_hex`           | `VARBINARY`        | Script public key of the spent output in raw hex                                            |
| `script_desc`          | `VARCHAR`          | Output descriptor of the spent output's script                                              |
| `script_signature_asm` | `VARCHAR`          | Unlocking script (scriptSig) in human-readable ASM format                                   |
| `script_signature_hex` | `VARBINARY`        | Unlocking script (scriptSig) in raw hex                                                     |
| `sequence`             | `BIGINT`           | Sequence number, used for relative time locks and replace-by-fee signaling                  |
| `witness_data`         | `ARRAY(VARBINARY)` | Segregated witness data stack for this input                                                |

## Table Sample

<TableSample />


# bitcoin.outputs
Source: https://docs.dune.com/data-catalog/bitcoin/outputs

Bitcoin transaction outputs — created UTXOs with value, script type, and locking conditions.

## Table description

The `bitcoin.outputs` table contains information about the outputs of Bitcoin transactions. An output is a record of the amount of Bitcoin being sent to a specific address.

## Table Schema

| Column         | Type        | Description                                                                           |
| -------------- | ----------- | ------------------------------------------------------------------------------------- |
| `block_time`   | `TIMESTAMP` | Timestamp of the block containing this transaction                                    |
| `block_date`   | `DATE`      | Date of the block for daily aggregations                                              |
| `block_height` | `BIGINT`    | Height of the block containing this transaction                                       |
| `block_hash`   | `VARBINARY` | Hash of the block containing this transaction                                         |
| `tx_id`        | `VARBINARY` | Hash of the transaction this output belongs to                                        |
| `index`        | `BIGINT`    | Position of this output within the transaction's output list                          |
| `value`        | `DOUBLE`    | Amount of BTC assigned to this output                                                 |
| `address`      | `VARCHAR`   | Bitcoin address that can spend this output                                            |
| `type`         | `VARCHAR`   | Address/script type of the output (e.g. pubkeyhash, scripthash, witness\_v0\_keyhash) |
| `script_asm`   | `VARCHAR`   | Locking script (scriptPubKey) in human-readable ASM format                            |
| `script_hex`   | `VARBINARY` | Locking script (scriptPubKey) in raw hex                                              |

## Table Sample

<TableSample />


# Bitcoin data
Source: https://docs.dune.com/data-catalog/bitcoin/overview

Bitcoin is the first and most well-known blockchain.

<CardGroup>
  <Card title="A full guide on all Bitcoin concepts" icon="map" href="https://web3datadegens.substack.com/p/how-to-analyze-bitcoin-data-with" />
</CardGroup>

Bitcoin uses a UTXO transaction model, and has a heavy focus on signatures and scripts for "locking" and "unlocking" tokens. It is also most well known for being tied to a 21 million token supply, and halvenings.

## Data Available

<CardGroup>
  <Card title="Blocks" icon="cube" href="/data-catalog/bitcoin/blocks">
    Blocks are the base unit that all transactions fit into.
  </Card>

  <Card title="Transactions" icon="exchange-alt" href="/data-catalog/bitcoin/transactions">
    Transactions contain all spent inputs and created outputs from a UTXO transaction.
  </Card>

  <Card title="Outputs" icon="file-export" href="/data-catalog/bitcoin/outputs">
    Just the outputs, unnested.
  </Card>

  <Card title="Inputs" icon="file-import" href="/data-catalog/bitcoin/inputs">
    Just the inputs, unnested.
  </Card>
</CardGroup>


# bitcoin.transactions
Source: https://docs.dune.com/data-catalog/bitcoin/transactions

Bitcoin transactions — version, locktime, size, weight, fee, and input/output counts.

## Table description

The `bitcoin.transactions` table represents the transactions on the Bitcoin blockchain. A transaction is a transfer of Bitcoin value that is broadcast to the network and collected into blocks. A transaction typically references previous transaction outputs as new transaction inputs and dedicates all input Bitcoin values to new outputs. Transactions are not encrypted, so it is possible to browse and view every transaction ever collected into a block.

## Table Schema

| Column         | Type                                                                                                                                                                                                                                                                                                | Description                                                               |
| -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- |
| `block_time`   | `TIMESTAMP`                                                                                                                                                                                                                                                                                         | Timestamp of the block containing this transaction                        |
| `block_date`   | `DATE`                                                                                                                                                                                                                                                                                              | Date of the block for daily aggregations                                  |
| `block_height` | `BIGINT`                                                                                                                                                                                                                                                                                            | Height of the block containing this transaction                           |
| `index`        | `INTEGER`                                                                                                                                                                                                                                                                                           | Position of this transaction within the block                             |
| `block_hash`   | `VARBINARY`                                                                                                                                                                                                                                                                                         | Hash of the block containing this transaction                             |
| `id`           | `VARBINARY`                                                                                                                                                                                                                                                                                         | Unique transaction identifier (txid)                                      |
| `lock_time`    | `BIGINT`                                                                                                                                                                                                                                                                                            | Earliest time or block height at which this transaction can be included   |
| `size`         | `BIGINT`                                                                                                                                                                                                                                                                                            | Total size of the serialized transaction in bytes                         |
| `virtual_size` | `BIGINT`                                                                                                                                                                                                                                                                                            | Virtual size in vbytes, accounting for SegWit discount                    |
| `coinbase`     | `VARBINARY`                                                                                                                                                                                                                                                                                         | Coinbase data if this is a coinbase transaction, otherwise empty          |
| `is_coinbase`  | `BOOLEAN`                                                                                                                                                                                                                                                                                           | Whether this is a coinbase transaction (block reward)                     |
| `version`      | `BIGINT`                                                                                                                                                                                                                                                                                            | Transaction version number                                                |
| `input_count`  | `INTEGER`                                                                                                                                                                                                                                                                                           | Number of inputs in this transaction                                      |
| `output_count` | `INTEGER`                                                                                                                                                                                                                                                                                           | Number of outputs in this transaction                                     |
| `input_value`  | `DOUBLE`                                                                                                                                                                                                                                                                                            | Total BTC value of all inputs                                             |
| `output_value` | `DOUBLE`                                                                                                                                                                                                                                                                                            | Total BTC value of all outputs                                            |
| `fee`          | `DOUBLE`                                                                                                                                                                                                                                                                                            | Transaction fee in BTC (input\_value minus output\_value)                 |
| `hex`          | `VARBINARY`                                                                                                                                                                                                                                                                                         | Full raw transaction in serialized hex format                             |
| `input`        | `ARRAY(ROW(VALUE DOUBLE, COINBASE VARBINARY, HEIGHT BIGINT, TX_ID VARBINARY, OUTPUT_NUMBER BIGINT, SCRIPT_PUB_KEY ROW(ADDRESS VARCHAR, ASM VARCHAR, DESC VARCHAR, HEX VARBINARY, TYPE VARCHAR), SCRIPT_SIGNATURE ROW(ASM VARCHAR, HEX VARBINARY), SEQUENCE BIGINT, WITNESS_DATA ARRAY(VARBINARY)))` | Array of transaction inputs with full details including spent output info |
| `output`       | `ARRAY(ROW(INDEX BIGINT, SCRIPT_PUB_KEY ROW(ADDRESS VARCHAR, ASM VARCHAR, DESC VARCHAR, HEX VARBINARY, TYPE VARCHAR), VALUE DOUBLE))`                                                                                                                                                               | Array of transaction outputs with script and value details                |

## Table Sample

<TableSample />

### Struct definitions

Within several of these columns is a data type of STRUCT which allows for representing nested hierarchical data and has key-value pairs. It's similar to a dictionary in Python and can be used to group fields together to make them more accessible.

Note that you can work with these columns with the syntax `input[1].witness_data[2]` or `input[3].script_pub_key.address` depending on lengths of arrays within each value. It is an `array(row(map))` type, and while it looks like just an array in the returned table - it is more than that!

**input**

| Field             | Data type       | Description                                                              |
| ----------------- | --------------- | ------------------------------------------------------------------------ |
| value             | double          | The number of Satoshis attached to this output                           |
| height            | bigint          | The height of the output                                                 |
| tx\_id            | string          | The transaction id of the output that is here used as input              |
| output\_number    | bigint          | The number (index) of the output in transaction `tx_id`'s outputs        |
| coinbase          | string          | The data specified in this transaction, if it was a coinbase transaction |
| sequence          | bigint          | Sequence number                                                          |
| witness\_data     | `array<string>` | Array of hex encoded witness data                                        |
| script\_signature | struct          | The script signature                                                     |
| script\_pub\_key  | struct          | The script public key                                                    |

***

**input.script\_signature**

| Field | Data type | Description                                                     |
| ----- | --------- | --------------------------------------------------------------- |
| hex   | string    | The transaction's script operations, in hex                     |
| asm   | string    | The transaction's script operations, in symbolic representation |

***

**input.script\_pub\_key**

| Field   | Data type | Description                                                     |
| ------- | --------- | --------------------------------------------------------------- |
| asm     | string    | The transaction's script operations, in symbolic representation |
| desc    | string    | The transaction's script operations, in symbolic representation |
| address | string    | The transaction's script operations, in symbolic representation |
| hex     | string    | The transaction's script operations, in hex                     |
| type    | string    | The address type of the output                                  |

***

**output**

| Field            | Data type | Description                                                                                                     |
| ---------------- | --------- | --------------------------------------------------------------------------------------------------------------- |
| index            | bigint    | 0-indexed number of an output within a transaction used by a later transaction to refer to that specific output |
| value            | double    | The number of Satoshis attached to this output                                                                  |
| script\_pub\_key | struct    | The public key                                                                                                  |

***

**output.script\_pub\_key**

| Field   | Data type | Description                                                     |
| ------- | --------- | --------------------------------------------------------------- |
| asm     | string    | The transaction's script operations, in symbolic representation |
| hex     | string    | The transaction's script operations, in hex                     |
| address | string    | The address the BTC came from                                   |
| type    | string    | The address type of the output                                  |


# Bring your Data
Source: https://docs.dune.com/data-catalog/bring-your-own-data

Dune offers several ways to bring your data to the platform.

## Data Upload

You can upload your data to Dune via the API or the UI. This allows you to combine your data with the data available on Dune.

<CardGroup>
  <Card title="Upload data via the User Interface" icon="upload" href="/web-app/upload-data">
    Upload data via dune.com
  </Card>

  <Card title="Upload data via the API" icon="square-terminal" href="/api-reference/tables/endpoint/upload">
    Programmatically upload data via the API
  </Card>
</CardGroup>

## LiveFetch Functions

You can also use the LiveFetch functions to fetch data from external APIs directly within your queries. This allows you to combine your data with external data sources in real-time and without having to upload the data to Dune.

<CardGroup>
  <Card title="LiveFetch Functions" icon="download" href="/query-engine/Functions-and-operators/live-fetch">
    Fetch data from external APIs directly within your queries
  </Card>
</CardGroup>

## Adding new blockchains

If you are a representative of a blockchain you would like to see supported on Dune, please reach out to us. We are always looking to expand our data catalog.

<CardGroup>
  <Card title="Request a new blockchain integration!" icon="warehouse" href="https://dune.com/enterprise" />
</CardGroup>

## Adding other relevant data

If you have other relevant web3 data that you would like to see on Dune, please reach out to us. We are always looking to expand our data catalog.
Data in this category could include web3 social, enriched blockchain data, tradfi data, pricing data and more.

A few examples of data we already have in this category are:

* [**farcaster.xyz**](https://www.farcaster.xyz/) data is supplied by [**Neynar**](https://www.neynar.xyz/)
* the [**Lens protocol**](https://lens.xyz) team uploads their data
* [**Snapshot**](https://snapshot.org/#/) team uploads their data
* [**Reservoir**](https://reservoir.api) provides enriched and cleaned NFT trading data
* etc...

<Info> The criteria for adding data in this category is that it should be relevant to the web3 ecosystem and should be of high quality.</Info>

<CardGroup>
  <Card title="Request a new data integration!" icon="tower-cell" href="https://dune.com/enterprise" />
</CardGroup>


# cardano.adapot
Source: https://docs.dune.com/data-catalog/cardano/adapot

Description of the adapot table on Dune

## Table Description

Contains per-epoch ADA supply distribution data for the Cardano blockchain. Each row represents a snapshot of how ADA is distributed across the system at a given epoch — including the treasury, reserves, UTXO set, staking deposits, fees, and reward pots. This table is useful for tracking Cardano's monetary policy, inflation schedule, and the flow of ADA between protocol-managed pots over time.

## Column Descriptions

| **Column**                 | **Description**                                                  | **Type**      |
| -------------------------- | ---------------------------------------------------------------- | ------------- |
| **epoch**                  | The epoch number for this snapshot.                              | integer       |
| **slot**                   | The slot number associated with this snapshot.                   | bigint        |
| **deposits\_stake**        | Total ADA locked in staking key deposits, in lovelace.           | decimal(38,0) |
| **fees**                   | Total transaction fees collected during this epoch, in lovelace. | decimal(38,0) |
| **utxo**                   | Total ADA held in the UTXO set, in lovelace.                     | decimal(38,0) |
| **treasury**               | Total ADA in the treasury, in lovelace.                          | decimal(38,0) |
| **reserves**               | Total ADA remaining in the reserves, in lovelace.                | decimal(38,0) |
| **circulation**            | Total ADA in circulation (outside reserves), in lovelace.        | decimal(38,0) |
| **distributed\_rewards**   | Total ADA distributed as staking rewards, in lovelace.           | decimal(38,0) |
| **undistributed\_rewards** | Total ADA in the reward pot not yet distributed, in lovelace.    | decimal(38,0) |
| **rewards\_pot**           | Total ADA in the rewards pot, in lovelace.                       | decimal(38,0) |
| **pool\_rewards\_pot**     | Total ADA allocated to stake pool rewards, in lovelace.          | decimal(38,0) |
| **\_updated\_at**          | The time when this record was last updated.                      | timestamp     |
| **\_ingested\_at**         | The time when this record was ingested into Dune.                | timestamp     |

## Table Sample

<TableSample />


# cardano.address_utxo
Source: https://docs.dune.com/data-catalog/cardano/address_utxo

Description of the address_utxo table on Dune

## Table Description

Contains unspent transaction output (UTXO) data for the Cardano blockchain. Each row represents a single output at a specific address, including native asset details (policy ID, asset name, quantity), datum information for smart contract interactions, and script references.

## Column Descriptions

| **Column**                  | **Description**                                                                               | **Type**      |
| --------------------------- | --------------------------------------------------------------------------------------------- | ------------- |
| **tx\_hash**                | The hash of the transaction that created this output.                                         | varchar       |
| **output\_index**           | The index of the output within the transaction.                                               | integer       |
| **asset\_unit**             | The concatenation of policy ID and asset name, uniquely identifying the asset. Empty for ADA. | varchar       |
| **policy\_id**              | The hash of the minting policy script that governs the asset.                                 | varchar       |
| **asset\_name**             | The name of the native asset (hex-encoded).                                                   | varchar       |
| **quantity**                | The quantity of the asset held in this UTXO.                                                  | decimal(38,0) |
| **address**                 | The Cardano address holding this UTXO.                                                        | varchar       |
| **stake\_address**          | The stake (reward) address associated with this UTXO's address.                               | varchar       |
| **payment\_credential**     | The payment credential (key hash or script hash) of the address.                              | varchar       |
| **stake\_credential**       | The stake credential of the address.                                                          | varchar       |
| **inline\_datum**           | The inline datum attached directly to the UTXO (CBOR-encoded).                                | varchar       |
| **datum\_hash**             | The hash of the datum attached to this UTXO (for non-inline datums).                          | varchar       |
| **script\_ref**             | A reference script attached to this UTXO, available for use by other transactions.            | varchar       |
| **reference\_script\_hash** | The hash of the reference script attached to this UTXO.                                       | varchar       |
| **is\_collateral\_return**  | Whether this output is a collateral return output.                                            | boolean       |
| **epoch**                   | The epoch in which this UTXO was created.                                                     | integer       |
| **slot**                    | The absolute slot number when this UTXO was created.                                          | bigint        |
| **block\_hash**             | The hash of the block containing the transaction that created this UTXO.                      | varchar       |
| **block\_time**             | The timestamp of the block containing this UTXO.                                              | timestamp     |
| **\_updated\_at**           | The time when this record was last updated.                                                   | timestamp     |
| **\_ingested\_at**          | The time when this record was ingested into Dune.                                             | timestamp     |

## Table Sample

<TableSample />


# cardano.asset_data
Source: https://docs.dune.com/data-catalog/cardano/asset_data

Description of the asset_data table on Dune

## Table Description

Contains metadata for native assets on the Cardano blockchain. Each row represents a unique asset identified by its policy ID and token name, and includes off-chain metadata such as display name, ticker, decimals, URL, categories, and latest price information.

## Column Descriptions

| **Column**         | **Description**                                                         | **Type**       |
| ------------------ | ----------------------------------------------------------------------- | -------------- |
| **policy\_id**     | The hash of the minting policy script governing this asset.             | varchar        |
| **token\_name**    | The on-chain token name (hex-encoded).                                  | varchar        |
| **name**           | The human-readable display name of the asset.                           | varchar        |
| **url**            | The URL associated with the asset (e.g., project website).              | varchar        |
| **ticker**         | The ticker symbol of the asset (e.g., SUNDAE, DJED).                    | varchar        |
| **decimals**       | The number of decimal places used to display the asset's quantity.      | bigint         |
| **created\_at**    | The timestamp when the asset was first minted.                          | timestamp      |
| **categories**     | An array of categories the asset belongs to (e.g., DeFi, NFT).          | array(varchar) |
| **price**          | The latest known price of the asset in USD.                             | double         |
| **fetched\_at**    | The timestamp when the metadata was last fetched from external sources. | timestamp      |
| **\_updated\_at**  | The time when this record was last updated.                             | timestamp      |
| **\_ingested\_at** | The time when this record was ingested into Dune.                       | timestamp      |

## Table Sample

<TableSample />


# cardano.asset_mint
Source: https://docs.dune.com/data-catalog/cardano/asset_mint

Description of the asset_mint table on Dune

## Table Description

Tracks native asset minting and burning events on the Cardano blockchain. Each row represents a mint or burn operation for a specific native asset within a transaction. Positive quantities indicate minting; negative quantities indicate burning.

## Column Descriptions

| **Column**         | **Description**                                                                | **Type**  |
| ------------------ | ------------------------------------------------------------------------------ | --------- |
| **slot**           | The absolute slot number when the mint/burn occurred.                          | bigint    |
| **tx\_hash**       | The hash of the transaction containing the mint/burn.                          | varchar   |
| **policy\_id**     | The hash of the minting policy script governing this asset.                    | varchar   |
| **asset\_name**    | The name of the asset (hex-encoded).                                           | varchar   |
| **asset\_unit**    | The concatenation of policy ID and asset name, uniquely identifying the asset. | varchar   |
| **fingerprint**    | The CIP-14 asset fingerprint (human-readable asset identifier).                | varchar   |
| **quantity**       | The quantity minted (positive) or burned (negative).                           | bigint    |
| **mint\_type**     | The type of mint operation (e.g., mint or burn).                               | varchar   |
| **block\_number**  | The sequential number of the block containing this event.                      | bigint    |
| **block\_time**    | The timestamp of the block containing this event.                              | timestamp |
| **\_updated\_at**  | The time when this record was last updated.                                    | timestamp |
| **\_ingested\_at** | The time when this record was ingested into Dune.                              | timestamp |

## Table Sample

<TableSample />


# cardano.block
Source: https://docs.dune.com/data-catalog/cardano/block

Description of the block table on Dune

## Table Description

Contains block-level data for the Cardano blockchain. Each row represents a single block and includes information about the epoch, slot, transaction count, total output value, fees collected, and protocol version.

## Column Descriptions

| **Column**                  | **Description**                                                                      | **Type**      |
| --------------------------- | ------------------------------------------------------------------------------------ | ------------- |
| **block\_hash**             | The hash uniquely identifying the block.                                             | varchar       |
| **block\_number**           | The sequential number of the block in the chain.                                     | bigint        |
| **block\_time**             | The timestamp when the block was produced.                                           | timestamp     |
| **epoch**                   | The epoch number in which the block was produced.                                    | integer       |
| **slot**                    | The absolute slot number of the block.                                               | bigint        |
| **epoch\_slot**             | The slot number relative to the start of the epoch.                                  | bigint        |
| **era**                     | The Cardano era during which the block was produced (e.g., Shelley, Alonzo, Conway). | integer       |
| **tx\_count**               | The number of transactions included in the block.                                    | integer       |
| **total\_output\_lovelace** | The total output value of all transactions in the block, in lovelace.                | decimal(38,0) |
| **total\_fees\_lovelace**   | The total transaction fees collected in the block, in lovelace.                      | bigint        |
| **protocol\_version**       | The protocol version active when the block was produced.                             | varchar       |
| **prev\_block\_hash**       | The hash of the preceding block.                                                     | varchar       |
| **pool\_hash**              | The hash of the stake pool that produced the block.                                  | varchar       |
| **\_updated\_at**           | The time when this record was last updated.                                          | timestamp     |
| **\_ingested\_at**          | The time when this record was ingested into Dune.                                    | timestamp     |

## Table Sample

<TableSample />


# cardano.drep_dist_enriched
Source: https://docs.dune.com/data-catalog/cardano/drep_dist_enriched

Description of the drep_dist_enriched table on Dune

## Table Description

Contains enriched delegated representative (DRep) voting power distribution data for the Cardano blockchain. Each row represents a DRep's delegated stake for a given epoch, including their type, on-chain ID, activity status, and optional human-readable name sourced from anchor metadata. This table is central to analyzing Cardano's on-chain governance participation under CIP-1694.

## Column Descriptions

| **Column**         | **Description**                                                         | **Type**  |
| ------------------ | ----------------------------------------------------------------------- | --------- |
| **drep\_hash**     | The hash identifier of the DRep.                                        | varchar   |
| **drep\_type**     | The type of DRep (e.g., key hash, script hash, abstain, no confidence). | varchar   |
| **drep\_id**       | The bech32-encoded DRep ID.                                             | varchar   |
| **amount**         | The total voting power delegated to this DRep, in lovelace.             | bigint    |
| **epoch**          | The epoch number for this distribution snapshot.                        | integer   |
| **active\_until**  | The last epoch in which this DRep is considered active.                 | integer   |
| **expiry**         | The epoch at which this DRep's registration expires if not renewed.     | integer   |
| **anchor\_url**    | The URL pointing to the DRep's off-chain metadata.                      | varchar   |
| **drep\_name**     | Human-readable name of the DRep, sourced from anchor metadata.          | varchar   |
| **\_updated\_at**  | The time when this record was last updated.                             | timestamp |
| **\_ingested\_at** | The time when this record was ingested into Dune.                       | timestamp |

## Table Sample

<TableSample />


# cardano.epoch_stake
Source: https://docs.dune.com/data-catalog/cardano/epoch_stake

Description of the epoch_stake table on Dune

## Table Description

Contains per-epoch stake delegation snapshots for the Cardano blockchain. Each row represents the stake delegated by a specific stake address to a stake pool for a given epoch, including the epoch when delegation began and when it became active.

## Column Descriptions

| **Column**            | **Description**                                                         | **Type**      |
| --------------------- | ----------------------------------------------------------------------- | ------------- |
| **epoch**             | The epoch number for this stake snapshot.                               | integer       |
| **stake\_address**    | The stake (reward) address of the delegator.                            | varchar       |
| **stake\_lovelace**   | The amount of stake delegated, in lovelace.                             | decimal(38,0) |
| **pool\_hash**        | The hash of the stake pool to which the stake is delegated.             | varchar       |
| **delegation\_epoch** | The epoch in which the delegation was registered.                       | integer       |
| **active\_epoch**     | The epoch in which the delegation became active for reward calculation. | integer       |
| **\_updated\_at**     | The time when this record was last updated.                             | timestamp     |
| **\_ingested\_at**    | The time when this record was ingested into Dune.                       | timestamp     |

## Table Sample

<TableSample />


# cardano.gov_action_proposal
Source: https://docs.dune.com/data-catalog/cardano/gov_action_proposal

Description of the gov_action_proposal table on Dune

## Table Description

Contains on-chain governance action proposals submitted under Cardano's CIP-1694 governance framework (Voltaire era). Each row represents a governance proposal, including the proposal type (e.g., parameter change, treasury withdrawal, hard fork initiation, no confidence), the deposit amount, return address, and an anchor linking to off-chain rationale.

## Column Descriptions

| **Column**            | **Description**                                                                                                                            | **Type**  |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | --------- |
| **tx\_hash**          | The hash of the transaction that submitted the proposal.                                                                                   | varchar   |
| **proposal\_index**   | The index of the proposal within the transaction.                                                                                          | integer   |
| **tx\_index**         | The index of the transaction within the block.                                                                                             | integer   |
| **slot**              | The absolute slot number when the proposal was submitted.                                                                                  | bigint    |
| **deposit\_lovelace** | The deposit amount required to submit the proposal, in lovelace.                                                                           | bigint    |
| **return\_address**   | The address to which the deposit will be returned.                                                                                         | varchar   |
| **proposal\_type**    | The type of governance action (e.g., ParameterChange, TreasuryWithdrawals, HardForkInitiation, NoConfidence, NewConstitution, InfoAction). | varchar   |
| **proposal\_details** | JSON-encoded details specific to the proposal type.                                                                                        | varchar   |
| **anchor\_url**       | The URL pointing to off-chain rationale and metadata for the proposal.                                                                     | varchar   |
| **anchor\_hash**      | The hash of the content at the anchor URL, for integrity verification.                                                                     | varchar   |
| **epoch**             | The epoch in which the proposal was submitted.                                                                                             | integer   |
| **block\_number**     | The sequential number of the block containing the proposal.                                                                                | bigint    |
| **block\_time**       | The timestamp of the block containing the proposal.                                                                                        | timestamp |
| **\_updated\_at**     | The time when this record was last updated.                                                                                                | timestamp |
| **\_ingested\_at**    | The time when this record was ingested into Dune.                                                                                          | timestamp |

## Table Sample

<TableSample />


# cardano.gov_action_proposal_status
Source: https://docs.dune.com/data-catalog/cardano/gov_action_proposal_status

Description of the gov_action_proposal_status table on Dune

## Table Description

Tracks the current status and voting statistics for Cardano governance proposals. Each row represents the latest state of a governance action, including whether it has been ratified, expired, or is still active, along with aggregated voting statistics broken down by voter role.

## Column Descriptions

| **Column**                | **Description**                                                                | **Type**  |
| ------------------------- | ------------------------------------------------------------------------------ | --------- |
| **gov\_action\_tx\_hash** | The hash of the transaction that submitted the governance proposal.            | varchar   |
| **gov\_action\_index**    | The index of the governance proposal within its submission transaction.        | integer   |
| **proposal\_type**        | The type of governance action (e.g., ParameterChange, TreasuryWithdrawals).    | varchar   |
| **status**                | The current status of the proposal (e.g., Active, Ratified, Expired, Enacted). | varchar   |
| **voting\_stats**         | JSON-encoded voting statistics including vote counts by role (DRep, SPO, CC).  | varchar   |
| **epoch**                 | The epoch as of which this status snapshot applies.                            | integer   |
| **\_updated\_at**         | The time when this record was last updated.                                    | timestamp |
| **\_ingested\_at**        | The time when this record was ingested into Dune.                              | timestamp |

## Table Sample

<TableSample />


# cardano.gov_action_vote
Source: https://docs.dune.com/data-catalog/cardano/gov_action_vote

Description of the gov_action_vote table on Dune

## Table Description

Contains votes cast on Cardano governance action proposals. Under CIP-1694, three groups can vote: Delegated Representatives (DReps), Stake Pool Operators (SPOs), and the Constitutional Committee. Each row represents a single vote, including the voter role, the governance action being voted on, and the vote cast (yes, no, or abstain).

## Column Descriptions

| **Column**                | **Description**                                                                    | **Type**  |
| ------------------------- | ---------------------------------------------------------------------------------- | --------- |
| **tx\_hash**              | The hash of the transaction containing this vote.                                  | varchar   |
| **vote\_index**           | The index of the vote within the transaction.                                      | integer   |
| **tx\_index**             | The index of the transaction within the block.                                     | integer   |
| **slot**                  | The absolute slot number when the vote was cast.                                   | bigint    |
| **voter\_role**           | The role of the voter (e.g., DRep, SPO, ConstitutionalCommittee).                  | varchar   |
| **voter\_hash**           | The hash identifying the voter (DRep credential, pool hash, or CC member hash).    | varchar   |
| **gov\_action\_tx\_hash** | The hash of the transaction that submitted the governance proposal being voted on. | varchar   |
| **gov\_action\_index**    | The index of the governance proposal within its submission transaction.            | integer   |
| **vote**                  | The vote cast (e.g., Yes, No, Abstain).                                            | varchar   |
| **anchor\_url**           | The URL pointing to off-chain rationale for the vote.                              | varchar   |
| **anchor\_hash**          | The hash of the content at the anchor URL.                                         | varchar   |
| **epoch**                 | The epoch in which the vote was cast.                                              | integer   |
| **block\_number**         | The sequential number of the block containing this vote.                           | bigint    |
| **block\_time**           | The timestamp of the block containing this vote.                                   | timestamp |
| **\_updated\_at**         | The time when this record was last updated.                                        | timestamp |
| **\_ingested\_at**        | The time when this record was ingested into Dune.                                  | timestamp |

## Table Sample

<TableSample />


# cardano.off_chain_pool_data
Source: https://docs.dune.com/data-catalog/cardano/off_chain_pool_data

Description of the off_chain_pool_data table on Dune

## Table Description

Contains off-chain metadata for Cardano stake pools. Each row represents a stake pool's self-reported metadata — including its ticker symbol, name, description, and homepage — as fetched from the metadata URL registered on-chain. This table is useful for enriching on-chain staking data with human-readable pool identifiers.

## Column Descriptions

| **Column**         | **Description**                                               | **Type**  |
| ------------------ | ------------------------------------------------------------- | --------- |
| **pool\_hash**     | The hash identifier of the stake pool.                        | varchar   |
| **pool\_id**       | The bech32-encoded pool ID.                                   | varchar   |
| **ticker**         | The pool's ticker symbol (e.g., BLOCK, ADAOZ).                | varchar   |
| **name**           | The human-readable name of the pool.                          | varchar   |
| **description**    | A description of the pool provided by the operator.           | varchar   |
| **homepage**       | The URL of the pool operator's homepage.                      | varchar   |
| **metadata\_url**  | The URL from which the pool metadata was fetched.             | varchar   |
| **metadata\_hash** | The hash of the metadata content, for integrity verification. | varchar   |
| **fetched\_at**    | The timestamp when the metadata was last fetched.             | timestamp |
| **version**        | The version number of the metadata record.                    | integer   |
| **\_updated\_at**  | The time when this record was last updated.                   | timestamp |
| **\_ingested\_at** | The time when this record was ingested into Dune.             | timestamp |

## Table Sample

<TableSample />


# Cardano Data
Source: https://docs.dune.com/data-catalog/cardano/overview

Cardano blockchain data on Dune

## What is Cardano?

Cardano is an open-source, proof-of-stake blockchain platform designed for security, scalability, and sustainability. Built on peer-reviewed academic research and developed using the Haskell programming language, Cardano uses the Ouroboros consensus protocol — the first provably secure proof-of-stake protocol. The platform supports smart contracts through Plutus (based on Haskell) and Marlowe (a domain-specific language for financial contracts), and uses an extended UTXO (eUTXO) model that combines the security benefits of Bitcoin's UTXO model with the programmability of account-based systems.

Cardano's native token, ADA, is used for transaction fees, staking, and governance participation. The smallest unit of ADA is called a **lovelace** (1 ADA = 1,000,000 lovelace).

## Key Concepts of Cardano

### **Extended UTXO Model (eUTXO)**

Unlike account-based blockchains, Cardano uses an extended UTXO model where each transaction consumes unspent outputs and produces new ones. This model enables deterministic transaction execution — users can verify the outcome of a transaction before submitting it. The "extended" part allows UTXOs to carry arbitrary data (datums) and be locked by scripts (validators).

### **Epochs and Slots**

Cardano divides time into **epochs** (approximately 5 days each), which are subdivided into **slots** (1 second each). A block can be produced in each slot by a slot leader selected through the Ouroboros protocol. This structure governs staking rewards, delegation cycles, and governance timelines.

### **Staking and Delegation**

ADA holders can delegate their stake to stake pools without locking their funds. Staking rewards are calculated per epoch based on the amount of stake delegated to a pool. The `epoch_stake` and `pool_reward` tables provide visibility into delegation snapshots and reward distributions.

### **Native Assets**

Cardano supports native multi-asset functionality at the ledger level — tokens are treated as first-class citizens alongside ADA without requiring smart contracts. Each native asset is identified by a **policy ID** (the hash of the minting policy script) and an **asset name**. The `asset_mint` and `asset_data` tables track minting events and token metadata.

### **Plutus Smart Contracts**

Cardano smart contracts (validators) are written in Plutus and executed on-chain when UTXOs guarded by scripts are consumed. Transaction scripts include redeemers (input data to the script) and datums (data attached to UTXOs). The `transaction_scripts` table captures script execution details including resource consumption.

### **On-Chain Governance (CIP-1694)**

Cardano's Voltaire era introduced on-chain governance, allowing ADA holders, stake pool operators, and a constitutional committee to vote on governance actions such as protocol parameter changes, treasury withdrawals, and hard forks. The `gov_action_proposal`, `gov_action_vote`, and `gov_action_proposal_status` tables provide full visibility into governance activity.

<CardGroup>
  <Card title="Cardano documentation" icon="link" href="https://docs.cardano.org">
    Explore comprehensive documentation of Cardano, detailing its architecture, protocol, and resources for developers.
  </Card>

  <Card title="Cardano explorer" icon="magnifying-glass" href="https://cardanoscan.io">
    Browse blocks, transactions, and stake pools on Cardano's block explorer.
  </Card>
</CardGroup>

## Cardano Data on Dune

Cardano data on Dune covers core ledger activity (blocks, transactions, UTXOs), native assets, staking and rewards, smart contract execution, and on-chain governance. Here are the Cardano tables available on Dune:

<CardGroup>
  <Card title="Blocks" icon="cube" href="/data-catalog/cardano/block">
    Block-level data including epoch, slot, transaction counts, total output, and fees.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="/data-catalog/cardano/transaction">
    Transaction details including fees, validity status, and input/output counts.
  </Card>

  <Card title="Address UTXOs" icon="wallet" href="/data-catalog/cardano/address_utxo">
    Unspent transaction outputs with asset details, addresses, datums, and script references.
  </Card>

  <Card title="Transaction Inputs" icon="arrow-right-to-bracket" href="/data-catalog/cardano/tx_input">
    Records of UTXO consumption, linking spent outputs to the transactions that spend them.
  </Card>

  <Card title="Epoch Stake" icon="layer-group" href="/data-catalog/cardano/epoch_stake">
    Per-epoch stake delegation snapshots showing stake amounts and pool assignments.
  </Card>

  <Card title="Pool Rewards" icon="coins" href="/data-catalog/cardano/pool_reward">
    Staking reward distributions per epoch, including reward type and pool information.
  </Card>

  <Card title="Asset Mints" icon="fire" href="/data-catalog/cardano/asset_mint">
    Native asset minting and burning events with policy IDs and quantities.
  </Card>

  <Card title="Asset Data" icon="tag" href="/data-catalog/cardano/asset_data">
    Token metadata including name, ticker, decimals, and price information.
  </Card>

  <Card title="Transaction Scripts" icon="code" href="/data-catalog/cardano/transaction_scripts">
    Plutus and native script executions with redeemer data and resource consumption.
  </Card>

  <Card title="Smart Contract Registry" icon="book" href="/data-catalog/cardano/smart_contract_registry">
    Registry of known smart contracts with project names, categories, and script languages.
  </Card>

  <Card title="Transaction Metadata" icon="memo" href="/data-catalog/cardano/transaction_metadata">
    Arbitrary JSON metadata attached to transactions via metadata labels.
  </Card>

  <Card title="Governance Proposals" icon="scroll" href="/data-catalog/cardano/gov_action_proposal">
    On-chain governance action proposals including type, deposit, and anchor details.
  </Card>

  <Card title="Governance Votes" icon="check-to-slot" href="/data-catalog/cardano/gov_action_vote">
    Votes cast on governance proposals by DReps, SPOs, and the constitutional committee.
  </Card>

  <Card title="Governance Proposal Status" icon="chart-bar" href="/data-catalog/cardano/gov_action_proposal_status">
    Current status and voting statistics for governance proposals.
  </Card>

  <Card title="ADA Pot" icon="vault" href="/data-catalog/cardano/adapot">
    Per-epoch ADA supply distribution across treasury, reserves, UTXO, and reward pots.
  </Card>

  <Card title="DRep Distribution" icon="users" href="/data-catalog/cardano/drep_dist_enriched">
    Delegated representative voting power distribution and metadata per epoch.
  </Card>

  <Card title="Off-Chain Pool Data" icon="server" href="/data-catalog/cardano/off_chain_pool_data">
    Stake pool off-chain metadata including ticker, name, description, and homepage.
  </Card>
</CardGroup>


# cardano.pool_reward
Source: https://docs.dune.com/data-catalog/cardano/pool_reward

Description of the pool_reward table on Dune

## Table Description

Contains staking reward distribution data for the Cardano blockchain. Each row represents a reward earned by a stake address for a specific epoch, including the reward type (leader, member, treasury, reserves), the pool that generated the reward, and the epoch in which the reward becomes spendable.

## Column Descriptions

| **Column**           | **Description**                                                | **Type**      |
| -------------------- | -------------------------------------------------------------- | ------------- |
| **stake\_address**   | The stake (reward) address that earned the reward.             | varchar       |
| **earned\_epoch**    | The epoch in which the reward was earned.                      | integer       |
| **spendable\_epoch** | The epoch in which the reward becomes spendable.               | integer       |
| **reward\_type**     | The type of reward (e.g., leader, member, treasury, reserves). | varchar       |
| **pool\_hash**       | The hash of the stake pool that generated the reward.          | varchar       |
| **amount\_lovelace** | The reward amount, in lovelace.                                | decimal(38,0) |
| **slot**             | The slot number associated with the reward record.             | bigint        |
| **\_updated\_at**    | The time when this record was last updated.                    | timestamp     |
| **\_ingested\_at**   | The time when this record was ingested into Dune.              | timestamp     |

## Table Sample

<TableSample />


# cardano.smart_contract_registry
Source: https://docs.dune.com/data-catalog/cardano/smart_contract_registry

Description of the smart_contract_registry table on Dune

## Table Description

A curated registry of known smart contracts on the Cardano blockchain. Each row maps a script hash to human-readable metadata including the project name, contract name, category, purpose, and the scripting language used. This table is useful for enriching on-chain data with project-level context.

## Column Descriptions

| **Column**         | **Description**                                                                 | **Type**  |
| ------------------ | ------------------------------------------------------------------------------- | --------- |
| **script\_hash**   | The hash uniquely identifying the smart contract script.                        | varchar   |
| **project\_name**  | The name of the project that deployed the contract (e.g., SundaeSwap, Minswap). | varchar   |
| **contract\_name** | The specific name of the contract within the project.                           | varchar   |
| **category**       | The high-level category of the contract (e.g., DEX, Lending, NFT Marketplace).  | varchar   |
| **sub\_category**  | A more specific sub-category for the contract.                                  | varchar   |
| **purpose**        | The purpose or function of the contract (e.g., swap, liquidity pool, oracle).   | varchar   |
| **language**       | The scripting language used (e.g., Plutus V1, Plutus V2, Plutus V3, Aiken).     | varchar   |
| **fetched\_at**    | The timestamp when the registry data was last fetched.                          | timestamp |
| **version**        | The version number of the contract metadata entry.                              | integer   |
| **\_updated\_at**  | The time when this record was last updated.                                     | timestamp |
| **\_ingested\_at** | The time when this record was ingested into Dune.                               | timestamp |

## Table Sample

<TableSample />


# cardano.transaction
Source: https://docs.dune.com/data-catalog/cardano/transaction

Description of the transaction table on Dune

## Table Description

Contains transaction-level data for the Cardano blockchain. Each row represents a single transaction and includes fee information, validity status, input/output counts, and references to collateral and script data.

## Column Descriptions

| **Column**                       | **Description**                                                                         | **Type**  |
| -------------------------------- | --------------------------------------------------------------------------------------- | --------- |
| **tx\_hash**                     | The hash uniquely identifying the transaction.                                          | varchar   |
| **block\_hash**                  | The hash of the block containing this transaction.                                      | varchar   |
| **block\_number**                | The sequential number of the block containing this transaction.                         | bigint    |
| **slot**                         | The absolute slot number of the block containing this transaction.                      | bigint    |
| **epoch**                        | The epoch number in which the transaction was included.                                 | integer   |
| **block\_time**                  | The timestamp of the block containing this transaction.                                 | timestamp |
| **tx\_index**                    | The index position of the transaction within the block.                                 | integer   |
| **fee\_lovelace**                | The fee paid for the transaction, in lovelace.                                          | bigint    |
| **is\_invalid**                  | Whether the transaction failed phase-2 validation (script execution).                   | boolean   |
| **script\_data\_hash**           | The hash of the script-related data (datums and redeemers) included in the transaction. | varchar   |
| **total\_collateral\_lovelace**  | The total collateral provided for script execution, in lovelace.                        | bigint    |
| **treasury\_donation\_lovelace** | The amount donated to the Cardano treasury, in lovelace.                                | bigint    |
| **inputs**                       | JSON array of transaction inputs (UTXOs consumed).                                      | varchar   |
| **outputs**                      | JSON array of transaction outputs (UTXOs created).                                      | varchar   |
| **reference\_inputs**            | JSON array of reference inputs used for read-only access to UTXOs.                      | varchar   |
| **collateral\_inputs**           | JSON array of collateral inputs used in case of script failure.                         | varchar   |
| **input\_count**                 | The number of inputs consumed by the transaction.                                       | bigint    |
| **output\_count**                | The number of outputs produced by the transaction.                                      | bigint    |
| **\_updated\_at**                | The time when this record was last updated.                                             | timestamp |
| **\_ingested\_at**               | The time when this record was ingested into Dune.                                       | timestamp |

## Table Sample

<TableSample />


# cardano.transaction_metadata
Source: https://docs.dune.com/data-catalog/cardano/transaction_metadata

Description of the transaction_metadata table on Dune

## Table Description

Contains arbitrary metadata attached to Cardano transactions. Cardano allows transactions to include structured metadata indexed by integer keys (metadata labels). Common uses include NFT metadata (label 721), message signing, and protocol-specific data. Each row represents a single metadata key-value pair within a transaction.

## Column Descriptions

| **Column**         | **Description**                                                                | **Type**  |
| ------------------ | ------------------------------------------------------------------------------ | --------- |
| **slot**           | The absolute slot number of the block containing this transaction.             | bigint    |
| **block\_number**  | The sequential number of the block containing this transaction.                | bigint    |
| **block\_time**    | The timestamp of the block containing this transaction.                        | timestamp |
| **tx\_hash**       | The hash of the transaction containing this metadata.                          | varchar   |
| **metadata\_key**  | The integer label identifying the metadata entry (e.g., 721 for NFT metadata). | varchar   |
| **metadata\_json** | The JSON-encoded metadata value associated with the key.                       | varchar   |
| **\_updated\_at**  | The time when this record was last updated.                                    | timestamp |
| **\_ingested\_at** | The time when this record was ingested into Dune.                              | timestamp |

## Table Sample

<TableSample />


# cardano.transaction_scripts
Source: https://docs.dune.com/data-catalog/cardano/transaction_scripts

Description of the transaction_scripts table on Dune

## Table Description

Contains smart contract script execution data for Cardano transactions. Each row represents a script (Plutus or native) invoked during a transaction, including its purpose (spend, mint, certify, reward), redeemer data, datum hash, and computational resource consumption (memory and CPU units).

## Column Descriptions

| **Column**                | **Description**                                                                     | **Type**  |
| ------------------------- | ----------------------------------------------------------------------------------- | --------- |
| **slot**                  | The absolute slot number of the block containing this transaction.                  | bigint    |
| **block\_number**         | The sequential number of the block containing this transaction.                     | bigint    |
| **block\_hash**           | The hash of the block containing this transaction.                                  | varchar   |
| **block\_time**           | The timestamp of the block containing this transaction.                             | timestamp |
| **tx\_hash**              | The hash of the transaction that invoked this script.                               | varchar   |
| **script\_hash**          | The hash uniquely identifying the script.                                           | varchar   |
| **script\_type**          | The type of script (e.g., 0 = native, 1 = Plutus V1, 2 = Plutus V2, 3 = Plutus V3). | integer   |
| **datum\_hash**           | The hash of the datum consumed by the script.                                       | varchar   |
| **purpose**               | The purpose of the script execution (e.g., spend, mint, certify, reward).           | varchar   |
| **redeemer\_index**       | The index of the redeemer in the transaction's redeemer list.                       | integer   |
| **redeemer\_cbor**        | The CBOR-encoded redeemer data passed to the script.                                | varchar   |
| **redeemer\_data\_hash**  | The hash of the redeemer data.                                                      | varchar   |
| **execution\_mem\_units** | The memory units consumed by the script execution.                                  | bigint    |
| **execution\_cpu\_steps** | The CPU steps consumed by the script execution.                                     | bigint    |
| **\_updated\_at**         | The time when this record was last updated.                                         | timestamp |
| **\_ingested\_at**        | The time when this record was ingested into Dune.                                   | timestamp |

## Table Sample

<TableSample />


# cardano.tx_input
Source: https://docs.dune.com/data-catalog/cardano/tx_input

Description of the tx_input table on Dune

## Table Description

Tracks the consumption of UTXOs on the Cardano blockchain. Each row represents a UTXO being spent, linking the original output (identified by transaction hash and output index) to the transaction and block in which it was consumed.

## Column Descriptions

| **Column**                 | **Description**                                               | **Type**  |
| -------------------------- | ------------------------------------------------------------- | --------- |
| **tx\_hash**               | The hash of the transaction that originally created the UTXO. | varchar   |
| **output\_index**          | The index of the output in the original transaction.          | integer   |
| **spent\_tx\_hash**        | The hash of the transaction that spent this UTXO.             | varchar   |
| **spent\_at\_slot**        | The absolute slot number when this UTXO was spent.            | bigint    |
| **spent\_at\_block**       | The block number in which this UTXO was spent.                | bigint    |
| **spent\_at\_block\_hash** | The hash of the block in which this UTXO was spent.           | varchar   |
| **spent\_block\_time**     | The timestamp of the block in which this UTXO was spent.      | timestamp |
| **spent\_epoch**           | The epoch in which this UTXO was spent.                       | integer   |
| **\_updated\_at**          | The time when this record was last updated.                   | timestamp |
| **\_ingested\_at**         | The time when this record was ingested into Dune.             | timestamp |

## Table Sample

<TableSample />


# dune.neynar.dataset_farcaster_casts
Source: https://docs.dune.com/data-catalog/community/farcaster/casts

Farcaster casts — posts, replies, and threads across the Farcaster social protocol.

## Table description

The `dune.neynar.dataset_farcaster_casts` table contains all casts (posts and replies) on the Farcaster protocol, including text content, embeds, mentions, and threading information.

## Table Schema

| Column Name          | Type             | Description                                                     |
| -------------------- | ---------------- | --------------------------------------------------------------- |
| `id`                 | `BIGINT`         | Auto-incrementing row identifier                                |
| `created_at`         | `TIMESTAMP`      | Timestamp when the record was created in the database           |
| `updated_at`         | `TIMESTAMP`      | Timestamp when the record was last updated in the database      |
| `deleted_at`         | `TIMESTAMP`      | Timestamp when the cast was deleted on the Farcaster protocol   |
| `timestamp`          | `TIMESTAMP`      | Timestamp when the cast was created on the Farcaster protocol   |
| `fid`                | `BIGINT`         | Farcaster user ID of the cast author                            |
| `hash`               | `VARBINARY`      | Unique hash of the cast                                         |
| `parent_hash`        | `VARBINARY`      | Hash of the parent cast (for replies)                           |
| `parent_fid`         | `BIGINT`         | Farcaster user ID of the parent cast author                     |
| `parent_url`         | `VARCHAR`        | Channel URL where the cast was posted (null for direct replies) |
| `text`               | `VARCHAR`        | Text content of the cast                                        |
| `embeds`             | `VARCHAR`        | JSON-encoded attachments (images, links, frames, etc.)          |
| `mentions`           | `ARRAY(BIGINT)`  | Array of Farcaster user IDs mentioned in the cast               |
| `mentions_positions` | `ARRAY(INTEGER)` | Byte positions in the cast text where mentions are placed       |
| `root_parent_hash`   | `VARBINARY`      | Hash of the root cast that started the thread                   |
| `root_parent_url`    | `VARCHAR`        | Channel URL of the root cast in the thread                      |

## Table Sample

<TableSample />


# dune.neynar.dataset_farcaster_fids
Source: https://docs.dune.com/data-catalog/community/farcaster/fids

Farcaster FIDs — unique user identifiers and registration data.

## Table description

The `dune.neynar.dataset_farcaster_fids` table contains all Farcaster user IDs (FIDs) and the custody addresses that own them. Each row represents a registered user on the protocol.

## Table Schema

| Column Name       | Type        | Description                                                |
| ----------------- | ----------- | ---------------------------------------------------------- |
| `fid`             | `BIGINT`    | Unique Farcaster user ID                                   |
| `created_at`      | `TIMESTAMP` | Timestamp when the record was created in the database      |
| `updated_at`      | `TIMESTAMP` | Timestamp when the record was last updated in the database |
| `custody_address` | `VARBINARY` | Wallet address that holds custody of the Farcaster account |
| `registered_at`   | `TIMESTAMP` | Timestamp when the FID was registered on the protocol      |

## Table Sample

<TableSample />


# dune.neynar.dataset_farcaster_fnames
Source: https://docs.dune.com/data-catalog/community/farcaster/fnames

Farcaster usernames — fname registrations and ownership history.

## Table description

The `dune.neynar.dataset_farcaster_fnames` table contains usernames (fnames) associated with Farcaster user IDs. Fnames are human-readable identifiers that can be transferred and expire.

## Table Schema

| Column Name       | Type        | Description                                                    |
| ----------------- | ----------- | -------------------------------------------------------------- |
| `fname`           | `VARCHAR`   | Farcaster username of the user                                 |
| `created_at`      | `TIMESTAMP` | Timestamp when the record was created in the database          |
| `updated_at`      | `TIMESTAMP` | Timestamp when the record was last updated in the database     |
| `custody_address` | `VARBINARY` | Wallet address that holds custody of the Farcaster account     |
| `expires_at`      | `TIMESTAMP` | Timestamp when the username registration expires               |
| `fid`             | `BIGINT`    | Farcaster user ID associated with this username                |
| `deleted_at`      | `TIMESTAMP` | Timestamp when the fname was removed on the Farcaster protocol |

## Table Sample

<TableSample />


# dune.neynar.dataset_farcaster_links
Source: https://docs.dune.com/data-catalog/community/farcaster/links

Farcaster social links — follow/unfollow relationships between users.

## Table description

The `dune.neynar.dataset_farcaster_links` table contains data about follower and following relationships on the Farcaster protocol. Each row represents a social graph link between two users.

## Table Schema

| Column Name         | Type        | Description                                                   |
| ------------------- | ----------- | ------------------------------------------------------------- |
| `id`                | `BIGINT`    | Auto-incrementing row identifier                              |
| `fid`               | `BIGINT`    | Farcaster user ID of the user who created the link            |
| `target_fid`        | `BIGINT`    | Farcaster user ID of the link target                          |
| `hash`              | `VARBINARY` | Unique hash of the link on the protocol                       |
| `timestamp`         | `TIMESTAMP` | Timestamp when the link was created on the Farcaster protocol |
| `created_at`        | `TIMESTAMP` | Timestamp when the record was created in the database         |
| `updated_at`        | `TIMESTAMP` | Timestamp when the record was last updated in the database    |
| `deleted_at`        | `TIMESTAMP` | Timestamp when the link was removed on the Farcaster protocol |
| `type`              | `VARCHAR`   | Link type (e.g. `follow`)                                     |
| `display_timestamp` | `TIMESTAMP` | Display-friendly timestamp for the link event                 |

## Table Sample

<TableSample />


# Farcaster data from Neynar
Source: https://docs.dune.com/data-catalog/community/farcaster/overview

Neynar is the development platform for web3 social protocols. Neynar makes Farcaster protocol data available on Dune.

# Farcaster

[Farcaster](https://farcaster.xyz) - a protocol for decentralized social apps

Neynar is the development platform for web3 social protocols. Neynar makes Farcaster protocol data available on Dune. Check out [neynar.com](https://neynar.com) for Farcaster hubs, APIs or other processed data.

**Website:** [neynar.com](https://neynar.com)

**Docs:** [docs.neynar.com](https://docs.neynar.com)

**Reach the team:** [Telegram](https://t.me/rishdoteth)

## Data available:

<CardGroup>
  <Card title="Casts" icon="comment-alt" href="/data-catalog/community/farcaster/casts">
    All casts on the Farcaster protocol.
  </Card>

  <Card title="FIDs" icon="id-badge" href="/data-catalog/community/farcaster/fids">
    User IDs associated with users on the Farcaster protocol.
  </Card>

  <Card title="Fnames" icon="user" href="/data-catalog/community/farcaster/fnames">
    Usernames for FIDs on the protocol.
  </Card>

  <Card title="Links" icon="link" href="/data-catalog/community/farcaster/links">
    Follower and following graph on Farcaster.
  </Card>

  <Card title="Reactions" icon="thumbs-up" href="/data-catalog/community/farcaster/reactions">
    Likes and recast events on Farcaster.
  </Card>

  <Card title="Signers" icon="signature" href="/data-catalog/community/farcaster/signers">
    Signers for users on Farcaster.
  </Card>

  <Card title="Storage" icon="database" href="/data-catalog/community/farcaster/storage">
    Storage units for Farcaster users.
  </Card>

  <Card title="User Data" icon="address-card" href="/data-catalog/community/farcaster/user_data">
    User information for Farcaster users.
  </Card>

  <Card title="Verifications" icon="check-circle" href="/data-catalog/community/farcaster/verifications">
    Ethereum wallet addresses connected to Farcaster profiles.
  </Card>

  <Card title="Profiles with Addresses" icon="address-book" href="/data-catalog/community/farcaster/profile_with_addresses">
    Farcaster user's profile data and their connected addresses.
  </Card>

  <Card title="Power Badge" icon="crown" href="/data-catalog/community/farcaster/power_badge">
    Warpcast power badge user lists by fid
  </Card>
</CardGroup>


# dune.neynar.dataset_farcaster_warpcast_power_users
Source: https://docs.dune.com/data-catalog/community/farcaster/power_badge

Warpcast power badge holders — users with the verified power badge on Warpcast.

## Table description

The `dune.neynar.dataset_farcaster_warpcast_power_users` table contains all power badge users on Warpcast. Power badges are a Warpcast-specific concept and are NOT stored on the Farcaster protocol itself. The table only contains the current power badge FIDs, not historical data. Read more [about power badges](https://warpcast.notion.site/Power-Badge-d81fea2e953e4dafae7c85295ffaf3ae) and the [power badge API](https://docs.farcaster.xyz/reference/warpcast/api#get-all-power-badge-users).

## Table Schema

| Column Name  | Type        | Description                                                |
| ------------ | ----------- | ---------------------------------------------------------- |
| `created_at` | `TIMESTAMP` | Timestamp when the record was created in the database      |
| `updated_at` | `TIMESTAMP` | Timestamp when the record was last updated in the database |
| `deleted_at` | `TIMESTAMP` | Timestamp when the power badge was removed                 |
| `fid`        | `BIGINT`    | Farcaster user ID of the power badge holder                |

## Table Sample

<TableSample />


# dune.neynar.dataset_farcaster_profile_with_addresses
Source: https://docs.dune.com/data-catalog/community/farcaster/profile_with_addresses

Farcaster profiles with verified addresses — user profiles linked to Ethereum addresses.

## Table description

The `dune.neynar.dataset_farcaster_profile_with_addresses` table contains Farcaster user profile data combined with their connected wallet addresses. It provides a convenient denormalized view for querying user identity alongside on-chain addresses.

## Table Schema

| Column Name          | Type        | Description                                                                  |
| -------------------- | ----------- | ---------------------------------------------------------------------------- |
| `fid`                | `BIGINT`    | Farcaster user ID                                                            |
| `fname`              | `VARCHAR`   | Farcaster username                                                           |
| `display_name`       | `VARCHAR`   | Display name chosen by the user                                              |
| `avatar_url`         | `VARCHAR`   | URL to the user's profile picture                                            |
| `bio`                | `VARCHAR`   | User's profile biography text                                                |
| `verified_addresses` | `VARCHAR`   | JSON-encoded array of verified EVM wallet addresses connected to the profile |
| `updated_at`         | `TIMESTAMP` | Timestamp when the profile data was last updated                             |

## Table Sample

<TableSample />


# dune.neynar.dataset_farcaster_reactions
Source: https://docs.dune.com/data-catalog/community/farcaster/reactions

Farcaster reactions — likes and recasts on posts.

## Table description

The `dune.neynar.dataset_farcaster_reactions` table contains data about likes and recast events on the Farcaster protocol. Each row represents a single reaction by a user to a cast or URL.

## Table Schema

| Column Name     | Type        | Description                                                       |
| --------------- | ----------- | ----------------------------------------------------------------- |
| `id`            | `BIGINT`    | Auto-incrementing row identifier                                  |
| `created_at`    | `TIMESTAMP` | Timestamp when the record was created in the database             |
| `updated_at`    | `TIMESTAMP` | Timestamp when the record was last updated in the database        |
| `deleted_at`    | `TIMESTAMP` | Timestamp when the reaction was removed on the Farcaster protocol |
| `timestamp`     | `TIMESTAMP` | Timestamp when the reaction was created on the Farcaster protocol |
| `reaction_type` | `BIGINT`    | Type of reaction (1 = like, 2 = recast)                           |
| `fid`           | `BIGINT`    | Farcaster user ID of the user who reacted                         |
| `hash`          | `VARBINARY` | Unique hash of the reaction                                       |
| `target_hash`   | `VARBINARY` | Hash of the cast being reacted to                                 |
| `target_fid`    | `BIGINT`    | Farcaster user ID of the author of the target cast                |
| `target_url`    | `VARCHAR`   | URL being reacted to (for URL-targeted reactions)                 |

## Table Sample

<TableSample />


# dune.neynar.dataset_farcaster_signers
Source: https://docs.dune.com/data-catalog/community/farcaster/signers

Farcaster signers — authorized signing keys for user accounts.

## Table description

The `dune.neynar.dataset_farcaster_signers` table contains data about signers associated with users on the Farcaster protocol. Signers are authorized key pairs that can perform actions on behalf of a user.

## Table Schema

| Column Name  | Type        | Description                                                     |
| ------------ | ----------- | --------------------------------------------------------------- |
| `id`         | `BIGINT`    | Auto-incrementing row identifier                                |
| `created_at` | `TIMESTAMP` | Timestamp when the record was created in the database           |
| `updated_at` | `TIMESTAMP` | Timestamp when the record was last updated in the database      |
| `deleted_at` | `TIMESTAMP` | Timestamp when the signer was revoked on the Farcaster protocol |
| `timestamp`  | `TIMESTAMP` | Timestamp when the signer was created on the Farcaster protocol |
| `fid`        | `BIGINT`    | Farcaster user ID that the signer belongs to                    |
| `signer`     | `VARBINARY` | Public key of the authorized signer                             |
| `name`       | `VARCHAR`   | Human-readable name assigned to the signer by the application   |
| `app_fid`    | `BIGINT`    | Farcaster user ID of the application that created the signer    |

## Table Sample

<TableSample />


# dune.neynar.dataset_farcaster_storage
Source: https://docs.dune.com/data-catalog/community/farcaster/storage

Farcaster storage allocations — storage units purchased per user.

## Table description

The `dune.neynar.dataset_farcaster_storage` table contains data about the storage units available for users on the Farcaster protocol. Storage units determine how many casts, reactions, and links a user can create.

## Table Schema

| Column Name  | Type        | Description                                                        |
| ------------ | ----------- | ------------------------------------------------------------------ |
| `id`         | `BIGINT`    | Auto-incrementing row identifier                                   |
| `created_at` | `TIMESTAMP` | Timestamp when the record was created in the database              |
| `updated_at` | `TIMESTAMP` | Timestamp when the record was last updated in the database         |
| `deleted_at` | `TIMESTAMP` | Timestamp when the storage allocation was removed                  |
| `timestamp`  | `TIMESTAMP` | Timestamp when the storage was allocated on the Farcaster protocol |
| `fid`        | `BIGINT`    | Farcaster user ID of the storage owner                             |
| `units`      | `BIGINT`    | Number of storage units allocated to the user                      |
| `expiry`     | `TIMESTAMP` | Timestamp when the storage allocation expires                      |

## Table Sample

<TableSample />


# dune.neynar.dataset_farcaster_user_data
Source: https://docs.dune.com/data-catalog/community/farcaster/user_data

Farcaster user data — profile fields like bio, display name, and avatar.

## Table description

The `dune.neynar.dataset_farcaster_user_data` table contains user profile data on the Farcaster protocol. Each row represents a single key-value pair of user information, such as display name, bio, or avatar URL. Join with the fids or fnames table for complete user profiles.

## Table Schema

| Column Name  | Type        | Description                                                                              |
| ------------ | ----------- | ---------------------------------------------------------------------------------------- |
| `id`         | `BIGINT`    | Auto-incrementing row identifier                                                         |
| `created_at` | `TIMESTAMP` | Timestamp when the record was created in the database                                    |
| `updated_at` | `TIMESTAMP` | Timestamp when the record was last updated in the database                               |
| `deleted_at` | `TIMESTAMP` | Timestamp when the data was removed on the Farcaster protocol                            |
| `timestamp`  | `TIMESTAMP` | Timestamp when the data was set on the Farcaster protocol                                |
| `fid`        | `BIGINT`    | Farcaster user ID the data belongs to                                                    |
| `hash`       | `VARBINARY` | Unique hash of the user data message                                                     |
| `type`       | `BIGINT`    | Type of user data (1 = pfp URL, 2 = display name, 3 = bio, 5 = URL, 6 = preferred fname) |
| `value`      | `VARCHAR`   | The value of the user data field                                                         |

## Table Sample

<TableSample />


# dune.neynar.dataset_farcaster_verifications
Source: https://docs.dune.com/data-catalog/community/farcaster/verifications

Farcaster address verifications — Ethereum addresses verified by Farcaster users.

## Table description

The `dune.neynar.dataset_farcaster_verifications` table contains data about wallet address verifications connected to Farcaster profiles. Users verify ownership of Ethereum and other addresses to link their on-chain identity with their Farcaster account.

## Table Schema

| Column Name  | Type        | Description                                                               |
| ------------ | ----------- | ------------------------------------------------------------------------- |
| `id`         | `BIGINT`    | Auto-incrementing row identifier                                          |
| `created_at` | `TIMESTAMP` | Timestamp when the record was created in the database                     |
| `updated_at` | `TIMESTAMP` | Timestamp when the record was last updated in the database                |
| `deleted_at` | `TIMESTAMP` | Timestamp when the verification was removed on the Farcaster protocol     |
| `timestamp`  | `TIMESTAMP` | Timestamp when the verification was created on the Farcaster protocol     |
| `fid`        | `BIGINT`    | Farcaster user ID of the profile owner                                    |
| `hash`       | `VARBINARY` | Unique hash of the verification message                                   |
| `claim`      | `VARCHAR`   | JSON-encoded verified wallet address and cryptographic proof of ownership |

## Table Sample

<TableSample />


# dune.flashbots.dataset_mempool_dumpster
Source: https://docs.dune.com/data-catalog/community/flashbots/mempool-dumpster

Flashbots mempool data — pending transactions captured from the public mempool.

## Table description

The `dune.flashbots.dataset_mempool_dumpster` table captures detailed transaction data from the Ethereum mempool. It includes transactions that might attempt to extract value through reordering, sandwiching, or other MEV strategies.

## Column descriptions

| Column Name                   | Description                                                                                            | Data Type |
| ----------------------------- | ------------------------------------------------------------------------------------------------------ | --------- |
| `to`                          | The recipient address of the transaction.                                                              | varchar   |
| `from`                        | The sender address of the transaction.                                                                 | varchar   |
| `hash`                        | The unique transaction hash.                                                                           | varchar   |
| `nonce`                       | The nonce of the transaction, a counter of the sender's transactions.                                  | Integer   |
| `value`                       | The value transferred in the transaction, in wei.                                                      | BigInt    |
| `gas`                         | The gas limit set for the transaction.                                                                 | Integer   |
| `gas_price`                   | The gas price set for the transaction, in wei.                                                         | BigInt    |
| `data_size`                   | The size of the data payload in the transaction, in bytes.                                             | Integer   |
| `data_4bytes`                 | The first four bytes of the transaction data, typically the method identifier in a contract call.      | varchar   |
| `sources`                     | The sources that captured the transaction data.                                                        | varchar   |
| `chain_id`                    | The identifier for the blockchain network (e.g., 1 for Ethereum Mainnet).                              | Integer   |
| `gas_fee_cap`                 | The maximum amount of gas fee the sender is willing to pay (EIP-1559).                                 | BigInt    |
| `gas_tip_cap`                 | The maximum tip the sender is willing to pay miners (EIP-1559).                                        | BigInt    |
| `timestamp_ms`                | The timestamp when the transaction was first seen, in milliseconds.                                    | BigInt    |
| `inclusion_delay_ms`          | The delay in milliseconds from when the transaction was first seen to when it was included in a block. | Integer   |
| `included_at_block_height`    | The block height at which the transaction was included.                                                | Integer   |
| `included_block_timestamp_ms` | The timestamp of the block at which the transaction was included, in milliseconds.                     | BigInt    |

## Table Sample

<TableSample />


# Flashbots Data
Source: https://docs.dune.com/data-catalog/community/flashbots/overview

Flashbots data on Dune

# Flashbots

[Flashbots](https://flashbots.net) - a research and development organization focusing on minimizing the negative externalities and risks of MEV (Maximal Extractable Value) in the blockchain ecosystem.

Flashbots is dedicated to advancing transparent and fair blockchain protocols, specifically addressing issues related to MEV to protect ecosystem integrity.

**Website** : [https://flashbots.net](https://flashbots.net)

**Documentation** : [https://docs.flashbots.net](https://docs.flashbots.net)

## Data available:

<CardGroup>
  <Card title="Mempool Dumpster Dataset" icon="database" href="/data-catalog/community/flashbots/mempool-dumpster">
    Comprehensive dataset providing insights into mempool transactions captured by Flashbots, focusing on MEV strategies and transactions.
  </Card>
</CardGroup>


# hyperliquid.market_data
Source: https://docs.dune.com/data-catalog/community/hyperliquid/market-data

Hyperliquid market data — order book snapshots, funding rates, open interest, and trade history.

## Table description

The `hyperliquid.market_data` table contains historical trading data from the Hyperliquid decentralized exchange. The data includes trading volume, open interest, funding rates, and other market metrics across all perpetual futures markets on the platform. The data is updated monthly.

## Table Schema

| Column Name     | Type      | Description                                             |
| --------------- | --------- | ------------------------------------------------------- |
| time            | timestamp | Timestamp of the market data snapshot                   |
| coin            | varchar   | Ticker symbol of the perpetual futures asset            |
| funding         | double    | Current funding rate for the perpetual contract         |
| open\_interest  | double    | Total open interest in the asset                        |
| prev\_day\_px   | double    | Closing price from the previous day                     |
| day\_ntl\_vlm   | double    | Notional trading volume over the day                    |
| premium         | double    | Premium of the perpetual price over the oracle price    |
| oracle\_px      | double    | Oracle (spot index) price of the asset                  |
| mark\_px        | double    | Mark price used for margin and liquidation calculations |
| mid\_px         | double    | Mid-point price between best bid and best ask           |
| impact\_bid\_px | double    | Bid-side price adjusted for a standard impact notional  |
| impact\_ask\_px | double    | Ask-side price adjusted for a standard impact notional  |

## Table Sample

<TableSample />


# Hyperliquid data
Source: https://docs.dune.com/data-catalog/community/hyperliquid/overview

Hyperliquid data on Dune

# Hyperliquid

[Hyperliquid](https://hyperliquid.xyz) is a high-performance decentralized perpetual futures exchange built on a custom L1 blockchain.

Hyperliquid is a decentralized exchange designed for perpetual futures trading with deep liquidity and low latency. The platform operates on its own Layer 1 blockchain, optimized for trading performance and features an on-chain order book with sub-second block times.

**Website** : [https://hyperliquid.xyz](https://hyperliquid.xyz)

**Documentation** : [https://hyperliquid.gitbook.io](https://hyperliquid.gitbook.io)

**Twitter** : [https://twitter.com/HyperliquidX](https://twitter.com/HyperliquidX)

## Data available:

<CardGroup>
  <Card title="Market Data" icon="chart-line" href="/data-catalog/community/hyperliquid/market-data">
    Historical trading data including volume, open interest, funding rates and more. Updated monthly.
  </Card>
</CardGroup>


# dune.lens.namespace_handle
Source: https://docs.dune.com/data-catalog/community/lens/namespace-handle

Lens Protocol handles — registered usernames in the Lens namespace.

<Warning>
  **Deprecation Notice**: Lens data ingestion has been discontinued as of December 2025. Only historical data is available, and no new data will be added.
</Warning>

## Table description

The `dune.lens.namespace_handle` table holds the handle information. Note that handles and profiles are 2 different NFTs. A handle has its own ID.

## Table Schema

| Column Name      | Type      | Description                                            |
| ---------------- | --------- | ------------------------------------------------------ |
| tld              | varchar   | Top-level domain of the handle namespace (e.g. `lens`) |
| local\_name      | varchar   | The local portion of the handle (the username part)    |
| handle\_id       | varbinary | Unique identifier for the handle NFT                   |
| handle           | varchar   | Full handle string (e.g. `lens/alice`)                 |
| owned\_by        | varbinary | Wallet address that currently owns the handle          |
| tx\_hash         | varbinary | Transaction hash of the handle creation or transfer    |
| block\_hash      | varbinary | Hash of the block containing the transaction           |
| block\_number    | integer   | Block number of the transaction                        |
| log\_index       | integer   | Index of the event log within the transaction          |
| tx\_index        | integer   | Index of the transaction within the block              |
| block\_timestamp | timestamp | Timestamp of the block                                 |

## Table Sample

<TableSample />


# dune.lens.namespace_handle_link
Source: https://docs.dune.com/data-catalog/community/lens/namespace-handle-link

Lens handle-to-profile links — mappings between handles and profile NFTs.

<Warning>
  **Deprecation Notice**: Lens data ingestion has been discontinued as of December 2025. Only historical data is available, and no new data will be added.
</Warning>

## Table description

The `dune.lens.namespace_handle_link` table you link your handle to your profile and this holds the reference of the link.

## Table Schema

| Column Name           | Type      | Description                                         |
| --------------------- | --------- | --------------------------------------------------- |
| tld                   | varchar   | Top-level domain of the handle namespace            |
| handle\_id            | varbinary | Unique identifier of the handle NFT being linked    |
| token\_id             | varbinary | Token ID of the profile NFT the handle is linked to |
| collection            | varbinary | Contract address of the profile NFT collection      |
| transaction\_executor | varbinary | Address that executed the link transaction          |
| tx\_hash              | varbinary | Transaction hash of the link event                  |
| block\_hash           | varbinary | Hash of the block containing the transaction        |
| block\_number         | integer   | Block number of the transaction                     |
| log\_index            | integer   | Index of the event log within the transaction       |
| tx\_index             | integer   | Index of the transaction within the block           |
| block\_timestamp      | timestamp | Timestamp of the block                              |

## Table Sample

<TableSample />


# Lens data
Source: https://docs.dune.com/data-catalog/community/lens/overview

Lens.xyz data on Dune

<Warning>
  **Deprecation Notice**: Lens data ingestion has been discontinued as of December 2025. Only historical data is available, and no new data will be added.
</Warning>

# Lens Protocol

[Lens Protocol](https://lens.xyz) - a composable and decentralized social graph ready for new connections.

Lens is a decentralized social graph that allows users to own their data and control their social connections. The protocol is designed to be composable, allowing developers to build new social applications on top of the Lens network.

**Website** : [https://lens.xyz](https://lens.xyz)

**Documentation** : [https://docs.lens.xyz](https://docs.lens.xyz)

**Twitter** : [https://twitter.com/lensprotocol](https://twitter.com/lensprotocol)

## Data available:

<CardGroup>
  <Card title="Overview" icon="eye" href="/data-catalog/community/lens/overview">
    An overview of the Lens protocol data.
  </Card>

  <Card title="Namespace Handle" icon="key" href="/data-catalog/community/lens/namespace-handle">
    Information about handle NFTs and how they are linked to Lens profiles.
  </Card>

  <Card title="Namespace Handle Link" icon="link" href="/data-catalog/community/lens/namespace-handle-link">
    References between users' handles and their profiles in the Lens protocol.
  </Card>

  <Card title="Profile Follower" icon="users" href="/data-catalog/community/lens/profile-follower">
    Data showing the follower relationships between users within the Lens ecosystem.
  </Card>

  <Card title="Profile Follow Module" icon="rss" href="/data-catalog/community/lens/profile-follow-module">
    Details on follow modules that users have engaged with on Lens.
  </Card>

  <Card title="Profile Follow Module Record" icon="record-vinyl" href="/data-catalog/community/lens/profile-follow-module-record">
    Tracking of follow modules that have been claimed or redeemed within the Lens network.
  </Card>

  <Card title="Profile Metadata" icon="id-card-alt" href="/data-catalog/community/lens/profile-metadata">
    Metadata associated with user profiles, including compliance with Lens standards.
  </Card>

  <Card title="Profile Record" icon="address-book" href="/data-catalog/community/lens/profile-record">
    Base profile information and how it integrates within the broader Lens protocol.
  </Card>

  <Card title="Publication Metadata" icon="book-open" href="/data-catalog/community/lens/publication-metadata">
    Content and metadata related to user publications on Lens.
  </Card>

  <Card title="Publication Open Action Module" icon="cogs" href="/data-catalog/community/lens/publication-open-action-module">
    Open action modules that are available for user publications on Lens.
  </Card>

  <Card title="Publication Open Action Module Acted Recorded" icon="check-double" href="/data-catalog/community/lens/publication-open-action-module-acted-recorded">
    Records of user interactions with publications, such as likes and comments on Lens.
  </Card>

  <Card title="Publication Open Action Module Multi-Recipient" icon="users-cog" href="/data-catalog/community/lens/publication-open-action-module-acted-multirecipient">
    Information on multi-recipient payout modules linked to user actions on Lens.
  </Card>

  <Card title="Publication Reaction" icon="thumbs-up" href="/data-catalog/community/lens/publication-reaction">
    Records of user reactions to content within the Lens ecosystem, like upvotes or downvotes.
  </Card>

  <Card title="Publication Record" icon="archive" href="/data-catalog/community/lens/publication-record">
    Database of successful publications that meet the Lens protocol's metadata standards.
  </Card>

  <Card title="Publication Reference Module" icon="project-diagram" href="/data-catalog/community/lens/publication-reference-module">
    Reference modules used to cite or link within publications on Lens.
  </Card>
</CardGroup>


# dune.lens.profile_follow_module
Source: https://docs.dune.com/data-catalog/community/lens/profile-follow-module

Lens follow modules — follow conditions and configurations per profile.

<Warning>
  **Deprecation Notice**: Lens data ingestion has been discontinued as of December 2025. Only historical data is available, and no new data will be added.
</Warning>

## Table description

The `dune.lens.profile_follow_module` table holds any follow module the profile has turned on.

## Table Schema

| Column Name           | Type      | Description                                          |
| --------------------- | --------- | ---------------------------------------------------- |
| profile\_id           | varbinary | Profile ID that has the follow module enabled        |
| implementation        | varbinary | Contract address of the follow module implementation |
| init\_data            | varbinary | Encoded initialization data passed to the module     |
| amount                | varchar   | Payment amount required to follow (if fee-based)     |
| currency              | varbinary | Token contract address for the follow fee currency   |
| recipient             | varbinary | Address that receives follow fee payments            |
| block\_timestamp      | timestamp | Timestamp of the block                               |
| block\_hash           | varbinary | Hash of the block containing the transaction         |
| tx\_hash              | varbinary | Transaction hash of the module setup                 |
| log\_index            | integer   | Index of the event log within the transaction        |
| tx\_index             | integer   | Index of the transaction within the block            |
| block\_number         | integer   | Block number of the transaction                      |
| transaction\_executor | varbinary | Address that executed the module setup transaction   |
| init\_return\_data    | varchar   | Data returned by the module after initialization     |

## Table Sample

<TableSample />


# dune.lens.profile_follow_module_record
Source: https://docs.dune.com/data-catalog/community/lens/profile-follow-module-record

Lens follow module events — follow module activation and update records.

<Warning>
  **Deprecation Notice**: Lens data ingestion has been discontinued as of December 2025. Only historical data is available, and no new data will be added.
</Warning>

## Table description

The `dune.lens.profile_follow_module_record` table holds any follow module which has been redeemed by another profile i.e. 0x01 pays to follow 0x02.

## Table Schema

| Column Name                           | Type          | Description                                                           |
| ------------------------------------- | ------------- | --------------------------------------------------------------------- |
| history\_id                           | integer       | Auto-incrementing record identifier                                   |
| followed                              | varbinary     | Profile ID of the user being followed                                 |
| follower                              | varbinary     | Profile ID of the follower who redeemed the module                    |
| follow\_module\_data                  | varchar       | Encoded data sent to the follow module during redemption              |
| process\_follow\_module\_return\_data | varchar       | Data returned by the module after processing the follow               |
| fiat\_price\_snapshot                 | decimal(10,2) | Fiat price snapshot at the time of the follow (for fee-based modules) |
| transaction\_executor                 | varbinary     | Address that executed the follow transaction                          |
| tx\_hash                              | varbinary     | Transaction hash of the follow                                        |
| block\_hash                           | varbinary     | Hash of the block containing the transaction                          |
| block\_number                         | integer       | Block number of the transaction                                       |
| log\_index                            | integer       | Index of the event log within the transaction                         |
| tx\_index                             | integer       | Index of the transaction within the block                             |
| block\_timestamp                      | timestamp     | Timestamp of the block                                                |

## Table Sample

<TableSample />


# dune.lens.profile_follower
Source: https://docs.dune.com/data-catalog/community/lens/profile-follower

Lens follower relationships — who follows whom on the Lens Protocol.

<Warning>
  **Deprecation Notice**: Lens data ingestion has been discontinued as of December 2025. Only historical data is available, and no new data will be added.
</Warning>

## Table description

The `dune.lens.profile_follower` table holds information about who follows whom.

## Table Schema

| Column Name                    | Type      | Description                                                                       |
| ------------------------------ | --------- | --------------------------------------------------------------------------------- |
| profile\_id                    | varbinary | Profile ID of the user being followed                                             |
| profile\_follower\_id          | varbinary | Profile ID of the follower                                                        |
| follow\_token\_id              | varbinary | Token ID of the follow NFT issued to the follower                                 |
| transaction\_executor          | varbinary | Address that executed the follow transaction                                      |
| tx\_hash                       | varbinary | Transaction hash of the follow event                                              |
| block\_hash                    | varbinary | Hash of the block containing the transaction                                      |
| block\_number                  | integer   | Block number of the transaction                                                   |
| log\_index                     | integer   | Index of the event log within the transaction                                     |
| tx\_index                      | integer   | Index of the transaction within the block                                         |
| block\_timestamp               | timestamp | Timestamp of the block                                                            |
| migration\_optimistic\_applied | boolean   | Whether the follow was optimistically applied during migration from Lens v1 to v2 |

## Table Sample

<TableSample />


# dune.lens.profile_metadata
Source: https://docs.dune.com/data-catalog/community/lens/profile-metadata

Lens profile metadata — display names, bios, avatars, and profile attributes.

<Warning>
  **Deprecation Notice**: Lens data ingestion has been discontinued as of December 2025. Only historical data is available, and no new data will be added.
</Warning>

## Table description

The `dune.lens.profile_metadata` table holds the profile metadata. If it does not pass metadata standards, it goes into the metadata\_failed table. This holds stuff like name, bio, etc.

## Table Schema

| Column Name                               | Type      | Description                                           |
| ----------------------------------------- | --------- | ----------------------------------------------------- |
| id                                        | integer   | Auto-incrementing row identifier                      |
| profile\_id                               | varbinary | Unique identifier of the Lens profile                 |
| name                                      | varchar   | Display name set by the profile owner                 |
| bio                                       | varchar   | Profile biography text                                |
| app                                       | varchar   | Application used to set the metadata                  |
| metadata\_json                            | varchar   | Raw JSON of the profile metadata                      |
| metadata\_version                         | varchar   | Version of the metadata standard used                 |
| metadata\_uri                             | varchar   | URI pointing to the metadata resource                 |
| metadata\_snapshot\_location\_url         | varchar   | Snapshot storage URL for the metadata                 |
| profile\_with\_weights                    | varchar   | Profile scoring or weighting data                     |
| profile\_picture\_snapshot\_location\_url | varchar   | Snapshot storage URL for the profile picture          |
| cover\_picture\_snapshot\_location\_url   | varchar   | Snapshot storage URL for the cover picture            |
| transaction\_executor                     | varbinary | Address that executed the metadata update transaction |
| tx\_hash                                  | varbinary | Transaction hash of the metadata update               |
| block\_hash                               | varbinary | Hash of the block containing the transaction          |
| block\_number                             | integer   | Block number of the transaction                       |
| log\_index                                | integer   | Index of the event log within the transaction         |
| tx\_index                                 | integer   | Index of the transaction within the block             |
| block\_timestamp                          | timestamp | Timestamp of the block                                |

## Table Sample

<TableSample />


# dune.lens.profile_record
Source: https://docs.dune.com/data-catalog/community/lens/profile-record

Lens profile records — profile creation and ownership data.

<Warning>
  **Deprecation Notice**: Lens data ingestion has been discontinued as of December 2025. Only historical data is available, and no new data will be added.
</Warning>

## Table description

The `dune.lens.profile_record` table holds the base profile information; this does not hold the handle, as that is a different table.

## Table Schema

| Column Name      | Type      | Description                                    |
| ---------------- | --------- | ---------------------------------------------- |
| profile\_id      | varbinary | Unique identifier of the Lens profile NFT      |
| owned\_by        | varbinary | Wallet address that currently owns the profile |
| is\_burnt        | boolean   | Whether the profile NFT has been burned        |
| tx\_hash         | varbinary | Transaction hash of the profile creation       |
| block\_hash      | varbinary | Hash of the block containing the transaction   |
| block\_number    | integer   | Block number of the transaction                |
| log\_index       | integer   | Index of the event log within the transaction  |
| tx\_index        | integer   | Index of the transaction within the block      |
| block\_timestamp | timestamp | Timestamp of the block                         |

## Table Sample

<TableSample />


# dune.lens.publication_metadata
Source: https://docs.dune.com/data-catalog/community/lens/publication-metadata

Lens publication metadata — content type, tags, and media attachments for posts.

<Warning>
  **Deprecation Notice**: Lens data ingestion has been discontinued as of December 2025. Only historical data is available, and no new data will be added.
</Warning>

## Table description

The `dune.lens.publication_metadata` table holds the publication content/metadata.

## Table Schema

| Column Name                       | Type      | Description                                                          |
| --------------------------------- | --------- | -------------------------------------------------------------------- |
| publication\_id                   | varchar   | Unique identifier of the publication (format: `profileId-pubId`)     |
| metadata\_snapshot\_location\_url | varchar   | Snapshot storage URL for the metadata                                |
| metadata\_json                    | varchar   | Raw JSON of the publication metadata                                 |
| metadata\_version                 | varchar   | Version of the metadata standard used                                |
| content                           | varchar   | Text content of the publication                                      |
| language                          | varchar   | Language code of the publication content                             |
| region                            | varchar   | Regional locale of the publication                                   |
| content\_warning                  | varchar   | Content warning label if applicable (e.g. `NSFW`, `SENSITIVE`)       |
| main\_content\_focus              | varchar   | Primary content type (e.g. `TEXT_ONLY`, `IMAGE`, `VIDEO`, `ARTICLE`) |
| tags\_vector                      | varchar   | Serialized array of tags associated with the publication             |
| hide\_from\_feed                  | boolean   | Whether the publication should be hidden from feeds                  |
| is\_encrypted                     | boolean   | Whether the publication content is gated/encrypted                   |
| app                               | varchar   | Application used to create the publication                           |
| tx\_hash                          | varbinary | Transaction hash (null for Momoka publications)                      |
| timestamp                         | timestamp | Timestamp of the publication creation                                |
| created\_at                       | timestamp | Timestamp when the record was created in the database                |
| content\_vector                   | varchar   | Vector embedding of the content for similarity searches              |

## Table Sample

<TableSample />


# dune.lens.publication_open_action_module
Source: https://docs.dune.com/data-catalog/community/lens/publication-open-action-module

Lens open action modules — collect, tip, and custom action configurations on publications.

<Warning>
  **Deprecation Notice**: Lens data ingestion has been discontinued as of December 2025. Only historical data is available, and no new data will be added.
</Warning>

## Table description

The `dune.lens.publication_open_action_module` table holds the modules which have been attached to a publication.

## Table Schema

| Column Name        | Type      | Description                                                          |
| ------------------ | --------- | -------------------------------------------------------------------- |
| publication\_id    | varchar   | Publication ID the module is attached to (format: `profileId-pubId`) |
| id                 | varchar   | Unique identifier for this module instance                           |
| implementation     | varbinary | Contract address of the open action module                           |
| init\_data         | varbinary | Encoded initialization data passed to the module                     |
| init\_return\_data | varbinary | Data returned by the module after initialization                     |
| collect\_limit     | varchar   | Maximum number of collects allowed (null if unlimited)               |
| amount             | varchar   | Payment amount required to act on the publication                    |
| follower\_only     | boolean   | Whether the action is restricted to followers                        |
| currency           | varbinary | Token contract address for the payment currency                      |
| recipient          | varbinary | Address that receives payments                                       |
| referral\_fee      | varchar   | Percentage fee paid to referrers                                     |
| end\_timestamp     | timestamp | Deadline after which the action is no longer available               |
| vault              | varchar   | Vault address for revenue distribution (if applicable)               |
| tx\_hash           | varbinary | Transaction hash of the module setup                                 |
| block\_hash        | varbinary | Hash of the block containing the transaction                         |
| block\_number      | integer   | Block number of the transaction                                      |
| log\_index         | integer   | Index of the event log within the transaction                        |
| tx\_index          | integer   | Index of the transaction within the block                            |
| block\_timestamp   | timestamp | Timestamp of the block                                               |

## Table Sample

<TableSample />


# dune.lens.publication_open_action_module_multirecipient
Source: https://docs.dune.com/data-catalog/community/lens/publication-open-action-module-acted-multirecipient

Lens multi-recipient action modules — revenue split configurations for publication actions.

<Warning>
  **Deprecation Notice**: Lens data ingestion has been discontinued as of December 2025. Only historical data is available, and no new data will be added.
</Warning>

## Table description

The `dune.lens.publication_open_action_module_multirecipient` table holds a line for each recipient who gets paid out by the multi-recipient module.

## Table Schema

| Column Name      | Type         | Description                                                      |
| ---------------- | ------------ | ---------------------------------------------------------------- |
| id               | integer      | Auto-incrementing row identifier                                 |
| open\_module\_id | varchar      | Reference to the parent open action module instance              |
| publication\_id  | varchar      | Publication ID the module belongs to (format: `profileId-pubId`) |
| recipient        | varbinary    | Wallet address of this recipient                                 |
| split            | decimal(5,2) | Percentage share of revenue allocated to this recipient          |
| index            | integer      | Position index of the recipient in the split list                |

## Table Sample

<TableSample />


# dune.lens.publication_open_action_module_acted_record
Source: https://docs.dune.com/data-catalog/community/lens/publication-open-action-module-acted-recorded

Lens open action events — records of users executing actions on publications.

<Warning>
  **Deprecation Notice**: Lens data ingestion has been discontinued as of December 2025. Only historical data is available, and no new data will be added.
</Warning>

## Table description

The `dune.lens.publication_open_action_module_acted_record` table holds which profiles have acted on that publication (collects are a part of an action).

## Table Schema

| Column Name           | Type          | Description                                                  |
| --------------------- | ------------- | ------------------------------------------------------------ |
| history\_id           | integer       | Auto-incrementing record identifier                          |
| record\_id            | integer       | Reference to the open action module record                   |
| publication\_id       | varchar       | Publication ID that was acted on (format: `profileId-pubId`) |
| acted\_profile\_id    | varbinary     | Profile ID of the user who performed the action              |
| implementation        | varbinary     | Contract address of the open action module                   |
| init\_return\_data    | varbinary     | Data returned by the module after processing the action      |
| fiat\_price\_snapshot | decimal(10,2) | Fiat price snapshot at the time of the action                |
| is\_collect           | boolean       | Whether this action was specifically a collect               |
| transaction\_executor | varbinary     | Address that executed the action transaction                 |
| tx\_hash              | varbinary     | Transaction hash of the action                               |
| block\_hash           | varbinary     | Hash of the block containing the transaction                 |
| block\_number         | integer       | Block number of the transaction                              |
| log\_index            | integer       | Index of the event log within the transaction                |
| tx\_index             | integer       | Index of the transaction within the block                    |
| block\_timestamp      | timestamp     | Timestamp of the block                                       |

## Table Sample

<TableSample />


# dune.lens.publication_reaction
Source: https://docs.dune.com/data-catalog/community/lens/publication-reaction

Lens reactions — likes, mirrors, and other reactions on publications.

<Warning>
  **Deprecation Notice**: Lens data ingestion has been discontinued as of December 2025. Only historical data is available, and no new data will be added.
</Warning>

## Table description

The `dune.lens.publication_reaction` table holds the reaction type and who reacted.

## Table Schema

| Column Name               | Type      | Description                                                    |
| ------------------------- | --------- | -------------------------------------------------------------- |
| publication\_id           | varchar   | Publication ID that was reacted to (format: `profileId-pubId`) |
| actioned\_by\_profile\_id | varbinary | Profile ID of the user who reacted                             |
| type                      | varchar   | Type of reaction (e.g. `UPVOTE`, `DOWNVOTE`)                   |
| action\_at                | timestamp | Timestamp when the reaction was created                        |
| app                       | varchar   | Application used to create the reaction                        |

## Table Sample

<TableSample />


# dune.lens.publication_record
Source: https://docs.dune.com/data-catalog/community/lens/publication-record

Lens publication records — posts, comments, and mirrors with content references.

<Warning>
  **Deprecation Notice**: Lens data ingestion has been discontinued as of December 2025. Only historical data is available, and no new data will be added.
</Warning>

## Table description

The `dune.lens.publication_record` table holds all the SUCCESSFUL publication records, including Momoka publications; it also has a MIRROR|QUOTE|COMMENT|POST publication type, but the rest of the columns should explain itself. The definition of success to us is if it follows the metadata standard.

## Table Schema

| Column Name                     | Type      | Description                                                        |
| ------------------------------- | --------- | ------------------------------------------------------------------ |
| publication\_id                 | varchar   | Unique publication identifier (format: `profileId-pubId`)          |
| contract\_publication\_id       | varbinary | On-chain publication ID from the Lens Hub contract                 |
| publication\_type               | varchar   | Type of publication: `POST`, `COMMENT`, `MIRROR`, or `QUOTE`       |
| profile\_id                     | varbinary | Profile ID of the publication author                               |
| content\_uri                    | varchar   | URI pointing to the publication content/metadata                   |
| parent\_publication\_id         | varchar   | Publication ID of the parent (for comments, quotes, mirrors)       |
| root\_publication\_id           | varchar   | Publication ID of the root post in the thread                      |
| is\_hidden                      | boolean   | Whether the publication has been hidden                            |
| is\_momoka                      | boolean   | Whether the publication was posted via Momoka (off-chain DA layer) |
| momoka\_proof                   | varchar   | Momoka data availability proof (null for on-chain publications)    |
| app                             | varchar   | Application used to create the publication                         |
| gardener\_flagged               | boolean   | Whether the publication was flagged by a gardener for moderation   |
| transaction\_executor           | varbinary | Address that executed the publication transaction                  |
| tx\_hash                        | varbinary | Transaction hash (null for Momoka publications)                    |
| block\_hash                     | varbinary | Hash of the block containing the transaction                       |
| block\_number                   | integer   | Block number of the transaction                                    |
| log\_index                      | integer   | Index of the event log within the transaction                      |
| tx\_index                       | integer   | Index of the transaction within the block                          |
| block\_timestamp                | timestamp | Timestamp of the block                                             |
| is\_comment\_hidden\_by\_author | boolean   | Whether a comment was hidden by the original post author           |

## Table Sample

<TableSample />


# dune.lens.publication_reference_module
Source: https://docs.dune.com/data-catalog/community/lens/publication-reference-module

Lens reference modules — comment and mirror permission configurations.

<Warning>
  **Deprecation Notice**: Lens data ingestion has been discontinued as of December 2025. Only historical data is available, and no new data will be added.
</Warning>

## Table description

The `dune.lens.publication_reference_module` table holds any reference modules that have been attached to a publication.

## Table Schema

| Column Name             | Type      | Description                                                          |
| ----------------------- | --------- | -------------------------------------------------------------------- |
| publication\_id         | varchar   | Publication ID the module is attached to (format: `profileId-pubId`) |
| implementation          | varbinary | Contract address of the reference module                             |
| init\_data              | varbinary | Encoded initialization data passed to the module                     |
| comments\_restricted    | boolean   | Whether commenting is restricted by this module                      |
| mirrors\_restricted     | boolean   | Whether mirroring is restricted by this module                       |
| degrees\_of\_separation | integer   | Maximum degrees of separation allowed for interaction                |
| block\_timestamp        | timestamp | Timestamp of the block                                               |
| block\_hash             | varbinary | Hash of the block containing the transaction                         |
| quotes\_restricted      | boolean   | Whether quoting is restricted by this module                         |
| source\_profile\_id     | varbinary | Profile ID from which degrees of separation are measured             |
| followers\_only         | boolean   | Whether interactions are limited to followers only                   |
| init\_return\_data      | varbinary | Data returned by the module after initialization                     |
| tx\_hash                | varbinary | Transaction hash of the module setup                                 |
| log\_index              | integer   | Index of the event log within the transaction                        |
| tx\_index               | integer   | Index of the transaction within the block                            |
| block\_number           | integer   | Block number of the transaction                                      |

## Table Sample

<TableSample />


# Ask Events
Source: https://docs.dune.com/data-catalog/community/reservoir/ask-events



## **reservoir.ask\_events**

This table contains records with information about each ask change.

Query examples can be found here:

[https://dune.com/queries/1302858/2232178](https://dune.com/queries/1302858/2232178)

[https://dune.com/queries/1302863/2232189](https://dune.com/queries/1302863/2232189)

| **Column name**     | **Type**  | **Description**                                                                                                 |
| ------------------- | --------- | --------------------------------------------------------------------------------------------------------------- |
| id                  | bigint    | Internal event id                                                                                               |
| kind                | string    | Event type (new-order, expiry, sale, cancel, balance-change, approval-change, bootstrap, revalidation, reprice) |
| contract            | string    | Contract address                                                                                                |
| token\_id           | string    | Id of the token in the collection                                                                               |
| order\_id           | string    | Associated ask id                                                                                               |
| maker               | string    | Associated ask maker wallet address                                                                             |
| price               | decimal   | Associated ask price (native currency)                                                                          |
| quantity\_remaining | bigint    | Associated ask tokens remaining                                                                                 |
| valid\_from         | bigint    | Associated ask validity start                                                                                   |
| valid\_until        | bigint    | Associated ask validity expiration                                                                              |
| source              | string    | Source of the order (e.g. opensea.io)                                                                           |
| tx\_hash            | string    | Associated transaction hash                                                                                     |
| tx\_timestamp       | bigint    | Associated transaction timestamp                                                                                |
| created\_at         | timestamp | Timestamp the event was recorded                                                                                |


# Asks
Source: https://docs.dune.com/data-catalog/community/reservoir/asks



## **reservoir.asks**

This table contains records with information about each listing.

Query examples can be found here:

[https://dune.com/queries/1302885/2232229](https://dune.com/queries/1302885/2232229)

[https://dune.com/queries/1302904/2232257](https://dune.com/queries/1302904/2232257)

| **Column name**     | **Type**  | **Description**                              |
| ------------------- | --------- | -------------------------------------------- |
| id                  | string    | Internal order id                            |
| kind                | string    | Protocol name (e.g. seaport)                 |
| status              | string    | Order status (active, inactive)              |
| contract            | string    | Contract address                             |
| token\_id           | string    | Id of the token in the collection            |
| maker               | string    | Maker wallet address                         |
| taker               | string    | Taker wallet address                         |
| price               | decimal   | The current price (native currency)          |
| start\_price        | bigint    | Start Listing price (for dutch auctions)     |
| end\_price          | bigint    | End Listing price (for dutch auctions)       |
| currency\_address   | string    | Currency address                             |
| currency\_symbol    | string    | Currency symbol                              |
| currency\_price     | decimal   | Currency price                               |
| dynamic             | boolean   | Is dutch auction?                            |
| quantity            | bigint    | Amount of tokens that is listed              |
| quantity\_filled    | bigint    | Amount of tokens that was filled             |
| quantity\_remaining | bigint    | Amount of tokens remaining                   |
| valid\_from         | bigint    | Listing start time                           |
| valid\_until        | bigint    | Listing end time                             |
| nonce               | string    | The order nonce of the maker                 |
| source              | string    | Source of the listing (e.g. opensea.io)      |
| fee\_bps            | bigint    | Listing fee                                  |
| expiration          | bigint    | Listing expiration time                      |
| raw\_data           | string    | Raw order data (format will vary per source) |
| created\_at         | timestamp | Timestamp the listing was created            |
| updated\_at         | timestamp | Timestamp the listing was updated            |


# Attribute Keys
Source: https://docs.dune.com/data-catalog/community/reservoir/attribute-keys



## **reservoir.attribute\_keys**

This table contains records with information about each attribute key.

Query examples can be found here:

[https://dune.com/queries/1302930/2232305](https://dune.com/queries/1302930/2232305)

| **Column name** | **Type**  | **Description**                          |
| --------------- | --------- | ---------------------------------------- |
| id              | string    | Internal attribute key id                |
| collection\_id  | string    | Associated collection id                 |
| key             | string    | The name of the attribute                |
| kind            | string    | Value type (string, number, date, range) |
| rank            | number    | Sort order                               |
| created\_at     | timestamp | Timestamp the attribute key was created  |
| updated\_at     | timestamp | Timestamp the attribute key was updated  |


# Attributes
Source: https://docs.dune.com/data-catalog/community/reservoir/attributes



## **reservoir.attributes**

This table contains records with information about each attribute.

Query examples can be found here:

[https://dune.com/queries/1302927/2232298](https://dune.com/queries/1302927/2232298)

[https://dune.com/queries/1302966/2232361](https://dune.com/queries/1302966/2232361)

| **Column name**    | **Type**  | **Description**                                            |
| ------------------ | --------- | ---------------------------------------------------------- |
| id                 | bigint    | Internal attribute id                                      |
| attribute\_key\_id | bigint    | Internal attribute key id                                  |
| value              | string    | Attribute value                                            |
| token\_count       | bigint    | Amount of tokens that have the attribute                   |
| on\_sale\_count    | bigint    | Amount of tokens that have the attribute which are on sale |
| floor\_sell\_value | decimal   | Current floor ask price                                    |
| sell\_updated\_at  | timestamp | Timestamp the floor sale was last updated                  |
| collection\_id     | string    | Associated collection id                                   |
| kind               | string    | Value type (string, number, date, range)                   |
| key                | string    | Associated key name                                        |
| created\_at        | timestamp | Timestamp the attribute was created                        |
| updated\_at        | timestamp | Timestamp the attribute was updated                        |


# Bid Events
Source: https://docs.dune.com/data-catalog/community/reservoir/bid-events



## **reservoir.bid\_events**

This table contains records with information about each bid change.

| **Column name**     | **Type**  | **Description**                                                                                                 |
| ------------------- | --------- | --------------------------------------------------------------------------------------------------------------- |
| id                  | string    | Internal event id                                                                                               |
| kind                | string    | Event type (new-order, expiry, sale, cancel, balance-change, approval-change, bootstrap, revalidation, reprice) |
| status              | string    | Event status (active, expired)                                                                                  |
| contract            | string    | Contract address                                                                                                |
| token\_set\_id      | string    | Id of the token set                                                                                             |
| order\_id           | string    | Associated bid id                                                                                               |
| maker               | string    | Associated bid maker wallet address                                                                             |
| price               | string    | Associated bid price (native currency)                                                                          |
| value               | string    | Associated bid value (native currency)                                                                          |
| quantity\_remaining | bigint    | Associated bid tokens remaining                                                                                 |
| valid\_from         | bigint    | Associated bid validity start                                                                                   |
| valid\_until        | bigint    | Associated bid validity expiration                                                                              |
| source              | string    | Source of the order (e.g. opensea.io)                                                                           |
| tx\_hash            | string    | Associated transaction hash                                                                                     |
| tx\_timestamp       | bigint    | Associated transaction timestamp                                                                                |
| created\_at         | timestamp | Timestamp the event was recorded                                                                                |


# Bids
Source: https://docs.dune.com/data-catalog/community/reservoir/bids



## **reservoir.bids**

This table contains records with information about each bid.

| **Column name**     | **Type**  | **Description**                              |
| ------------------- | --------- | -------------------------------------------- |
| id                  | string    | Internal order id                            |
| kind                | string    | Protocol name (e.g. seaport)                 |
| status              | string    | Order status (active, inactive)              |
| contract            | string    | Contract address                             |
| token\_set\_id      | string    | Id of the token set                          |
| maker               | string    | Maker wallet address                         |
| taker               | string    | Taker wallet address                         |
| price               | string    | The current price (native currency)          |
| value               | string    | The current value (native currency)          |
| currency\_address   | string    | Currency address                             |
| currency\_symbol    | string    | Currency symbol                              |
| currency\_price     | string    | Currency price                               |
| quantity            | bigint    | Amount of tokens that are listed             |
| quantity\_filled    | bigint    | Amount of tokens that was filled             |
| quantity\_remaining | bigint    | Amount of tokens remaining                   |
| valid\_from         | bigint    | Listing start time                           |
| valid\_until        | bigint    | Listing end time                             |
| nonce               | bigint    | The order nonce of the maker                 |
| source              | string    | Source of the listing (e.g. opensea.io)      |
| fee\_bps            | bigint    | Listing fee                                  |
| expiration          | bigint    | Expiration timestamp                         |
| raw\_data           | string    | Raw order data (format will vary per source) |
| created\_at         | timestamp | Timestamp the listing was created            |
| updated\_at         | timestamp | Timestamp the listing was updated            |


# Collection Floor Ask Events
Source: https://docs.dune.com/data-catalog/community/reservoir/collection-floor-ask-events



## **reservoir.collection\_floor\_ask\_events**

This table contains records with information about each collection floor ask change.

Query examples can be found here:

[https://dune.com/queries/1302799/2232083](https://dune.com/queries/1302799/2232083)

[https://dune.com/queries/1302841/2232151](https://dune.com/queries/1302841/2232151)

| **Column name** | **Type**  | **Description**                                                                                                 |
| --------------- | --------- | --------------------------------------------------------------------------------------------------------------- |
| id              | bigint    | Internal event id                                                                                               |
| kind            | string    | Event type (new-order, expiry, sale, cancel, balance-change, approval-change, bootstrap, revalidation, reprice) |
| collection\_id  | string    | Collection id                                                                                                   |
| contract        | string    | Contract address                                                                                                |
| token\_id       | string    | Id of the token in the collection                                                                               |
| order\_id       | string    | Associated ask id                                                                                               |
| maker           | string    | Associated ask maker wallet address                                                                             |
| price           | decimal   | Associated ask price (native currency)                                                                          |
| previous\_price | decimal   | Previous floor ask price (native currency)                                                                      |
| valid\_until    | bigint    | Associated ask validity expiration                                                                              |
| source          | string    | Source of the order (e.g. opensea.io)                                                                           |
| tx\_hash        | string    | Associated transaction hash                                                                                     |
| tx\_timestamp   | bigint    | Associated transaction timestamp                                                                                |
| created\_at     | timestamp | Timestamp the event was recorded                                                                                |


# Collection Top Bid Events
Source: https://docs.dune.com/data-catalog/community/reservoir/collection-top-bid-events



## **reservoir.collection\_top\_bid\_events**

This table contains records with information about each collection top bid change.

| **Column name** | **Type**  | **Description**                                                                                                 |
| --------------- | --------- | --------------------------------------------------------------------------------------------------------------- |
| id              | string    | Internal event id                                                                                               |
| kind            | string    | Event type (new-order, expiry, sale, cancel, balance-change, approval-change, bootstrap, revalidation, reprice) |
| collection\_id  | string    | Collection id                                                                                                   |
| contract        | string    | Contract address                                                                                                |
| token\_id       | string    | Id of the token in the collection                                                                               |
| order\_id       | string    | Associated bid id                                                                                               |
| maker           | string    | Associated bid maker wallet address                                                                             |
| price           | string    | Associated bid price (native currency)                                                                          |
| previous\_price | decimal   | Previous top bid price (native currency)                                                                        |
| valid\_until    | bigint    | Associated bid validity expiration                                                                              |
| source          | string    | Source of the order (e.g. opensea.io)                                                                           |
| tx\_hash        | string    | Associated transaction hash                                                                                     |
| tx\_timestamp   | bigint    | Associated transaction timestamp                                                                                |
| created\_at     | timestamp | Timestamp the event was recorded                                                                                |


# Collections
Source: https://docs.dune.com/data-catalog/community/reservoir/collections



## **reservoir.collections**

This table contains records with information about each NFT collection.

Query examples can be found here:

[https://dune.com/queries/1302781/2232054](https://dune.com/queries/1302781/2232054)

[https://dune.com/queries/1302788/2232065](https://dune.com/queries/1302788/2232065)

| **Column name**            | **Type**  | **Description**                             |
| -------------------------- | --------- | ------------------------------------------- |
| id                         | string    | Internal collection id                      |
| slug                       | string    | Collection slug                             |
| name                       | string    | Collection name                             |
| description                | string    | Collection description                      |
| token\_count               | bigint    | Number of tokens in the collection          |
| contract                   | string    | Contract address                            |
| day1\_rank                 | bigint    | Ranking in the previous day                 |
| day7\_rank                 | bigint    | Ranking in the previous 7 days              |
| day30\_rank                | bigint    | Ranking in the previous 30 days             |
| all\_time\_rank            | bigint    | All time ranking                            |
| day1\_volume               | decimal   | Trade volume in the previous day            |
| day7\_volume               | decimal   | Trade volume in the previous 7 days         |
| day30\_volume              | decimal   | Trade volume in the previous 30 days        |
| all\_time\_volume          | decimal   | All time trade volume                       |
| day1\_volume\_change       | double    | Trade volume change in the previous day     |
| day7\_volume\_change       | double    | Trade volume change in the previous 7 days  |
| day30\_volume\_change      | double    | Trade volume change in the previous 30 days |
| floor\_ask\_value          | decimal   | Current floor ask price (native currency)   |
| day1\_floor\_sale\_value   | decimal   | Floor sale price in the previous day        |
| day7\_floor\_sale\_value   | decimal   | Floor sale price 7 days ago                 |
| day30\_floor\_sale\_value  | decimal   | Floor sale price 30 days ago                |
| day1\_floor\_sale\_change  | double    | Floor sale price change from previous day   |
| day7\_floor\_sale\_change  | double    | Floor sale price change from 7 days ago     |
| day30\_floor\_sale\_change | double    | Floor sale price change from 30 days ago    |
| created\_at                | timestamp | Timestamp the collection was created        |
| updated\_at                | timestamp | Timestamp the collection was updated        |


# Reservoir NFT trading data
Source: https://docs.dune.com/data-catalog/community/reservoir/overview

Reservoir makes open-source NFT trading infrastructure enabling the next generation of NFT products.

# Reservoir

**Dashboard:** [https://dune.com/reservoir0x/reservoir-dune-docs-dashboard](https://dune.com/reservoir0x/reservoir-dune-docs-dashboard)

**Docs:** [https://docs.reservoir.tools/docs](https://docs.reservoir.tools/docs)

**Discord:** [https://discord.gg/jbEUwrVx](https://discord.gg/jbEUwrVx)

## Data available:

<CardGroup>
  <Card title="Ask Events" description="Information about Ask events in a marketplace." href="/data-catalog/community/reservoir/ask-events" />

  <Card title="Bid Events" description="Information about Bid events in a marketplace." href="/data-catalog/community/reservoir/bid-events" />

  <Card title="Collections" description="Information about NFT collections." href="/data-catalog/community/reservoir/collections" />

  <Card title="Token Floor Ask Events" description="Information about Token Floor Ask events in a marketplace." href="/data-catalog/community/reservoir/token-floor-ask-events" />

  <Card title="Asks" description="Information about Asks in a marketplace." href="/data-catalog/community/reservoir/asks" />

  <Card title="Bids" description="Information about Bids in a marketplace." href="/data-catalog/community/reservoir/bids" />

  <Card title="Tokens" description="Information about ERC-721 tokens." href="/data-catalog/community/reservoir/tokens" />

  <Card title="Attribute Keys" description="List of attributes or characteristics of a token." href="/data-catalog/community/reservoir/attribute-keys" />

  <Card title="Collection Floor Ask Events" description="Information about Collection Floor Ask events in a marketplace." href="/data-catalog/community/reservoir/collection-floor-ask-events" />

  <Card title="Sales" description="Information about sales in a marketplace." href="/data-catalog/community/reservoir/sales" />

  <Card title="Attributes" description="Information about token attributes." href="/data-catalog/community/reservoir/attributes" />

  <Card title="Collection Top Bid Events" description="Information about Collection Top Bid events in a marketplace." href="/data-catalog/community/reservoir/collection-top-bid-events" />

  <Card title="Token Attributes" description="Information about token attributes and characteristics." href="/data-catalog/community/reservoir/token-attributes" />
</CardGroup>


# Sales
Source: https://docs.dune.com/data-catalog/community/reservoir/sales



## **reservoir.sales**

This table contains records with information about each sale.

Query examples can be found here:

[https://dune.com/queries/1302771/2232036](https://dune.com/queries/1302771/2232036)

[https://dune.com/queries/1302775/2232040](https://dune.com/queries/1302775/2232040)

| **Column name**      | **Type**  | **Description**                                   |
| -------------------- | --------- | ------------------------------------------------- |
| id                   | string    | Internal sale id                                  |
| contract             | string    | Contract address                                  |
| token\_id            | string    | Id of the token in the collection                 |
| order\_id            | string    | Associated order id                               |
| order\_kind          | string    | Protocol name (e.g. seaport)                      |
| order\_side          | string    | Order type (ask / bid)                            |
| order\_source        | string    | Source of the listing (e.g. opensea.io)           |
| from                 | string    | Maker wallet address                              |
| to                   | string    | Taker wallet address                              |
| price                | decimal   | Sale price (native currency)                      |
| usd\_price           | string    | Sale price in USD                                 |
| currency\_address    | string    | The currency address used for this sale           |
| currency\_symbol     | string    | The currency symbol used for this sale            |
| currency\_price      | decimal   | Sale price                                        |
| amount               | string    | Amount of tokens sold                             |
| fill\_source         | string    | Where the order was filled                        |
| aggregator\_source   | string    | Aggregator source (e.g. reservoir)                |
| wash\_trading\_score | int       | Internal wash trading score (based on past sales) |
| is\_primary          | boolean   | Is paid mint?                                     |
| tx\_hash             | string    | Associated transaction hash                       |
| tx\_log\_index       | int       | Associated transaction log index                  |
| tx\_batch\_index     | int       | Associated transaction batch index                |
| tx\_timestamp        | bigint    | Associated transaction timestamp                  |
| created\_at          | timestamp | Timestamp the sale was recorded                   |
| updated\_at          | timestamp | Timestamp the sale was updated                    |


# Token Attributes
Source: https://docs.dune.com/data-catalog/community/reservoir/token-attributes



## **reservoir.token\_attributes**

This table contains records with information about each NFT token attribute.

Query examples can be found here:

[https://dune.com/queries/1302940/2232326](https://dune.com/queries/1302940/2232326)

| **Column name** | **Type**  | **Description**                           |
| --------------- | --------- | ----------------------------------------- |
| id              | bigint    | Internal token attribute id               |
| contract        | string    | Contract address                          |
| token\_id       | string    | Id of the token in the collection         |
| attribute\_id   | bigint    | Internal attribute id                     |
| collection\_id  | string    | Internal collection id                    |
| key             | string    | Attribute name                            |
| value           | string    | Attribute value                           |
| created\_at     | timestamp | Timestamp the token attribute was created |
| updated\_at     | timestamp | Timestamp the token attribute was updated |


# Token Floor Ask Events
Source: https://docs.dune.com/data-catalog/community/reservoir/token-floor-ask-events



## **reservoir.token\_floor\_ask\_events**

This table contains records with information about each NFT token floor ask change.

Query examples can be found here:

[https://dune.com/queries/1302852/2232169](https://dune.com/queries/1302852/2232169)

[https://dune.com/queries/1302854/2232173](https://dune.com/queries/1302854/2232173)

| **Column name** | **Type**  | **Description**                                                                                                 |
| --------------- | --------- | --------------------------------------------------------------------------------------------------------------- |
| id              | bigint    | Internal token attribute id                                                                                     |
| kind            | string    | Event type (new-order, expiry, sale, cancel, balance-change, approval-change, bootstrap, revalidation, reprice) |
| contract        | string    | Contract address                                                                                                |
| token\_id       | string    | Id of the token in the collection                                                                               |
| order\_id       | string    | Associated Ask id                                                                                               |
| maker           | string    | Associated Ask maker wallet address                                                                             |
| price           | decimal   | Associated ask price (native currency)                                                                          |
| previous\_price | decimal   | Previous associated ask price (native currency)                                                                 |
| nonce           | string    | The order nonce of the maker                                                                                    |
| valid\_from     | bigint    | Associated ask validity start                                                                                   |
| valid\_until    | bigint    | Associated ask validity expiration                                                                              |
| source          | string    | Source of the order (e.g. opensea.io)                                                                           |
| tx\_hash        | string    | Associated transaction hash                                                                                     |
| tx\_timestamp   | bigint    | Associated transaction timestamp                                                                                |
| created\_at     | timestamp | Timestamp the event was recorded                                                                                |


# Tokens
Source: https://docs.dune.com/data-catalog/community/reservoir/tokens



## **reservoir.tokens**

This table contains records with information about each NFT token.

Query examples can be found here:

[https://dune.com/queries/1303052/2232521](https://dune.com/queries/1303052/2232521)

[https://dune.com/queries/1303064/2232571](https://dune.com/queries/1303064/2232571)

| **Column name**         | **Type**  | **Description**                    |   |
| ----------------------- | --------- | ---------------------------------- | - |
| id                      | string    | Internal token id                  |   |
| contract                | string    | Contract address                   |   |
| token\_id               | string    | Id of the token in the collection  |   |
| name                    | string    | NFT name                           |   |
| description             | string    | NFT description                    |   |
| collection\_id          | string    | Associated Collection id           |   |
| owner                   | string    | Owner wallet address               |   |
| floor\_ask\_id          | string    | Floor ask id                       |   |
| floor\_ask\_value       | bigint    | Floor ask value                    |   |
| floor\_ask\_maker       | string    | Floor ask maker wallet address     |   |
| floor\_ask\_valid\_from | bigint    | Floor ask listing start time       |   |
| floor\_ask\_valid\_to   | bigint    | Floor ask listing end time         |   |
| floor\_ask\_source      | string    | Floor ask source (e.g. opensea.io) |   |
| last\_sale\_value       | bigint    | Last sale value                    |   |
| last\_sale\_timestamp   | bigint    | Last sale timestamp                |   |
| created\_at             | timestamp | Timestamp the token was created    |   |
| updated\_at             | timestamp | Timestamp the token was updated    |   |


# dune.shot.dataset_follows
Source: https://docs.dune.com/data-catalog/community/snapshot/follows

Snapshot space follows — users subscribed to governance spaces.

## Table description

The `dune.shot.dataset_follows` table provides data on the follow relationships between users on Snapshot.

## Table Schema

| Column Name | Type      | Description                                                     |
| ----------- | --------- | --------------------------------------------------------------- |
| id          | varbinary | Unique identifier of the follow record                          |
| ipfs        | varchar   | IPFS hash of the follow data                                    |
| space       | varchar   | Snapshot space (DAO) being followed                             |
| created     | bigint    | Unix timestamp when the follow was created                      |
| follower    | varbinary | Address of the user following the space                         |
| to\_delete  | bigint    | Flag indicating if the follow has been removed (1 = unfollowed) |

## Table Sample

<TableSample />


# Snapshot Data
Source: https://docs.dune.com/data-catalog/community/snapshot/overview

Snapshot data is available on Dune

# Snapshot

[Snapshot](https://snapshot.org) - a decentralized voting platform that enables off-chain, gasless voting for decentralized governance.

Snapshot is pivotal for communities to make collective decisions effectively without the high costs associated with on-chain votes. It operates on IPFS, ensuring that proposals and votes are tamper-proof and easily accessible.

**Website** : [https://snapshot.org](https://snapshot.org)

**Documentation** : [https://docs.snapshot.org](https://docs.snapshot.org)

**Twitter** : [https://twitter.com/SnapshotLabs](https://twitter.com/SnapshotLabs)

## Data available:

<CardGroup>
  <Card title="Follows" icon="person" href="/data-catalog/community/snapshot/follows">
    Data on user follow relationships within the Snapshot ecosystem, tracking how users engage with one another.
  </Card>

  <Card title="Proposals" icon="file" href="/data-catalog/community/snapshot/proposals">
    Detailed views of governance proposals, including information on their creation, discussion, and current status.
  </Card>

  <Card title="Spaces" icon="cube" href="/data-catalog/community/snapshot/spaces">
    Overviews of different governance spaces, showcasing active and historical governance frameworks associated with various projects.
  </Card>

  <Card title="Users" icon="users" href="/data-catalog/community/snapshot/users">
    Comprehensive dataset of user profiles, including registration details and activity logs within Snapshot.
  </Card>

  <Card title="Votes" icon="check" href="/data-catalog/community/snapshot/votes">
    Insights into votes cast on proposals, providing analytics on voting patterns, stakeholder involvement, and outcomes.
  </Card>
</CardGroup>


# dune.shot.dataset_proposals_view
Source: https://docs.dune.com/data-catalog/community/snapshot/proposals

Snapshot governance proposals — proposal text, voting options, and results.

## Table description

The `dune.shot.dataset_proposals_view` table provides a comprehensive view of all governance proposals made on Snapshot.

## Table Schema

| Column Name          | Type      | Description                                                                 |
| -------------------- | --------- | --------------------------------------------------------------------------- |
| id                   | varbinary | Unique identifier of the proposal                                           |
| app                  | varchar   | Application or client used to create the proposal                           |
| end                  | bigint    | Unix timestamp when voting ends                                             |
| body                 | varchar   | Full markdown body/description of the proposal                              |
| ipfs                 | varchar   | IPFS hash of the proposal data                                              |
| type                 | varchar   | Voting type (e.g. `single-choice`, `weighted`, `ranked-choice`, `approval`) |
| space                | varchar   | Snapshot space (DAO) the proposal belongs to                                |
| start                | bigint    | Unix timestamp when voting begins                                           |
| title                | varchar   | Title of the proposal                                                       |
| votes                | bigint    | Total number of votes cast on the proposal                                  |
| author               | varbinary | Address of the proposal creator                                             |
| quorum               | double    | Minimum voting power required for the proposal to pass                      |
| scores               | varchar   | JSON-encoded final scores for each choice                                   |
| symbol               | varchar   | Token symbol used for voting power display                                  |
| choices              | varchar   | JSON-encoded array of available voting choices                              |
| created              | bigint    | Unix timestamp when the proposal was created                                |
| flagged              | bigint    | Flag indicating if the proposal has been flagged (1 = flagged)              |
| network              | varchar   | Blockchain network ID used for strategy execution                           |
| plugins              | varchar   | JSON-encoded plugin configurations                                          |
| privacy              | varchar   | Privacy mode for the vote (e.g. `shutter` for encrypted voting)             |
| updated              | bigint    | Unix timestamp of the last update                                           |
| snapshot             | bigint    | Block number snapshot used for voting power calculation                     |
| discussion           | varchar   | URL to an external discussion thread                                        |
| strategies           | varchar   | JSON-encoded array of voting strategies                                     |
| validation           | varchar   | JSON-encoded validation settings for proposal creation                      |
| scores\_state        | varchar   | State of score calculation (e.g. `final`)                                   |
| scores\_total        | double    | Sum of all voting power across all choices                                  |
| scores\_updated      | bigint    | Unix timestamp when scores were last updated                                |
| scores\_by\_strategy | varchar   | JSON-encoded breakdown of scores by each strategy                           |

## Table Sample

<TableSample />


# dune.shot.dataset_spaces_view
Source: https://docs.dune.com/data-catalog/community/snapshot/spaces

Snapshot governance spaces — DAO and protocol governance space metadata.

## Table description

The `dune.shot.dataset_spaces_view` table provides overviews of different governance spaces on Snapshot.

## Table Schema

| Column Name | Type    | Description                                                            |
| ----------- | ------- | ---------------------------------------------------------------------- |
| id          | varchar | Unique identifier (ENS name) of the Snapshot space                     |
| name        | varchar | Display name of the space                                              |
| deleted     | bigint  | Flag indicating if the space has been deleted (1 = deleted)            |
| flagged     | bigint  | Flag indicating if the space has been flagged for review (1 = flagged) |
| settings    | varchar | JSON-encoded space settings (strategies, voting params, admins, etc.)  |
| verified    | bigint  | Flag indicating if the space is verified (1 = verified)                |
| created\_at | bigint  | Unix timestamp when the space was created                              |
| updated\_at | bigint  | Unix timestamp of the last update to the space                         |

## Table Sample

<TableSample />


# dune.shot.dataset_users
Source: https://docs.dune.com/data-catalog/community/snapshot/users

Snapshot users — governance participant profiles and activity.

## Table description

The `dune.shot.dataset_users` table contains detailed information about users registered on Snapshot.

## Table Schema

| Column Name | Type      | Description                                            |
| ----------- | --------- | ------------------------------------------------------ |
| id          | varbinary | Wallet address serving as the user's unique identifier |
| ipfs        | varchar   | IPFS hash of the user profile data                     |
| created     | bigint    | Unix timestamp when the user was first registered      |
| profile     | varchar   | JSON-encoded user profile information                  |

## Table Sample

<TableSample />


# dune.shot.dataset_votes_view
Source: https://docs.dune.com/data-catalog/community/snapshot/votes

Snapshot votes — individual voting records with choice, voting power, and timestamp.

## Table description

The `dune.shot.dataset_votes_view` table provides insights into votes cast on proposals, highlighting voting patterns and outcomes.

## Table Schema

| Column Name      | Type      | Description                                                                  |
| ---------------- | --------- | ---------------------------------------------------------------------------- |
| cb               | bigint    | Internal cursor/batch identifier                                             |
| id               | varbinary | Unique identifier of the vote                                                |
| vp               | double    | Total voting power used for this vote                                        |
| app              | varchar   | Application or client used to cast the vote                                  |
| ipfs             | varchar   | IPFS hash of the vote data                                                   |
| space            | varchar   | Snapshot space (DAO) the vote was cast in                                    |
| voter            | varbinary | Address of the voter                                                         |
| choice           | varchar   | The choice(s) selected by the voter (JSON-encoded for weighted/ranked votes) |
| reason           | varchar   | Optional text reason provided by the voter                                   |
| created          | bigint    | Unix timestamp when the vote was cast                                        |
| metadata         | varchar   | Additional metadata associated with the vote                                 |
| proposal         | varbinary | Identifier of the proposal being voted on                                    |
| vp\_state        | varchar   | State of voting power calculation (e.g. `final`)                             |
| vp\_by\_strategy | varchar   | Breakdown of voting power by each strategy (JSON-encoded)                    |

## Table Sample

<TableSample />


# EVM Token & NFT Balances
Source: https://docs.dune.com/data-catalog/curated/balances/evm-balances

Balances for addresses on EVM networks.

<Warning>
  **IMPORTANT: These tables are currently very unperformant.** The ONLY efficient way to query them is by using the query template pattern shown below. Do NOT query these tables directly - you will experience timeouts and poor performance.
</Warning>

The `tokens_<chain>.balances_daily` and `tokens_<chain>.balances` tables contain token balances across all addresses on EVM-compatible networks. This dataset encompasses:

* **Native currency balances** (such as ETH, MATIC)
* **ERC-20 token balances**
* **ERC-721 (NFT) balances**
* **ERC-1155 token balances**

## How to Query These Tables Efficiently

**The ONLY performant way to query these tables is through the query template pattern:**

```sql theme={null}
SELECT 
    day,
    token_symbol,
    token_address,
    SUM(balance) as balance,
    SUM(balance_usd) as balance_usd
FROM "query_4419528(blockchain = 'base', filter='address = 0x729170d38dd5449604f35f349fdfcc9ad08257cd', native_token='ETH')"
WHERE day >= timestamp '2025-01-01'
GROUP BY 1, 2, 3
```

**Example Query:** [https://dune.com/queries/5133694](https://dune.com/queries/5133694)

### Template Parameters

* **blockchain**: The EVM chain to query (e.g., 'base', 'ethereum', 'arbitrum', 'optimism')
* **filter**: Filter condition for addresses (e.g., `'address = 0x...'`)
* **native\_token**: The native token symbol for the chain (e.g., 'ETH', 'MATIC')

### Network Coverage

Balances are available for the following EVM-compatible networks:

* Arbitrum
* Avalanche C-Chain
* Base
* Ethereum
* Kaia
* Linea
* Optimism
* Polygon
* Scroll
* Worldchain

## Balance Calculation Methodology

Our approach to storing balances involves querying the blockchain for the balance of each address at the end of the day. The balance is then stored in the `tokens_<chain>.balances` table, which is updated daily. For the balance to be queried, the address must have appeared in any of the following tables:

* **For native currencies**: Transactions and traces `to`/`from` addresses, Ethereum-specific withdrawals, and block mining/validator activities.
* **For ERC20**: Analysis is based on token transfer events detailed in the [tokens\_ethereum\_base\_transfers](https://github.com/duneanalytics/spellbook/blob/main/models/_sector/tokens/ethereum/tokens_ethereum_base_transfers.sql). The address balance is updated based on the `to`/`from` addresses in the transfer events. For non-standard ERC20 tokens (e.g., ERC4626 vault tokens, rebasing tokens like stETH), balances are updated when standard ERC20 transfer events are detected. Coverage for additional token standards is continuously expanding.
* **For ERC721 and ERC1155**: Inspection of NFT transfer activities via the [nft\_ethereum\_transfers](https://github.com/duneanalytics/spellbook/blob/main/models/_sector/nft/transfers/chains/nft_ethereum_transfers.sql), focusing on the `to`/`from` addresses.

These dependencies on transfer and NFT event tables introduce a delay to balance updates, contingent on the latency inherent in the curated data processing.

Balances are tracked for all addresses that appear in the activity tables listed above. For tokens using non-standard transfer events, [contact our team](mailto:support@dune.com) to request coverage — we continuously expand the range of token standards supported.

### Granular Balances

The `tokens_<chain>.balances` table provides a more granular view of token balances, containing granular balance changes for each address and token combination per block. This table is updated in near real-time and is used to calculate the daily balances.

The `tokens_<chain>.balances` table adds a new row every time a balance changes but does not carry the balance forward for every block. Instead, it only creates a new row for a balance change of an address and token combination.

<Note>
  **Direct querying is possible** for the `tokens_<chain>.balances` table when querying a limited time range and small number of addresses. For broader queries, use the query template pattern shown above.
</Note>


# Balances
Source: https://docs.dune.com/data-catalog/curated/balances/overview

Token and asset balance data across EVM and Solana networks

<Warning>
  **Open Beta**: The balances tables are currently in open beta and may experience performance limitations. We are actively working on revamping and improving these tables. For optimal performance, please follow the query patterns documented on the individual balance pages.
</Warning>

Dune provides token balance data that enables tracking of asset holdings across blockchain addresses. Balance data is essential for portfolio analysis, wallet tracking, and understanding asset distribution across networks.

<Info>
  **Maintained by:** Dune · **Refresh:** \~1.5 hours · **Chains:** EVM networks, Solana
</Info>

<Card title="Get This Data" icon="database" href="https://dune.com/enterprise?dataset=balances">
  Access balance data via API, Datashare, or the Dune App.
</Card>

## Available Datasets

<CardGroup>
  <Card title="EVM Token & NFT Balances" icon="scale-balanced" href="/data-catalog/curated/balances/evm-balances">
    Token balances for addresses on EVM-compatible networks including native currencies, ERC20, ERC721, and ERC1155 tokens
  </Card>

  <Card title="Solana Latest Balances" icon="bolt" href="/data-catalog/curated/balances/solana-latest-balances">
    Current SOL and SPL token balances for every address on Solana
  </Card>

  <Card title="Solana Daily Balances" icon="calendar-day" href="/data-catalog/curated/balances/solana-daily-balances">
    Historical daily SOL and SPL token balance snapshots for every address on Solana
  </Card>
</CardGroup>

## Key Features

* **Multi-Asset Coverage**: Native currencies, ERC20 tokens, NFTs (ERC721/ERC1155), SOL, and SPL tokens
* **Daily Snapshots**: End-of-day balance snapshots for historical analysis
* **Granular Changes**: Block-level balance change tracking
* **Cross-Chain Support**: Balance data across multiple EVM networks and Solana

## When to Use These Tables

* Track wallet portfolio holdings and historical balances
* Analyze token holder distribution and concentration metrics
* Monitor treasury balances for DAOs and protocols
* Build wallet scoring and risk profiling systems
* Power portfolio dashboards and balance alerts

## Query Performance

Balance tables come in two variants: `_latest` (current snapshot) and `_daily` (historical). Use `_latest` for current balances and `_daily` for historical analysis.

**Partition keys:** `blockchain`, `token_address` (varies by table)

```sql theme={null}
-- ✅ Good: latest balances with chain filter
SELECT * FROM balances.erc20_latest
WHERE blockchain = 'ethereum'
  AND address = 0x...

-- ✅ Good: historical with date filter
SELECT * FROM balances.erc20_daily
WHERE blockchain = 'ethereum'
  AND block_date >= DATE '2025-01-01'
  AND address = 0x...
```

## Methodology

Balance tables are maintained by Dune ([source code](https://github.com/duneanalytics/spellbook)). They compute cumulative balances from token transfer events — summing all incoming and outgoing transfers per address per token. The `_latest` tables provide the most recent balance snapshot, while `_daily` tables store end-of-day balances for historical analysis.

## Example Queries

**Top ETH holders on Ethereum:**

```sql theme={null}
SELECT
  address,
  balance,
  balance_usd
FROM balances.erc20_latest
WHERE blockchain = 'ethereum'
  AND token_address = 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2 -- WETH
ORDER BY balance DESC
LIMIT 20
```

**Daily USDC balance for a specific wallet:**

```sql theme={null}
SELECT
  block_date,
  balance,
  balance_usd
FROM balances.erc20_daily
WHERE blockchain = 'ethereum'
  AND address = 0x...
  AND token_address = 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48
  AND block_date >= DATE '2025-01-01'
ORDER BY block_date
```

## Related Tables

* `tokens.transfers` — Raw transfer events underlying balance calculations
* `prices.day` / `prices.latest` — Token pricing for USD balance values
* `tokens.erc20` — Token metadata (symbols, decimals)
* `tokens_solana.fungible` — Solana SPL token metadata
* `labels.addresses` — Address identification for known entities

<CardGroup>
  <Card title="Enterprise Data Solutions" icon="building" href="https://dune.com/enterprise">
    Need custom balance datasets or dedicated support? Talk to our enterprise team.
  </Card>

  <Card title="Build Custom Models" icon="code" href="/api-reference/connectors/overview">
    Build private balance tracking pipelines with the dbt Connector.
  </Card>
</CardGroup>


# solana_utils.daily_balances
Source: https://docs.dune.com/data-catalog/curated/balances/solana-daily-balances

Historical daily SOL and SPL token balances for every address on Solana.

The `solana_utils.daily_balances` table provides end-of-day balance snapshots for every address on Solana, covering both native SOL and SPL token holdings. This table is the historical counterpart to `solana_utils.latest_balances`.

Each row represents the balance for a specific address, token, and day. The table is partitioned by `month` for query performance and is sourced from `solana.account_activity`.

### When to Use This Table

* Track historical balance changes for a wallet over time
* Analyze token holder distribution trends
* Build time-series portfolio valuation charts
* Monitor treasury balances for Solana DAOs and protocols

### Query Performance

**Partition key:** `month`

Always include a time filter (`day` range) and filter on `address` or `token_mint_address` for best performance.

```sql theme={null}
-- ✅ Good: specific address + time range
SELECT *
FROM solana_utils.daily_balances
WHERE address = 'FG4Y3yX4AAchp1HvNZ7LfzFTewF2f6nDoMDCohTFrdpk'
  AND day >= DATE '2025-01-01'

-- ❌ Slow: no time or address filter
SELECT * FROM solana_utils.daily_balances
WHERE token_mint_address = 'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v'
```

## Table Schema

| Column                | Type             | Description                                |
| --------------------- | ---------------- | ------------------------------------------ |
| `day`                 | `TIMESTAMP`      | Day of the balance snapshot                |
| `month`               | `DATE`           | Month partition key                        |
| `address`             | `VARCHAR`        | Solana wallet address                      |
| `sol_balance`         | `DOUBLE`         | Native SOL balance at end of day           |
| `token_mint_address`  | `VARCHAR`        | Mint address of the SPL token              |
| `token_balance`       | `DECIMAL(38,18)` | SPL token balance in display units         |
| `token_balance_owner` | `VARCHAR`        | Owner of the token balance                 |
| `block_time`          | `TIMESTAMP`      | Block time of the last balance change      |
| `block_slot`          | `BIGINT`         | Block slot of the last balance change      |
| `unique_address_key`  | `VARCHAR`        | Unique key for address + token combination |
| `updated_at`          | `TIMESTAMP`      | When this record was last updated          |

## Table Sample

<TableSample />

## Example Queries

**Daily SOL balance for a wallet over the last 30 days:**

```sql theme={null}
SELECT
  day,
  sol_balance,
  token_balance,
  token_mint_address
FROM solana_utils.daily_balances
WHERE address = 'FG4Y3yX4AAchp1HvNZ7LfzFTewF2f6nDoMDCohTFrdpk'
  AND day >= NOW() - INTERVAL '30' DAY
ORDER BY day DESC
```

**Track USDC balance history for an address:**

```sql theme={null}
SELECT
  day,
  token_balance
FROM solana_utils.daily_balances
WHERE address = 'FG4Y3yX4AAchp1HvNZ7LfzFTewF2f6nDoMDCohTFrdpk'
  AND token_mint_address = 'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v' -- USDC
  AND day >= DATE '2025-01-01'
ORDER BY day
```


# solana_utils.latest_balances
Source: https://docs.dune.com/data-catalog/curated/balances/solana-latest-balances

Current SOL and SPL token balances for every address on Solana.

The `solana_utils.latest_balances` table provides the most recent balance snapshot for every address on Solana, covering both native SOL and SPL token holdings.

Each row represents the latest known balance for a specific address and token combination. This table is derived from `solana_utils.daily_balances` and is incrementally updated.

### When to Use This Table

* Look up current token holdings for a wallet
* Build portfolio dashboards showing real-time Solana balances
* Identify top holders of a specific SPL token
* Power wallet scoring and risk profiling systems

### Query Performance

This table can be large. Always filter on `address` or `token_mint_address` for best performance.

```sql theme={null}
-- ✅ Good: filter on specific address
SELECT *
FROM solana_utils.latest_balances
WHERE address = 'FG4Y3yX4AAchp1HvNZ7LfzFTewF2f6nDoMDCohTFrdpk'

-- ✅ Good: top holders of a specific token
SELECT address, token_balance
FROM solana_utils.latest_balances
WHERE token_mint_address = 'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v' -- USDC
ORDER BY token_balance DESC
LIMIT 100
```

## Table Schema

| Column                | Type             | Description                             |
| --------------------- | ---------------- | --------------------------------------- |
| `address`             | `VARCHAR`        | Solana wallet address                   |
| `block_time`          | `TIMESTAMP`      | Block time of the latest balance update |
| `block_slot`          | `BIGINT`         | Block slot of the latest balance update |
| `sol_balance`         | `DOUBLE`         | Native SOL balance                      |
| `token_balance`       | `DECIMAL(38,18)` | SPL token balance in display units      |
| `token_mint_address`  | `VARCHAR`        | Mint address of the SPL token           |
| `token_balance_owner` | `VARCHAR`        | Owner of the token balance              |
| `updated_at`          | `TIMESTAMP`      | When this record was last updated       |

## Table Sample

<TableSample />

## Example Queries

**Get all token balances for a specific wallet:**

```sql theme={null}
SELECT
  token_mint_address,
  token_balance,
  sol_balance,
  updated_at
FROM solana_utils.latest_balances
WHERE address = 'FG4Y3yX4AAchp1HvNZ7LfzFTewF2f6nDoMDCohTFrdpk'
ORDER BY token_balance DESC
```

**Top SOL holders:**

```sql theme={null}
SELECT
  address,
  sol_balance
FROM solana_utils.latest_balances
WHERE sol_balance > 0
ORDER BY sol_balance DESC
LIMIT 50
```


# bridges_evms.deposits
Source: https://docs.dune.com/data-catalog/curated/bridges/deposits

Cross-chain bridge deposits — tokens locked or burned on the source chain for bridging to another network.

The `bridges_evms.deposits` table contains individual bridge deposit events on source chains, enriched with token metadata and USD pricing.

## Table Schema

| Column                   | Type        | Description                               |
| ------------------------ | ----------- | ----------------------------------------- |
| `deposit_chain`          | `VARCHAR`   | Blockchain where tokens were sent from    |
| `withdrawal_chain_id`    | `DOUBLE`    | Chain ID where tokens were received       |
| `withdrawal_chain`       | `VARCHAR`   | Blockchain where tokens were received     |
| `bridge_name`            | `VARCHAR`   | Bridge protocol name                      |
| `bridge_version`         | `VARCHAR`   | Bridge version                            |
| `block_date`             | `TIMESTAMP` | Block date                                |
| `block_time`             | `TIMESTAMP` | Block timestamp                           |
| `block_number`           | `BIGINT`    | Block number                              |
| `deposit_amount_raw`     | `DOUBLE`    | Raw amount of tokens bridged              |
| `deposit_amount`         | `DOUBLE`    | Amount of tokens bridged in display units |
| `deposit_amount_usd`     | `DOUBLE`    | USD value of tokens bridged               |
| `sender`                 | `VARBINARY` | Source address                            |
| `recipient`              | `VARBINARY` | Destination address                       |
| `deposit_token_standard` | `VARCHAR`   | Source token standard                     |
| `deposit_token_address`  | `VARBINARY` | Source token contract address             |
| `tx_from`                | `VARBINARY` | Address that initiated the deposit        |
| `tx_hash`                | `VARBINARY` | Transaction hash                          |
| `evt_index`              | `BIGINT`    | Event index                               |
| `contract_address`       | `VARBINARY` | Bridge contract address                   |
| `bridge_transfer_id`     | `VARCHAR`   | Bridge order identifier                   |
| `duplicate_index`        | `BIGINT`    | Index for duplicate deposit events        |

## Table sample

<TableSample />


# bridges_evms.flows
Source: https://docs.dune.com/data-catalog/curated/bridges/flows

Matched cross-chain bridge flows — deposits paired with withdrawals for complete bridge transfer tracking.

The `bridges_evms.flows` table contains matched deposit-withdrawal pairs representing complete cross-chain bridge transfers across 41 EVM chains.

## Table Schema

| Column                      | Type        | Description                            |
| --------------------------- | ----------- | -------------------------------------- |
| `deposit_chain`             | `VARCHAR`   | Blockchain where tokens were sent from |
| `deposit_chain_id`          | `DOUBLE`    | Chain ID where tokens were sent from   |
| `withdrawal_chain`          | `VARCHAR`   | Blockchain where tokens were received  |
| `withdrawal_chain_id`       | `DOUBLE`    | Chain ID where tokens were received    |
| `bridge_name`               | `VARCHAR`   | Bridge protocol name                   |
| `bridge_version`            | `VARCHAR`   | Bridge version                         |
| `deposit_block_date`        | `TIMESTAMP` | Deposit block date                     |
| `deposit_block_time`        | `TIMESTAMP` | Deposit block timestamp                |
| `deposit_block_number`      | `BIGINT`    | Deposit block number                   |
| `withdrawal_block_date`     | `DATE`      | Withdrawal block date                  |
| `withdrawal_block_time`     | `TIMESTAMP` | Withdrawal block timestamp             |
| `withdrawal_block_number`   | `BIGINT`    | Withdrawal block number                |
| `deposit_amount_raw`        | `DOUBLE`    | Raw amount deposited                   |
| `deposit_amount`            | `DOUBLE`    | Amount deposited in display units      |
| `withdrawal_amount_raw`     | `DOUBLE`    | Raw amount withdrawn                   |
| `withdrawal_amount`         | `DOUBLE`    | Amount withdrawn in display units      |
| `amount_usd`                | `DOUBLE`    | USD value of the bridge transfer       |
| `sender`                    | `VARBINARY` | Source address                         |
| `recipient`                 | `VARBINARY` | Destination address                    |
| `deposit_token_standard`    | `VARCHAR`   | Source token standard                  |
| `withdrawal_token_standard` | `VARCHAR`   | Destination token standard             |
| `deposit_token_address`     | `VARBINARY` | Source token address                   |
| `withdrawal_token_address`  | `VARBINARY` | Destination token address              |
| `deposit_tx_from`           | `VARBINARY` | Address that initiated the deposit     |
| `deposit_tx_hash`           | `VARBINARY` | Deposit transaction hash               |
| `withdrawal_tx_hash`        | `VARBINARY` | Withdrawal transaction hash            |
| `bridge_transfer_id`        | `VARCHAR`   | Bridge order identifier                |
| `duplicate_index`           | `BIGINT`    | Index for duplicate events             |

## Table sample

<TableSample />


# Bridges
Source: https://docs.dune.com/data-catalog/curated/bridges/overview

Curated cross-chain bridge datasets across 41 EVM chains on Dune

Dune's bridge tables track cross-chain token transfers across 41 EVM chains, capturing deposit events on the source chain and withdrawal events on the destination chain, then matching them into complete bridge flows.

<Info>
  **Maintained by:** Dune · **Refresh:** \~30 min · **Chains:** 41 EVM chains
</Info>

<Card title="Get This Data" icon="database" href="https://dune.com/enterprise?dataset=bridges">
  Access bridge data via API, Datashare, or the Dune App.
</Card>

## Available Tables

<CardGroup>
  <Card title="bridges_evms.flows" icon="database" href="/data-catalog/curated/bridges/flows">
    Matched deposit-withdrawal pairs showing complete bridge transfers
  </Card>

  <Card title="bridges_evms.deposits" icon="database" href="/data-catalog/curated/bridges/deposits">
    Individual deposit events on source chains
  </Card>

  <Card title="bridges_evms.withdrawals" icon="database" href="/data-catalog/curated/bridges/withdrawals">
    Individual withdrawal events on destination chains
  </Card>
</CardGroup>

## When to Use These Tables

* Track cross-chain capital flows between L1s and L2s
* Monitor bridge protocol volumes and market share
* Analyze net inflows/outflows for specific chains
* Identify bridge usage patterns for wallets or tokens
* Build cross-chain flow dashboards for chain ecosystem teams

## Coverage

<Accordion title="View all 41 supported chains">
  Abstract, Apechain, Arbitrum, Avalanche C-Chain, Base, Berachain, Blast, BNB Chain, Bob, Boba, Celo, Corn, Ethereum, Fantom, Flare, Gnosis, HyperEVM, Ink, Kaia, Katana, Lens, Linea, Mantle, Nova, opBNB, Optimism, Plasma, Plume, Polygon, Ronin, Scroll, Sei, Sonic, Sophon, Story, Taiko, Unichain, Worldchain, zkEVM, zkSync, Zora
</Accordion>

**Protocols:** All major bridge protocols with decoded contracts on Dune. Use `SELECT DISTINCT bridge_name FROM bridges_evms.deposits` for the current list.

## Query Performance

Filter on `block_date` or `block_time` ranges. For chain-specific analysis, also filter on `deposit_chain` or `withdrawal_chain`.

```sql theme={null}
-- ✅ Good: time-bounded with chain filter
SELECT * FROM bridges_evms.deposits
WHERE deposit_chain = 'ethereum'
  AND block_date >= DATE '2025-01-01'

-- ❌ Slow: unbounded scan
SELECT * FROM bridges_evms.flows
WHERE bridge_name = 'across'
```

## Methodology

Bridge tables are maintained by Dune ([source code](https://github.com/duneanalytics/spellbook)). The system works in three stages: (1) `deposits` decodes deposit events on source chains, enriched with token metadata and USD pricing; (2) `withdrawals` decodes withdrawal events on destination chains; (3) `flows` joins deposits and withdrawals on `bridge_transfer_id` to produce matched pairs representing complete cross-chain transfers.

Not all deposits have matching withdrawals (and vice versa), as matching depends on both chains being indexed and the bridge protocol emitting linkable identifiers.

## Example Queries

**Daily bridge volume by destination chain (last 30 days):**

```sql theme={null}
SELECT
  date_trunc('day', deposit_block_time) AS day,
  withdrawal_chain,
  SUM(amount_usd) AS bridge_volume_usd,
  COUNT(*) AS num_transfers
FROM bridges_evms.flows
WHERE deposit_block_time >= NOW() - INTERVAL '30' DAY
GROUP BY 1, 2
ORDER BY 1 DESC, 3 DESC
```

**Net flows for a specific chain:**

```sql theme={null}
WITH inflows AS (
  SELECT SUM(deposit_amount_usd) AS total_in
  FROM bridges_evms.deposits
  WHERE withdrawal_chain = 'base'
    AND block_date >= DATE '2025-01-01'
),
outflows AS (
  SELECT SUM(deposit_amount_usd) AS total_out
  FROM bridges_evms.deposits
  WHERE deposit_chain = 'base'
    AND block_date >= DATE '2025-01-01'
)
SELECT
  i.total_in,
  o.total_out,
  i.total_in - o.total_out AS net_flow
FROM inflows i, outflows o
```

## Related Tables

* `cex.flows` — For tracking flows to/from centralized exchanges
* `tokens.transfers` — Raw token transfer events (bridges are a subset of all transfers)

<CardGroup>
  <Card title="Enterprise Data Solutions" icon="building" href="https://dune.com/enterprise">
    Need custom bridge datasets or additional chain coverage? Talk to our enterprise team.
  </Card>

  <Card title="Build Custom Models" icon="code" href="/api-reference/connectors/overview">
    Build private cross-chain flow pipelines with the dbt Connector.
  </Card>
</CardGroup>


# bridges_evms.withdrawals
Source: https://docs.dune.com/data-catalog/curated/bridges/withdrawals

Cross-chain bridge withdrawals — tokens minted or released on the destination chain after bridging.

The `bridges_evms.withdrawals` table contains individual bridge withdrawal events on destination chains, enriched with token metadata and USD pricing.

## Table Schema

| Column                      | Type        | Description                                |
| --------------------------- | ----------- | ------------------------------------------ |
| `deposit_chain_id`          | `DOUBLE`    | Chain ID where tokens were sent from       |
| `deposit_chain`             | `VARCHAR`   | Blockchain where tokens were sent from     |
| `withdrawal_chain`          | `VARCHAR`   | Blockchain where tokens were received      |
| `bridge_name`               | `VARCHAR`   | Bridge protocol name                       |
| `bridge_version`            | `VARCHAR`   | Bridge version                             |
| `block_date`                | `DATE`      | Block date                                 |
| `block_time`                | `TIMESTAMP` | Block timestamp                            |
| `block_number`              | `BIGINT`    | Block number                               |
| `withdrawal_amount_raw`     | `DOUBLE`    | Raw amount of tokens received              |
| `withdrawal_amount`         | `DOUBLE`    | Amount of tokens received in display units |
| `withdrawal_amount_usd`     | `DOUBLE`    | USD value of tokens received               |
| `sender`                    | `VARBINARY` | Source address                             |
| `recipient`                 | `VARBINARY` | Destination address                        |
| `withdrawal_token_standard` | `VARCHAR`   | Destination token standard                 |
| `withdrawal_token_address`  | `VARBINARY` | Destination token contract address         |
| `tx_from`                   | `VARBINARY` | Address that initiated the transaction     |
| `tx_hash`                   | `VARBINARY` | Transaction hash                           |
| `evt_index`                 | `BIGINT`    | Event index                                |
| `contract_address`          | `VARBINARY` | Bridge contract address                    |
| `bridge_transfer_id`        | `VARCHAR`   | Bridge order identifier                    |
| `duplicate_index`           | `BIGINT`    | Index for duplicate withdrawal events      |

## Table sample

<TableSample />


# cex.addresses
Source: https://docs.dune.com/data-catalog/curated/cex-flows/addresses

Centralized exchange address directory — all known addresses attributed to major exchanges.

The `cex.addresses` table contains all identified centralized exchange addresses across 29 chains, including non-EVM networks like Bitcoin, Solana, Aptos, Tron, and Sui.

## Table Schema

| Column          | Type        | Description                  |
| --------------- | ----------- | ---------------------------- |
| `blockchain`    | `VARCHAR`   | Blockchain                   |
| `address`       | `VARBINARY` | CEX-controlled address       |
| `cex_name`      | `VARCHAR`   | Centralized exchange name    |
| `distinct_name` | `VARCHAR`   | Distinct name of the address |
| `added_by`      | `VARCHAR`   | Who added the address        |
| `added_date`    | `DATE`      | Date the address was added   |

## Table sample

<TableSample />


# cex.deposit_addresses
Source: https://docs.dune.com/data-catalog/curated/cex-flows/deposit_addresses

Known centralized exchange deposit addresses — identified user-facing deposit wallets by exchange.

The `cex.deposit_addresses` table contains programmatically detected user deposit addresses — identified through on-chain consolidation patterns where tokens flow from external wallets through deposit addresses to known CEX hot wallets.

## Table Schema

| Column                           | Type        | Description                        |
| -------------------------------- | ----------- | ---------------------------------- |
| `blockchain`                     | `VARCHAR`   | Blockchain                         |
| `address`                        | `VARBINARY` | Deposit address                    |
| `cex_name`                       | `VARCHAR`   | CEX name                           |
| `first_deposit_token_standard`   | `VARCHAR`   | Token standard of first deposit    |
| `first_deposit_token_address`    | `VARBINARY` | Token address of first deposit     |
| `deposit_first_block_time`       | `TIMESTAMP` | Time of first deposit              |
| `consolidation_first_block_time` | `TIMESTAMP` | Time of first consolidation by CEX |
| `deposit_count`                  | `BIGINT`    | Number of deposits                 |
| `consolidation_count`            | `BIGINT`    | Number of consolidations           |
| `amount_deposited`               | `DOUBLE`    | Total amount deposited             |
| `consolidation_unique_key`       | `VARCHAR`   | Unique key for consolidation       |
| `deposit_unique_key`             | `VARCHAR`   | Unique key for deposit             |

## Table sample

<TableSample />


# cex.flows
Source: https://docs.dune.com/data-catalog/curated/cex-flows/flows

Token flows to and from centralized exchanges — deposits, withdrawals, and internal transfers with exchange entity attribution.

The `cex.flows` table contains all token flows to and from identified centralized exchange addresses across 21 EVM chains, classified as inflows or outflows with USD pricing.

## Table Schema

| Column           | Type        | Description                           |
| ---------------- | ----------- | ------------------------------------- |
| `blockchain`     | `VARCHAR`   | Blockchain                            |
| `block_month`    | `DATE`      | Block month                           |
| `block_time`     | `TIMESTAMP` | Block timestamp                       |
| `block_number`   | `BIGINT`    | Block number                          |
| `cex_name`       | `VARCHAR`   | Centralized exchange name             |
| `distinct_name`  | `VARCHAR`   | Distinct name of the CEX address      |
| `token_address`  | `VARBINARY` | Token contract address                |
| `token_symbol`   | `VARCHAR`   | Token symbol                          |
| `token_standard` | `VARCHAR`   | Token standard                        |
| `flow_type`      | `VARCHAR`   | Flow type (deposit or withdrawal)     |
| `amount`         | `DOUBLE`    | Token amount                          |
| `amount_raw`     | `UINT256`   | Raw token amount                      |
| `amount_usd`     | `DOUBLE`    | USD value                             |
| `from`           | `VARBINARY` | Sender address                        |
| `to`             | `VARBINARY` | Recipient address                     |
| `tx_from`        | `VARBINARY` | Address that executed the transaction |
| `tx_to`          | `VARBINARY` | Address the transaction points to     |
| `tx_index`       | `BIGINT`    | Transaction index                     |
| `tx_hash`        | `VARBINARY` | Transaction hash                      |
| `evt_index`      | `BIGINT`    | Event index                           |
| `unique_key`     | `VARCHAR`   | Unique transfer identifier            |

## Table sample

<TableSample />


# CEX Flows
Source: https://docs.dune.com/data-catalog/curated/cex-flows/overview

Curated centralized exchange flow datasets across 29 chains on Dune

Dune's CEX (Centralized Exchange) tables identify known exchange addresses across 29 chains, track token flows in and out of exchanges, and detect user deposit addresses through on-chain consolidation pattern analysis.

<Info>
  **Maintained by:** Dune · **Refresh:** \~1 hour · **Chains:** 29 (addresses), 21 EVM (flows)
</Info>

<Card title="Get This Data" icon="database" href="https://dune.com/enterprise?dataset=cex-flows">
  Access CEX flow data via API, Datashare, or the Dune App.
</Card>

## Available Tables

<CardGroup>
  <Card title="cex.flows" icon="database" href="/data-catalog/curated/cex-flows/flows">
    All token flows to/from identified CEX addresses on EVM chains
  </Card>

  <Card title="cex.addresses" icon="database" href="/data-catalog/curated/cex-flows/addresses">
    All identified CEX-controlled addresses across 29 chains (including non-EVM)
  </Card>

  <Card title="cex.deposit_addresses" icon="database" href="/data-catalog/curated/cex-flows/deposit_addresses">
    Programmatically detected user deposit addresses
  </Card>
</CardGroup>

## When to Use These Tables

* Monitor exchange inflows and outflows for market sentiment analysis
* Track specific token flows to/from exchanges
* Identify exchange-controlled addresses for compliance or analytics
* Detect user deposit addresses programmatically
* Analyze exchange reserve changes over time

## Coverage

**cex.addresses (29 chains):** Ethereum, BNB Chain, Avalanche C-Chain, Optimism, Arbitrum, Polygon, Bitcoin, Fantom, Aptos, Celo, Zora, zkSync, zkEVM, Linea, Solana, Scroll, Tron, Base, Mantle, Worldchain, Sei, Berachain, Ink, Katana, Kaia, Nova, opBNB, Unichain, Sui

**cex.flows (21 EVM chains):** Ethereum, BNB Chain, Avalanche C-Chain, Gnosis, Optimism, Arbitrum, Polygon, Base, Celo, Zora, zkSync, Scroll, Fantom, Linea, zkEVM, Berachain, Ink, Katana, Nova, opBNB, Unichain

**Exchanges:** Major centralized exchanges with identified hot wallets and deposit addresses. Additional exchanges can be added upon request for enterprise customers.

<Info>
  **Need coverage for additional exchanges?** We can add new exchange address identification upon request. [Contact our enterprise team →](https://dune.com/enterprise)
</Info>

## Query Performance

`cex.flows` uses `block_month` for incremental processing. Always filter on time range and optionally `blockchain`.

```sql theme={null}
-- ✅ Good: time-bounded with chain filter
SELECT * FROM cex.flows
WHERE blockchain = 'ethereum'
  AND block_time >= NOW() - INTERVAL '7' DAY
  AND cex_name = 'Binance'

-- ❌ Slow: no time filter
SELECT * FROM cex.flows
WHERE cex_name = 'Coinbase'
```

## Methodology

CEX tables are maintained by Dune ([source code](https://github.com/duneanalytics/spellbook)).

`cex.addresses` aggregates known CEX addresses from manually curated seed files across chain-specific models. Each address record includes who added it and when.

`cex.flows` joins identified CEX addresses with token transfer events to classify each transfer as an inflow (to exchange) or outflow (from exchange), enriched with token metadata and USD pricing.

`cex.deposit_addresses` uses on-chain heuristics to detect user-specific deposit addresses: it identifies addresses that receive tokens from external wallets and then consolidate those tokens to known CEX hot wallets — a pattern characteristic of exchange deposit addresses.

## Example Queries

**Daily CEX net flows by exchange (Ethereum):**

```sql theme={null}
SELECT
  date_trunc('day', block_time) AS day,
  cex_name,
  SUM(CASE WHEN flow_type = 'inflow' THEN amount_usd ELSE 0 END) AS inflows_usd,
  SUM(CASE WHEN flow_type = 'outflow' THEN amount_usd ELSE 0 END) AS outflows_usd,
  SUM(CASE WHEN flow_type = 'inflow' THEN amount_usd ELSE -amount_usd END) AS net_flow_usd
FROM cex.flows
WHERE blockchain = 'ethereum'
  AND block_time >= NOW() - INTERVAL '30' DAY
GROUP BY 1, 2
ORDER BY 1 DESC, 5 DESC
```

**Stablecoin flows to exchanges:**

```sql theme={null}
SELECT
  cex_name,
  token_symbol,
  SUM(CASE WHEN flow_type = 'inflow' THEN amount_usd ELSE 0 END) AS inflow_usd,
  SUM(CASE WHEN flow_type = 'outflow' THEN amount_usd ELSE 0 END) AS outflow_usd
FROM cex.flows
WHERE blockchain = 'ethereum'
  AND token_symbol IN ('USDT', 'USDC', 'DAI')
  AND block_time >= NOW() - INTERVAL '7' DAY
GROUP BY 1, 2
ORDER BY 3 DESC
```

## Related Tables

* `labels.addresses` — Broader address labeling beyond CEX
* `tokens.transfers` — Raw transfer data underlying CEX flow classification
* `staking_ethereum.deposits` — Staking data for CEX staking analysis

<CardGroup>
  <Card title="Enterprise Data Solutions" icon="building" href="https://dune.com/enterprise">
    Need custom exchange coverage or dedicated support? Talk to our enterprise team.
  </Card>

  <Card title="Build Custom Models" icon="code" href="/api-reference/connectors/overview">
    Build private exchange flow analytics with the dbt Connector.
  </Card>
</CardGroup>


# dex_aggregator.trades
Source: https://docs.dune.com/data-catalog/curated/dex-trades/evm/dex-aggregator-trades

The `dex_aggregator.trades` table captures data on actions taken on aggregators - recording all events across various aggregators and blockchains.

<Frame>
  <DuneEmbed />
</Frame>

<Frame>
  <DuneEmbed />
</Frame>

## Table Description

The `dex_aggregator.trades` table captures high-level trade data executed via decentralized exchange (DEX) aggregators. These aggregators aggregate liquidity from multiple DEXs to provide users with the best possible trade execution. Unlike the `dex.trades` table, which records each intermediary step of a trade, `dex_aggregator.trades` condenses the trade data to reflect the user's intended trade, presenting it as a single entry.

## Functional Overview

Users can expect the `dex_aggregator.trades` table to provide a high-level view of DEX trades facilitated by aggregators. This table simplifies trade records by showing a single entry for trades that may involve multiple DEXs and liquidity pools.\
For instance, a user might initiate a trade to swap USDC for PEPE via a DEX aggregator. The aggregator might route this trade through several liquidity pools such as WETH-USDC and WETH-PEPE, but `dex_aggregator.trades` will record it as a single USDC -> PEPE trade.

Complementary to `dex_aggregator.trades` is the `dex.trades` table, where detailed trade executions are recorded. This table captures the granular steps of each trade, including interactions with different liquidity pools. The volume routed through aggregators is also recorded in the `dex.trades` table. One row in `dex_aggregator.trades` corresponds to one or more rows in `dex.trades`, providing a comprehensive view of the detailed execution path that aggregated trades take.

## Coverage

The table covers the following decentralized exchanges and their versions:

<div>
  <DuneEmbed />
</div>

## Table Schema

| Column                     | Type            | Description                                               |
| -------------------------- | --------------- | --------------------------------------------------------- |
| `blockchain`               | `VARCHAR`       | Blockchain on which the DEX is deployed                   |
| `project`                  | `VARCHAR`       | Name of the aggregator project                            |
| `version`                  | `VARCHAR`       | Version of the contract built and deployed by the project |
| `block_date`               | `TIMESTAMP`     | UTC event block date                                      |
| `block_month`              | `TIMESTAMP`     | UTC event block month (partition key)                     |
| `block_time`               | `TIMESTAMP`     | UTC event block time                                      |
| `token_bought_symbol`      | `VARCHAR`       | Symbol of the token bought                                |
| `token_sold_symbol`        | `VARCHAR`       | Symbol of the token sold                                  |
| `token_pair`               | `VARCHAR`       | Token symbol pair for each token involved                 |
| `token_bought_amount`      | `DOUBLE`        | Amount of the token bought in display units               |
| `token_sold_amount`        | `DOUBLE`        | Amount of the token sold in display units                 |
| `token_bought_amount_raw`  | `UINT256`       | Raw amount of the token bought                            |
| `token_sold_amount_raw`    | `UINT256`       | Raw amount of the token sold                              |
| `amount_usd`               | `DOUBLE`        | USD value of the trade at time of execution               |
| `token_bought_address`     | `VARBINARY`     | Contract address of the token bought                      |
| `token_sold_address`       | `VARBINARY`     | Contract address of the token sold                        |
| `taker`                    | `VARBINARY`     | Address of trader who purchased tokens                    |
| `maker`                    | `VARBINARY`     | Address of trader who sold tokens                         |
| `project_contract_address` | `VARBINARY`     | Project contract address which executed the trade         |
| `tx_hash`                  | `VARBINARY`     | Transaction hash                                          |
| `tx_from`                  | `VARBINARY`     | Address which initiated the trade                         |
| `tx_to`                    | `VARBINARY`     | Address which received the trade                          |
| `trace_address`            | `ARRAY(BIGINT)` | Trace address within the transaction                      |
| `evt_index`                | `BIGINT`        | Index of the corresponding trade event                    |

## Table Sample

<TableSample />


# dex.sandwiched
Source: https://docs.dune.com/data-catalog/curated/dex-trades/evm/dex-sandwiched

The `dex.sandwiched` table captures detailed data on the victim trades of sandwich attacks in decentralized exchanges (DEXs), recording transactions that have been sandwiched across various EVM networks.

## Table Description

The `dex.sandwiched` table captures detailed data on the victim trades of sandwich attacks executed via decentralized exchanges (DEXs). This table records the transactions that have been sandwiched between front-running and back-running trades. It provides a comprehensive view of sandwich attack victims across various EVM networks.

## Functional Overview

The `dex.sandwiched` table provides an in-depth view of the victim trades in sandwich attacks on decentralized exchanges. A sandwich attack occurs when a trader (usually a bot) spots a pending transaction in the mempool, quickly executes a trade before it (front-running), and then immediately after it (back-running) to profit from the price movement caused by the victim's trade.

This table includes entries for:

1. The victim trade that has been sandwiched

Note that the front-running and back-running trades that sandwich these victim trades are captured in a separate table, `dex.sandwiches`.

This detailed approach allows for granular analysis of sandwich attack patterns, enabling users to:

* **Identify Sandwich Attack Victims**: Easily spot instances of trades that have been sandwiched across different DEXs and networks.
* **Analyze Attack Impacts**: Understand the frequency, size, and potential losses of sandwiched trades.
* **Monitor Market Vulnerability**: Gain insights into which trades are most susceptible to sandwich attacks across different DEXs and EVM networks.

By providing comprehensive details of the victim trades in sandwich attacks, the `dex.sandwiched` table supports advanced analytics and research into DEX trading behavior, market manipulation, and potential areas for improved trade execution or protocol design to protect users from sandwich attacks.

## Table Schema

| Column                     | Type        | Description                                                    |
| -------------------------- | ----------- | -------------------------------------------------------------- |
| `blockchain`               | `VARCHAR`   | Blockchain on which this trade occurred                        |
| `project`                  | `VARCHAR`   | Name of the DEX on which the trade occurred                    |
| `version`                  | `VARCHAR`   | Version of the DEX protocol/contract                           |
| `block_time`               | `TIMESTAMP` | UTC event block time                                           |
| `block_month`              | `DATE`      | UTC event block month (partition key)                          |
| `block_number`             | `BIGINT`    | Block number in which the trade occurred                       |
| `token_sold_address`       | `VARBINARY` | Contract address of the token sold                             |
| `token_bought_address`     | `VARBINARY` | Contract address of the token bought                           |
| `token_sold_symbol`        | `VARCHAR`   | Symbol of the token sold                                       |
| `token_bought_symbol`      | `VARCHAR`   | Symbol of the token bought                                     |
| `maker`                    | `VARBINARY` | Address that sold tokens (can be contract or EOA)              |
| `taker`                    | `VARBINARY` | Address that purchased tokens (can be contract or EOA)         |
| `tx_hash`                  | `VARBINARY` | Transaction hash                                               |
| `tx_from`                  | `VARBINARY` | EOA address that sent the transaction                          |
| `tx_to`                    | `VARBINARY` | Address called in the first call of this transaction           |
| `project_contract_address` | `VARBINARY` | Smart contract address which emitted the trade event           |
| `token_pair`               | `VARCHAR`   | Symbol pair for the tokens involved, always alphabetical order |
| `tx_index`                 | `BIGINT`    | Index of the transaction in the block                          |
| `token_sold_amount_raw`    | `UINT256`   | Raw amount of the token sold                                   |
| `token_bought_amount_raw`  | `UINT256`   | Raw amount of the token bought                                 |
| `token_sold_amount`        | `DOUBLE`    | Amount of the token sold in display units                      |
| `token_bought_amount`      | `DOUBLE`    | Amount of the token bought in display units                    |
| `amount_usd`               | `DOUBLE`    | USD value of the trade at time of execution                    |
| `evt_index`                | `BIGINT`    | Index of the event in the transaction                          |

## Table Sample

<TableSample />

## Related Tables

* `dex.sandwiches`: This complementary table captures the front-running and back-running trades that sandwich the victim trades recorded in `dex.sandwiched`.
* `dex.trades`: This table captures all trades and is the basis for the `dex.sandwiched` table.


# dex.sandwiches
Source: https://docs.dune.com/data-catalog/curated/dex-trades/evm/dex-sandwiches

The `dex.sandwiches` table captures detailed data on the outer trades of sandwich attacks in decentralized exchanges (DEXs), recording front-running and back-running trades across various EVM networks.

## Table Description

The `dex.sandwiches` table captures detailed data on the outer trades of sandwich attacks executed via decentralized exchanges (DEXs). This table records the trades that constitute the "bread" of the sandwich attack, which can include both front-running and back-running trades, as well as more complex patterns. It provides a comprehensive view of sandwich attack patterns across various EVM networks.

## Functional Overview

The `dex.sandwiches` table provides an in-depth view of the outer trades in sandwich attacks on decentralized exchanges. A sandwich attack typically occurs when a searcher spots a pending transaction in the mempool, quickly executes a trade before it (front-running), and then immediately after it (back-running) to profit from the price movement caused by the victim's trade.

However, this table also captures more complex sandwich attack patterns. For example:

bot1: ETH>USDC
victim1: USDC>ETH
bot1: USDC>ETH
victim2: ETH>USDC
bot1: ETH>USDC

In this scenario, the bot executes trades on both sides of the liquidity pool, sandwiching multiple victim trades in a single sequence.

This table includes entries for all bot trades involved in these attack patterns.

Note that the victim trades sandwiched between these outer trades are captured in a separate table, `dex.sandwiched`.

This detailed approach allows for granular analysis of sandwich attack patterns, enabling users to:

* **Identify Sandwich Attacks**: Easily spot instances of sandwich attacks across different DEXs and networks, including complex multi-trade patterns.
* **Analyze Attack Patterns**: Understand the frequency, size, and potential profitability of sandwich attacks, including sophisticated strategies that target multiple victims in a single sequence.
* **Monitor Market Manipulation**: Gain insights into various forms of market manipulation across different DEXs and EVM networks.

By providing comprehensive details of the trades involved in sandwich attacks, the `dex.sandwiches` table supports advanced analytics and research into DEX trading behavior, market manipulation, and potential areas for improved trade execution or protocol design.

## Table Schema

| Column                     | Type        | Description                                                    |
| -------------------------- | ----------- | -------------------------------------------------------------- |
| `blockchain`               | `VARCHAR`   | Blockchain on which this trade occurred                        |
| `project`                  | `VARCHAR`   | Name of the DEX on which the trade occurred                    |
| `version`                  | `VARCHAR`   | Version of the DEX protocol/contract                           |
| `block_time`               | `TIMESTAMP` | UTC event block time                                           |
| `block_month`              | `DATE`      | UTC event block month (partition key)                          |
| `block_number`             | `BIGINT`    | Block number in which the trade occurred                       |
| `token_sold_address`       | `VARBINARY` | Contract address of the token sold                             |
| `token_bought_address`     | `VARBINARY` | Contract address of the token bought                           |
| `token_sold_symbol`        | `VARCHAR`   | Symbol of the token sold                                       |
| `token_bought_symbol`      | `VARCHAR`   | Symbol of the token bought                                     |
| `maker`                    | `VARBINARY` | Address that sold tokens (can be contract or EOA)              |
| `taker`                    | `VARBINARY` | Address that purchased tokens (can be contract or EOA)         |
| `tx_hash`                  | `VARBINARY` | Transaction hash                                               |
| `tx_from`                  | `VARBINARY` | EOA address that sent the transaction                          |
| `tx_to`                    | `VARBINARY` | Address called in the first call of this transaction           |
| `project_contract_address` | `VARBINARY` | Smart contract address which emitted the trade event           |
| `token_pair`               | `VARCHAR`   | Symbol pair for the tokens involved, always alphabetical order |
| `tx_index`                 | `BIGINT`    | Index of the transaction in the block                          |
| `token_sold_amount_raw`    | `UINT256`   | Raw amount of the token sold                                   |
| `token_bought_amount_raw`  | `UINT256`   | Raw amount of the token bought                                 |
| `token_sold_amount`        | `DOUBLE`    | Amount of the token sold in display units                      |
| `token_bought_amount`      | `DOUBLE`    | Amount of the token bought in display units                    |
| `amount_usd`               | `DOUBLE`    | USD value of the trade at time of execution                    |
| `evt_index`                | `BIGINT`    | Index of the event in the transaction                          |

## Table Sample

<TableSample />

## Examples

The following query demonstrates how to use the `dex.sandwiches` table to calculate the total volume of sandwich attack trades on a weekly basis.

```sql theme={null}
SELECT
  date_trunc('week', block_time) AS week,
  COUNT(*) AS sandwich_count,
  SUM(token_sold_amount_usd) AS total_volume_usd
FROM dex.sandwiches
WHERE blockchain = 'ethereum'
  AND block_time >= NOW() - INTERVAL '90' DAY
GROUP BY 1
ORDER BY 1
```

## Related Tables

* `dex.sandwiched`: This complementary table captures the victim trades that are sandwiched between the trades recorded in `dex.sandwiches`.
* `dex.trades`: This table captures all trades and is the basis for the `dex.sandwiches` table.


# dex.trades
Source: https://docs.dune.com/data-catalog/curated/dex-trades/evm/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols and blockchains.

<Frame>
  <DuneEmbed />
</Frame>

<Frame>
  <DuneEmbed />
</Frame>

## Table Description

The `dex.trades` table captures detailed data on trades executed via decentralized exchanges (DEXs). This table captures all raw trade events that happen across all liquidity pools. It provides a comprehensive view of the entire trade execution process, detailing the specific paths and liquidity sources utilized.

## Functional Overview

The `dex.trades` table provides an in-depth view of trades on decentralized exchanges like Uniswap or Curve. This table includes entries for each segment of a trade that passes through different liquidity pools, as well as single-step trades. For example, a user may initiate a trade to swap USDC for PEPE. If this trade is executed through multiple liquidity pools, such as USDC-WETH and WETH-PEPE, the `dex.trades` table will record each segment of the trade as a separate entry. Conversely, a single-step trade, such as directly swapping USDC for ETH, will be recorded as a single entry.

This detailed approach allows for granular analysis of trade execution paths, enabling users to:

* **Analyze Liquidity Sources**: Understand which liquidity pools are used and how they interact in both single-step and multi-step trades.
* **Track Trade Execution Paths**: Follow the exact route a trade takes across different DEXs and liquidity pools.
* **Assess Slippage and Execution Quality**: Evaluate the impact of each step on the overall trade execution, including slippage and price changes.
* **Monitor Market Dynamics**: Gain insights into the behavior and dynamics of different liquidity pools and DEXs over time.

By providing comprehensive trade details, the `dex.trades` table supports advanced analytics and research into DEX trading behavior and liquidity management.

Complementary tables include `dex_aggregator.trades`, in which trade-intents that are routed through aggregators are recorded. The volume routed through aggregators is also recorded in the dex.trades table, one row in dex\_aggregator trades corresponds to one or more rows in dex.trades.

## Coverage

The table covers the following decentralized exchanges and their versions:

<div>
  <DuneEmbed />
</div>

## Table Schema

| Column                     | Type        | Description                                                         |
| -------------------------- | ----------- | ------------------------------------------------------------------- |
| `blockchain`               | `VARCHAR`   | Blockchain on which this trade occurred                             |
| `project`                  | `VARCHAR`   | Name of the DEX on which the trade occurred                         |
| `version`                  | `VARCHAR`   | Version of the DEX protocol/contract                                |
| `block_month`              | `DATE`      | UTC event block month (partition key)                               |
| `block_date`               | `DATE`      | UTC event block date                                                |
| `block_time`               | `TIMESTAMP` | UTC event block time                                                |
| `block_number`             | `BIGINT`    | Block number in which the trade occurred                            |
| `token_bought_symbol`      | `VARCHAR`   | Symbol of the token bought                                          |
| `token_sold_symbol`        | `VARCHAR`   | Symbol of the token sold                                            |
| `token_pair`               | `VARCHAR`   | Symbol pair for the tokens involved, always alphabetical order      |
| `token_bought_amount`      | `DOUBLE`    | Amount of the token bought in display units                         |
| `token_sold_amount`        | `DOUBLE`    | Amount of the token sold in display units                           |
| `token_bought_amount_raw`  | `UINT256`   | Raw amount of the token bought before decimal adjustment            |
| `token_sold_amount_raw`    | `UINT256`   | Raw amount of the token sold before decimal adjustment              |
| `amount_usd`               | `DOUBLE`    | USD value of the trade at time of execution                         |
| `token_bought_address`     | `VARBINARY` | Contract address of the token bought                                |
| `token_sold_address`       | `VARBINARY` | Contract address of the token sold                                  |
| `taker`                    | `VARBINARY` | Address that purchased tokens (can be contract or EOA)              |
| `maker`                    | `VARBINARY` | Address that sold tokens (can be contract or EOA)                   |
| `project_contract_address` | `VARBINARY` | Smart contract address which emitted the event (pool, router, etc.) |
| `tx_hash`                  | `VARBINARY` | Transaction hash                                                    |
| `tx_from`                  | `VARBINARY` | EOA address that sent the trade transaction                         |
| `tx_to`                    | `VARBINARY` | Address called in the first call of this transaction                |
| `evt_index`                | `BIGINT`    | Index of the event in the transaction                               |

## Table Sample

<TableSample />

## Examples

The following query demonstrates how to use the dex.trades table to calculate the total volume of trades on a weekly basis.

```sql theme={null}
SELECT
  blockchain,
  DATE_TRUNC('week', block_time),
  SUM(CAST(amount_usd AS DOUBLE)) AS usd_volume
FROM
  dex."trades" AS t
WHERE
 block_time > NOW() - INTERVAL '365' day
GROUP BY 1,2
```

<div>
  <DuneEmbed />
</div>

<CardGroup>
  <Card title="Dex Dashboard" icon="chart-waterfall" href="https://dune.com/dune/dex-metrics">
    For more examples of how to use the `dex.trades` table, check out this dashboard.
  </Card>
</CardGroup>


# DEX Data
Source: https://docs.dune.com/data-catalog/curated/dex-trades/overview

Curated DEX trading data across multiple blockchain networks

Decentralized exchanges (DEXs) have become a cornerstone of DeFi, enabling permissionless trading of tokens directly on-chain. Dune provides comprehensive coverage of DEX activity through curated tables that capture trades, aggregator usage, and MEV events like sandwich attacks across both EVM and Solana networks. These datasets enable analysis of trading volumes, liquidity dynamics, price impact, and market manipulation across major DEX protocols and networks.

<Info>
  **Maintained by:** Dune · **Refresh:** \~30 min · **Chains:** 50 EVM chains, Solana
</Info>

<Card title="Get This Data" icon="database" href="https://dune.com/enterprise?dataset=dex.trades">
  Access DEX trading data via API, Datashare, or the Dune App.
</Card>

## Cross-Chain DEX Coverage

Our DEX data covers multiple blockchain ecosystems:

* **EVM Networks**: Ethereum, Arbitrum, Polygon, Base, Optimism, and 50 EVM chains total
* **Solana**: Comprehensive coverage of Solana DEX protocols and Jupiter aggregator

## Available Datasets

### EVM DEX Data

<CardGroup>
  <Card title="DEX Trades" icon="arrow-right-arrow-left" href="/data-catalog/curated/dex-trades/evm/dex-trades">
    Individual trades across DEX protocols like Uniswap, SushiSwap, Curve and more
  </Card>

  <Card title="Aggregator Trades" icon="shuffle" href="/data-catalog/curated/dex-trades/evm/dex-aggregator-trades">
    Trades routed through aggregators like 1inch, 0x Protocol, ParaSwap
  </Card>

  <Card title="Sandwich Attacks" icon="bread-slice" href="/data-catalog/curated/dex-trades/evm/dex-sandwiches">
    Detected sandwich attack trades and their details
  </Card>

  <Card title="Sandwiched Trades" icon="user-injured" href="/data-catalog/curated/dex-trades/evm/dex-sandwiched">
    Transactions that were victims of sandwich attacks
  </Card>
</CardGroup>

### Solana DEX Data

<CardGroup>
  <Card title="Solana DEX Trades" icon="handshake" href="/data-catalog/curated/dex-trades/solana/solana-dex-trades">
    Detailed trade data across Solana DEX protocols like Orca, Raydium, and more
  </Card>

  <Card title="Jupiter Aggregator" icon="layer-group" href="/data-catalog/curated/dex-trades/solana/jupiter-aggregator-trades">
    Trades executed through the Jupiter aggregator on Solana
  </Card>
</CardGroup>

## Key Features

* **Multi-Chain Coverage**: Analyze DEX activity across EVM and Solana ecosystems
* **Standardized Schema**: Consistent data structure for cross-chain analysis
* **MEV Detection**: Identify sandwich attacks and other MEV activities (EVM)
* **Aggregator Data**: Track trades through major aggregators on both networks
* **Real-time Updates**: Data is updated continuously as new blocks are processed

## Sample Cross-Chain Analysis

Compare DEX trading volume across different blockchain networks:

```sql theme={null}
-- EVM DEX volume
SELECT 
    'EVM' as ecosystem,
    blockchain,
    DATE_TRUNC('day', block_time) as date,
    SUM(amount_usd) as volume_usd
FROM dex.trades
WHERE block_time >= NOW() - INTERVAL '30' day
GROUP BY 1, 2, 3

UNION ALL

-- Solana DEX volume  
SELECT 
    'Solana' as ecosystem,
    'solana' as blockchain,
    DATE_TRUNC('day', block_time) as date,
    SUM(amount_usd) as volume_usd
FROM dex_solana.trades
WHERE block_time >= NOW() - INTERVAL '30' day
GROUP BY 1, 2, 3

ORDER BY date DESC, volume_usd DESC
```

## When to Use These Tables

* Analyze DEX trading volumes and market share across protocols and chains
* Track token price impact and liquidity depth on specific pairs
* Monitor MEV activity (sandwich attacks) and their cost to traders
* Build DEX aggregator performance benchmarks
* Compare DEX activity across L1s and L2s for ecosystem analysis

## Query Performance

**Partition keys for `dex.trades`:** `blockchain`, `project`, `block_month`

Always include `blockchain` and a time filter (`block_month` or `block_time` range) for best performance.

```sql theme={null}
-- ✅ Good: partition key filters
SELECT * FROM dex.trades
WHERE blockchain = 'ethereum'
  AND block_month >= DATE '2025-01-01'
  AND project = 'uniswap'

-- ❌ Slow: no partition filters
SELECT * FROM dex.trades
WHERE token_bought_symbol = 'USDC'
```

## Methodology

DEX tables are maintained by Dune ([source code](https://github.com/duneanalytics/spellbook)). They aggregate data from protocol-specific base models (e.g., `uniswap_v3_ethereum.trades`, `curve_ethereum.trades`) that decode swap events from each DEX's smart contracts. Token amounts are decimal-adjusted and joined with Dune's price feeds for USD values. The `dex.trades` union view combines all EVM chain models; `dex_solana.trades` covers Solana DEXs separately.

## Example Queries

**Daily DEX volume by protocol on Ethereum (last 30 days):**

```sql theme={null}
SELECT
  date_trunc('day', block_time) AS day,
  project,
  SUM(amount_usd) AS volume_usd,
  COUNT(*) AS num_trades
FROM dex.trades
WHERE blockchain = 'ethereum'
  AND block_month >= DATE '2025-01-01'
  AND block_time >= NOW() - INTERVAL '30' DAY
GROUP BY 1, 2
ORDER BY 1 DESC, 3 DESC
```

**Top traded pairs on Uniswap v3 (last 7 days):**

```sql theme={null}
SELECT
  token_bought_symbol,
  token_sold_symbol,
  SUM(amount_usd) AS volume_usd,
  COUNT(*) AS num_trades
FROM dex.trades
WHERE blockchain = 'ethereum'
  AND project = 'uniswap'
  AND project_version = '3'
  AND block_time >= NOW() - INTERVAL '7' DAY
GROUP BY 1, 2
ORDER BY 3 DESC
LIMIT 20
```

## Related Tables

* `prices.day` / `prices.hour` / `prices.minute` — Token pricing feeds used for USD values
* `tokens.erc20` — Token metadata (symbols, decimals, contract addresses)
* `nft.trades` — NFT marketplace trades (separate from fungible token DEX trades)
* `dex.sandwiches` — MEV sandwich attack data

<CardGroup>
  <Card title="Enterprise Data Solutions" icon="building" href="https://dune.com/enterprise">
    Need custom DEX datasets or dedicated support? Talk to our enterprise team.
  </Card>

  <Card title="Build Custom Models" icon="code" href="/api-reference/connectors/overview">
    Build private DEX analytics pipelines with the dbt Connector.
  </Card>
</CardGroup>


# jupiter_solana.aggregator_swaps
Source: https://docs.dune.com/data-catalog/curated/dex-trades/solana/jupiter-aggregator-trades

The `jupiter_solana.aggregator_swaps` table captures data on trades executed through the Jupiter aggregator on Solana.

## Table Description

The `jupiter_solana.aggregator_swaps` table captures high-level trade data executed via the Jupiter decentralized exchange (DEX) aggregator on Solana. Jupiter is the most important and only relevant aggregator on Solana, providing users with the best possible trade execution by aggregating liquidity from multiple DEXs.

## Functional Overview

Users can expect the `jupiter_solana.aggregator_swaps` table to provide a comprehensive view of DEX trades facilitated by Jupiter on Solana. This table records each trade as a single entry, showing the user's intended swap from input token to output token.

For instance, a user might initiate a trade to swap USDC for SOL via Jupiter. The aggregator might route this trade through several liquidity pools, but `jupiter_solana.aggregator_swaps` will record it as a single USDC -> SOL trade, including details such as the amounts, USD values, and the specific AMM used for the swap.

## Coverage

This table covers all trades executed through the Jupiter aggregator on Solana, which includes liquidity from various Solana-based DEXs and AMMs.

## Table Schema

| Column            | Type        | Description                                 |
| ----------------- | ----------- | ------------------------------------------- |
| `amm`             | `VARCHAR`   | Program ID of the AMM routed through        |
| `amm_name`        | `VARCHAR`   | Name of the AMM routed through              |
| `token_pair`      | `VARCHAR`   | Token pair routed through                   |
| `input_symbol`    | `VARCHAR`   | Symbol of the token sold                    |
| `input_mint`      | `VARCHAR`   | Mint address of the token sold              |
| `input_amount`    | `BIGINT`    | Raw amount of the token sold                |
| `input_decimals`  | `BIGINT`    | Decimals of the token sold                  |
| `input_usd`       | `DOUBLE`    | USD value of the token sold                 |
| `output_symbol`   | `VARCHAR`   | Symbol of the token bought                  |
| `output_mint`     | `VARCHAR`   | Mint address of the token bought            |
| `output_amount`   | `BIGINT`    | Raw amount of the token bought              |
| `output_usd`      | `DOUBLE`    | USD value of the token bought               |
| `output_decimals` | `BIGINT`    | Decimals of the token bought                |
| `log_index`       | `BIGINT`    | Ordering of the swap within the transaction |
| `tx_id`           | `VARCHAR`   | Transaction ID                              |
| `block_slot`      | `BIGINT`    | Block slot number                           |
| `block_time`      | `TIMESTAMP` | UTC block time                              |
| `block_month`     | `DATE`      | Block month (partition key)                 |
| `tx_signer`       | `VARCHAR`   | Signer of the transaction                   |
| `jup_version`     | `INTEGER`   | Version of the Jupiter aggregator used      |

## Table Sample

<TableSample />


# Trading
Source: https://docs.dune.com/data-catalog/curated/dex-trades/solana/overview

Analyzing trading activity across Solana's decentralized exchanges.

The Solana blockchain hosts various decentralized exchanges (DEXs) and trading protocols that facilitate token swaps and trading activities. Dune provides comprehensive trading data through prepared tables that capture trades across different DEX protocols and aggregators on the Solana network.

<Info>
  **Maintained by:** Dune · **Refresh:** \~3 hours · **Chain:** Solana
</Info>

## Tables

<CardGroup>
  <Card title="DEX Trades" icon="handshake" href="/data-catalog/curated/dex-trades/solana/solana-dex-trades">
    Detailed trade data across Solana DEX protocols
  </Card>

  <Card title="Jupiter Aggregator" icon="layer-group" href="/data-catalog/curated/dex-trades/solana/jupiter-aggregator-trades">
    Trades executed through the Jupiter aggregator
  </Card>
</CardGroup>

## Key Features

The trading tables provide essential data for analyzing Solana's DEX ecosystem:

* Comprehensive coverage of major DEX protocols
* Detailed trade execution data including amounts, prices, and USD values
* Aggregator-specific data for Jupiter trades
* Transaction and block details for each trade

## Common Use Cases

These datasets enable various types of trading analysis:

* Track trading volume across different DEX protocols
* Monitor market activity for specific token pairs
* Analyze price impact and slippage in trades
* Compare performance between different DEXs and aggregators
* Identify trading patterns and trends

## Sample Query

Here's a simple query to get started analyzing DEX trading volume:

```sql theme={null}
SELECT 
    DATE_TRUNC('day', block_time) as date,
    project,
    COUNT(*) as num_trades,
    SUM(amount_usd) as volume_usd
FROM dex_solana.trades
WHERE block_time >= NOW() - INTERVAL '30' day
GROUP BY 1, 2
ORDER BY 1 DESC, 4 DESC
```

These datasets provide valuable insights into trading activity across the Solana ecosystem, enabling users to understand market dynamics and analyze trading patterns on the network.


# dex_solana.trades
Source: https://docs.dune.com/data-catalog/curated/dex-trades/solana/solana-dex-trades

The `dex_solana.trades` table captures detailed data on decentralized exchange (DEX) trades on the Solana blockchain, recording all raw trade events across various protocols.

## Table Description

The `dex_solana.trades` table captures detailed data on trades executed via decentralized exchanges (DEXs) on the Solana blockchain. This table records all raw trade events that occur across all liquidity pools on Solana DEXs, providing a comprehensive view of the entire trade execution process and detailing the specific paths and liquidity sources utilized.

## Functional Overview

The `dex_solana.trades` table provides an in-depth view of trades on Solana-based decentralized exchanges like Raydium, Orca, or Serum. This table includes entries for each segment of a trade that passes through different liquidity pools, as well as single-step trades. For example, a user may initiate a trade to swap USDC for RAY. If this trade is executed through multiple liquidity pools, such as USDC-SOL and SOL-RAY, the `dex_solana.trades` table will record each segment of the trade as a separate entry. Conversely, a single-step trade, such as directly swapping USDC for SOL, will be recorded as a single entry.

This detailed approach allows for granular analysis of trade execution paths on Solana, enabling users to:

* **Analyze Liquidity Sources**: Understand which liquidity pools are used and how they interact in both single-step and multi-step trades on Solana DEXs.
* **Track Trade Execution Paths**: Follow the exact route a trade takes across different Solana DEXs and liquidity pools.
* **Assess Slippage and Execution Quality**: Evaluate the impact of each step on the overall trade execution, including slippage and price changes in the Solana ecosystem.
* **Monitor Market Dynamics**: Gain insights into the behavior and dynamics of different liquidity pools and DEXs over time on the Solana blockchain.

By providing comprehensive trade details, the `dex_solana.trades` table supports advanced analytics and research into DEX trading behavior and liquidity management specific to the Solana ecosystem.

## Coverage

<div>
  <DuneEmbed />
</div>

## Table Schema

| Column                      | Type        | Description                                                                      |
| --------------------------- | ----------- | -------------------------------------------------------------------------------- |
| `blockchain`                | `VARCHAR`   | Blockchain (always `solana`)                                                     |
| `project`                   | `VARCHAR`   | Name of the DEX protocol                                                         |
| `version`                   | `INTEGER`   | Version of the contract                                                          |
| `version_name`              | `VARCHAR`   | Version name                                                                     |
| `block_month`               | `DATE`      | UTC event block month (partition key)                                            |
| `block_date`                | `DATE`      | UTC event block date                                                             |
| `block_time`                | `TIMESTAMP` | UTC event block time                                                             |
| `block_slot`                | `BIGINT`    | Block slot number                                                                |
| `trade_source`              | `VARCHAR`   | Whether the trade was a direct call or routed through an aggregator like Jupiter |
| `token_bought_symbol`       | `VARCHAR`   | Symbol of the token bought                                                       |
| `token_sold_symbol`         | `VARCHAR`   | Symbol of the token sold                                                         |
| `token_pair`                | `VARCHAR`   | Token symbol pair                                                                |
| `token_bought_amount`       | `DOUBLE`    | Amount of the token bought in display units                                      |
| `token_sold_amount`         | `DOUBLE`    | Amount of the token sold in display units                                        |
| `token_bought_amount_raw`   | `UINT256`   | Raw amount of the token bought                                                   |
| `token_sold_amount_raw`     | `UINT256`   | Raw amount of the token sold                                                     |
| `amount_usd`                | `DOUBLE`    | USD value of the trade at time of execution                                      |
| `fee_tier`                  | `DOUBLE`    | Pool fee tier (fee percentage)                                                   |
| `fee_usd`                   | `DOUBLE`    | Fee paid on swap in USD                                                          |
| `token_bought_mint_address` | `VARCHAR`   | Mint address of the token bought                                                 |
| `token_sold_mint_address`   | `VARCHAR`   | Mint address of the token sold                                                   |
| `token_bought_vault`        | `VARCHAR`   | Token vault address for the pool, of the token bought                            |
| `token_sold_vault`          | `VARCHAR`   | Token vault address for the pool, of the token sold                              |
| `project_program_id`        | `VARCHAR`   | Pool program ID of the DEX project                                               |
| `project_main_id`           | `VARCHAR`   | Project main ID                                                                  |
| `trader_id`                 | `VARCHAR`   | Address of the trader who initiated the swap                                     |
| `tx_id`                     | `VARCHAR`   | Transaction ID                                                                   |
| `outer_instruction_index`   | `INTEGER`   | Top-level instruction index for the transaction                                  |
| `inner_instruction_index`   | `INTEGER`   | Inner instruction index for the transaction                                      |
| `tx_index`                  | `INTEGER`   | Index of the transaction in the block slot                                       |

## Table Sample

<TableSample />

## Examples

The following query demonstrates how to use the `dex_solana.trades` table to calculate the total volume of trades on a weekly basis for Solana DEXs.

```sql theme={null}
SELECT
  DATE_TRUNC('week', block_time) AS week,
  SUM(CAST(amount_usd AS DOUBLE)) AS usd_volume
FROM
  dex_solana.trades
WHERE
  block_time > NOW() - INTERVAL '365' day
GROUP BY 1
ORDER BY 1
```

<CardGroup>
  <Card title="DEX Dashboard" icon="chart-waterfall" href="https://dune.com/hagaetc/dex-metrics">
    For more examples of how to use the `dex_solana.trades` table, check out this dashboard.
  </Card>
</CardGroup>


# gas.fees
Source: https://docs.dune.com/data-catalog/curated/gas-fees/fees

Transaction-level gas fee data across EVM chains — base fee, priority fee, L1/L2 breakdowns, and gas consumption.

The `gas.fees` table provides transaction-level gas fee data across 55 EVM chains, including fee breakdowns via the `tx_fee_breakdown` MAP column.

## Table Schema

| Column                 | Type                   | Description                                  |
| ---------------------- | ---------------------- | -------------------------------------------- |
| `blockchain`           | `VARCHAR`              | Blockchain name                              |
| `block_month`          | `DATE`                 | Block month (partition key)                  |
| `block_date`           | `DATE`                 | Block date                                   |
| `block_time`           | `TIMESTAMP`            | Block timestamp in UTC                       |
| `block_number`         | `BIGINT`               | Block number                                 |
| `tx_hash`              | `VARBINARY`            | Transaction hash                             |
| `tx_from`              | `VARBINARY`            | Address that initiated the transaction       |
| `tx_to`                | `VARBINARY`            | Address that received the transaction        |
| `gas_price`            | `UINT256`              | Gas price per unit in gwei                   |
| `gas_used`             | `BIGINT`               | Gas units consumed by the transaction        |
| `currency_symbol`      | `VARCHAR`              | Native token symbol for the blockchain       |
| `tx_fee`               | `DOUBLE`               | Total gas fee in native tokens               |
| `tx_fee_usd`           | `DOUBLE`               | Total gas fee in USD                         |
| `tx_fee_raw`           | `UINT256`              | Raw transaction fee                          |
| `tx_fee_breakdown`     | `MAP(VARCHAR,DOUBLE)`  | Fee breakdown in native tokens               |
| `tx_fee_breakdown_usd` | `MAP(VARCHAR,DOUBLE)`  | Fee breakdown in USD                         |
| `tx_fee_breakdown_raw` | `MAP(VARCHAR,UINT256)` | Raw fee breakdown                            |
| `tx_fee_currency`      | `VARBINARY`            | Fee currency address                         |
| `block_proposer`       | `VARBINARY`            | Block validator/proposer address             |
| `gas_limit`            | `UINT256`              | Maximum gas units allowed                    |
| `gas_limit_usage`      | `DOUBLE`               | Percentage of gas used relative to gas limit |

## Table sample

<TableSample />

## Query performance

Partition keys: `blockchain`, `block_month`, `block_date`. Always include `blockchain` and a date filter.

```sql theme={null}
-- ✅ Good: chain + date filter
SELECT * FROM gas.fees
WHERE blockchain = 'ethereum'
  AND block_date = CURRENT_DATE
```


# Gas & Fees
Source: https://docs.dune.com/data-catalog/curated/gas-fees/overview

Curated transaction fee datasets across 55+ EVM chains and Solana on Dune

Dune's gas tables provide transaction-level fee data across 55+ EVM chains and Solana, including fee breakdowns (base fee, priority fee, L1 data fee for L2s), gas pricing, and validator/proposer identification.

<Info>
  **Maintained by:** Dune · **Refresh:** \~10 min · **Chains:** 55 EVM + Solana
</Info>

<Card title="Get This Data" icon="database" href="https://dune.com/enterprise?dataset=gas.fees">
  Access gas fee data via API, Datashare, or the Dune App.
</Card>

## Available Tables

<CardGroup>
  <Card title="gas.fees" icon="database" href="/data-catalog/curated/gas-fees/fees">
    Transaction-level gas fees across 55 EVM chains
  </Card>

  <Card title="gas_solana.fees" icon="database" href="/data-catalog/curated/gas-fees/solana_fees">
    Transaction-level fees on Solana (including vote transactions)
  </Card>
</CardGroup>

## When to Use These Tables

* Analyze transaction costs across chains
* Compare gas pricing and fee structures between L1s and L2s
* Track fee revenue for validators and block proposers
* Understand fee breakdowns (base vs priority vs L1 data costs on rollups)
* Build gas cost estimators or optimize transaction timing

## Coverage

**gas.fees (55 EVM chains):**

<Accordion title="View all chains">
  Abstract, Apechain, Arbitrum, Avalanche C-Chain, B3, Base, Berachain, Blast, BNB Chain, Bob, Boba, Celo, Corn, Degen, Ethereum, Fantom, Flare, Gnosis, Hemi, Henesys, HyperEVM, Ink, Kaia, Katana, Lens, Linea, Mantle, MegaETH, Mezo, Monad, Nova, opBNB, Optimism, Peaq, Plasma, Plume, Polygon, Ronin, Scroll, Sei, Shape, Somnia, Sonic, Sophon, Story, Superseed, TAC, Taiko, Tron, Unichain, Worldchain, X Layer, zkEVM, zkSync, Zora
</Accordion>

**gas\_solana.fees:** Solana (includes vote transactions)

## Query Performance

`gas.fees` is a view over chain-specific incremental tables using `block_month` and `block_date` as partition keys.

```sql theme={null}
-- ✅ Good: chain + time filter
SELECT * FROM gas.fees
WHERE blockchain = 'ethereum'
  AND block_date = DATE '2025-02-01'

-- ✅ L2 analysis with month filter
SELECT * FROM gas.fees
WHERE blockchain = 'base'
  AND block_month >= DATE '2025-01-01'
```

## Methodology

Gas tables are maintained by Dune ([source code](https://github.com/duneanalytics/spellbook)). Each chain has its own underlying gas model reading from the chain's `transactions` table, enriched with native token pricing for USD values.

A key feature is the `tx_fee_breakdown` MAP column, which decomposes fees into their components. For L2s like Base, this breaks down into base fee, priority fee, and L1 data fee — enabling precise rollup cost analysis.

## Example Queries

**Average gas price by chain (today):**

```sql theme={null}
SELECT
  blockchain,
  AVG(tx_fee_usd) AS avg_fee_usd,
  APPROX_PERCENTILE(tx_fee_usd, 0.5) AS median_fee_usd,
  COUNT(*) AS num_transactions
FROM gas.fees
WHERE block_date = CURRENT_DATE
GROUP BY 1
ORDER BY 2 DESC
```

**L2 fee breakdown on Base (base fee vs L1 data cost):**

```sql theme={null}
SELECT
  date_trunc('day', block_time) AS day,
  SUM(tx_fee_breakdown['base_fee']) AS total_base_fee_eth,
  SUM(tx_fee_breakdown['l1_fee']) AS total_l1_fee_eth,
  SUM(tx_fee_usd) AS total_fee_usd
FROM gas.fees
WHERE blockchain = 'base'
  AND block_month >= DATE '2025-01-01'
GROUP BY 1
ORDER BY 1
```

## Related Tables

* `rollup_economics_ethereum.l1_fees` — Aggregate daily L1 posting costs per rollup
* `rollup_economics_ethereum.l2_revenue` — Aggregate daily gas revenue per rollup

<CardGroup>
  <Card title="Enterprise Data Solutions" icon="building" href="https://dune.com/enterprise">
    Need custom gas analytics or additional chain coverage? Talk to our enterprise team.
  </Card>

  <Card title="Build Custom Models" icon="code" href="/api-reference/connectors/overview">
    Build private gas fee analysis pipelines with the dbt Connector.
  </Card>
</CardGroup>


# gas_solana.fees
Source: https://docs.dune.com/data-catalog/curated/gas-fees/solana_fees

Solana transaction fee data — compute units, priority fees, and fee payer details per transaction.

The `gas_solana.fees` table provides transaction-level fee data on Solana, including compute unit pricing and vote/non-vote transaction classification.

## Table Schema

| Column                 | Type                  | Description                                           |
| ---------------------- | --------------------- | ----------------------------------------------------- |
| `blockchain`           | `VARCHAR`             | Blockchain (always solana)                            |
| `block_month`          | `DATE`                | Block month                                           |
| `block_date`           | `DATE`                | Block date                                            |
| `block_time`           | `TIMESTAMP`           | Block timestamp                                       |
| `block_slot`           | `BIGINT`              | Block slot number                                     |
| `tx_index`             | `INTEGER`             | Transaction index                                     |
| `tx_hash`              | `VARCHAR`             | Transaction hash                                      |
| `signer`               | `VARCHAR`             | Transaction signer address                            |
| `compute_unit_price`   | `DOUBLE`              | Compute unit price in lamports                        |
| `compute_limit`        | `BIGINT`              | Compute units used or limit set                       |
| `currency_symbol`      | `VARCHAR`             | Currency symbol (SOL)                                 |
| `tx_fee_raw`           | `BIGINT`              | Raw transaction fee in lamports                       |
| `tx_fee`               | `DOUBLE`              | Transaction fee in SOL                                |
| `tx_fee_usd`           | `DOUBLE`              | Transaction fee in USD                                |
| `tx_fee_breakdown_raw` | `MAP(VARCHAR,DOUBLE)` | Fee breakdown (base\_fee, prioritization\_fee) in raw |
| `tx_fee_breakdown`     | `MAP(VARCHAR,DOUBLE)` | Fee breakdown in SOL                                  |
| `tx_fee_breakdown_usd` | `MAP(VARCHAR,DOUBLE)` | Fee breakdown in USD                                  |
| `tx_fee_currency`      | `VARCHAR`             | Fee currency address                                  |
| `leader`               | `VARCHAR`             | Validator that proposed the block                     |
| `tx_type`              | `VARCHAR`             | Transaction type (vote or normal)                     |

## Table sample

<TableSample />

## Query performance

Filter on `block_date`. Use `tx_type = 'normal'` to exclude validator vote transactions from analysis.

```sql theme={null}
-- ✅ Good: date filter, non-vote only
SELECT * FROM gas_solana.fees
WHERE block_date = CURRENT_DATE
  AND tx_type = 'normal'
```


# labels.addresses
Source: https://docs.dune.com/data-catalog/curated/labels/address-labels

Comprehensive address labeling and attribution data — maps blockchain addresses to known entities, categories, and usage metrics across all supported chains

The `labels.addresses` table on Dune catalogs specific blockchain addresses, associating them with descriptive labels, categories, and usage metrics. This table is a superset of many other `labels.<category>` tables, providing a comprehensive overview of labeled addresses across various categories and blockchains.
You can use the `category` column to filter labels for the specific type of address you are interested in.

<Note>
  The `labels.addresses` table serves as a central repository for all labeled addresses on Dune, offering a consolidated view of labeled entities across different categories and blockchains.
</Note>

## Available Categories

Here are all the distinct category values available in the `labels.addresses` table:

<DuneEmbed />

## Table Schema

| Column        | Type        | Description                                         |
| ------------- | ----------- | --------------------------------------------------- |
| `blockchain`  | `VARCHAR`   | Blockchain the address belongs to                   |
| `address`     | `VARBINARY` | Labeled blockchain address                          |
| `name`        | `VARCHAR`   | Human-readable label name for the address           |
| `category`    | `VARCHAR`   | Label category (e.g., dex, cex, bridge, dao)        |
| `contributor` | `VARCHAR`   | Contributor(s) who created the label                |
| `source`      | `VARCHAR`   | How the label was generated (static or query-based) |
| `created_at`  | `DATE`      | When the label was created                          |
| `updated_at`  | `TIMESTAMP` | When the label was last updated                     |
| `model_name`  | `VARCHAR`   | Name of the label model sourced from                |
| `label_type`  | `VARCHAR`   | Type of label                                       |

## Table Sample

<TableSample />

## Example Query

The following SQL query demonstrates how to find addresses categorized under 'dex' within the Binance blockchain:

```sql theme={null}
SELECT
  address,
  name
FROM
  labels.addresses
WHERE
  category = 'dex' AND
  blockchain = 'bnb'
```


# labels.ens
Source: https://docs.dune.com/data-catalog/curated/labels/ens-labels

Ethereum Name Service (ENS) domain resolution data — links human-readable .eth names to blockchain addresses for identity verification and aggregation

The `labels.ens` table on Dune provides key information about Ethereum Name Service (ENS) domains and their associated addresses. This table is instrumental in linking human-readable names with blockchain addresses, aiding in identity verification and data aggregation within the Ethereum ecosystem.

## Table Schema

| Column        | Type        | Description                                         |
| ------------- | ----------- | --------------------------------------------------- |
| `blockchain`  | `VARCHAR`   | Blockchain (always Ethereum)                        |
| `address`     | `VARBINARY` | Resolved blockchain address                         |
| `name`        | `VARCHAR`   | ENS domain name (e.g., vitalik.eth)                 |
| `category`    | `VARCHAR`   | Label category                                      |
| `contributor` | `VARCHAR`   | Contributor(s) who created the label                |
| `source`      | `VARCHAR`   | How the label was generated (static or query-based) |
| `created_at`  | `DATE`      | When the label was created                          |
| `updated_at`  | `TIMESTAMP` | When the label was last updated                     |
| `model_name`  | `VARCHAR`   | Name of the label model sourced from                |
| `label_type`  | `VARCHAR`   | Type of label                                       |

## Table Sample

<TableSample />

## Example Query

The following SQL query demonstrates how to retrieve details for a specific ENS name within the Ethereum blockchain:

```sql theme={null}
SELECT
  address,
  name
FROM
  labels.ens
WHERE
  name = 'vitalik.eth'
```


# Labels Data
Source: https://docs.dune.com/data-catalog/curated/labels/overview

Labels provide valuable context and clarity to blockchain addresses, enhancing the readability and understanding of blockchain transaction data.

## Why Labels Matter

Labels are more than just simple tags or annotations. They provide valuable context and clarity to blockchain addresses, enhancing the readability and understanding of blockchain transaction data.

<Info>
  **Maintained by:** Dune · **Refresh:** N/A · **Chains:** Cross-chain
</Info>

<Card title="Get This Data" icon="database" href="https://dune.com/enterprise?dataset=labels">
  Access label data via API, Datashare, or the Dune App.
</Card>

In the world of blockchain analysis, labels play a crucial role in identifying and categorizing different entities and activities. They act as signposts, guiding analysts through the complex web of transactions and addresses, making it easier to identify the parties involved and their roles.

By mapping blockchain addresses to **known entities**, labels bring transparency to transaction analysis. They help distinguish between individuals, organizations, smart contracts, and other important actors in the blockchain ecosystem. This clarity is essential for compliance, risk assessment, and investigative purposes.

Labels also provide insights into the roles and functions of addresses, helping analysts understand the nature of transactions and the relationships between different entities in the blockchain ecosystem.

<div>
  <DuneEmbed />
</div>

## Labels datasets

We provide several label datasets that can be used to enrich your analysis:

<CardGroup>
  <Card title="All Labels" icon="maximize" href="/data-catalog/curated/labels/address-labels">
    A comprehensive collection of labeled addresses across various categories and blockchains, serving as a central repository for all labeled entities on Dune.
  </Card>

  <Card title="ENS Labels" icon="signature" href="/data-catalog/curated/labels/ens-labels">
    Ethereum Name Service (ENS) data linking human-readable names with blockchain addresses, facilitating easier interactions and identifications within the Ethereum ecosystem.
  </Card>

  <Card title="Owner Addresses" icon="house" href="/data-catalog/curated/labels/owner-addresses">
    Detailed mapping of blockchain addresses to their owners and custodians, providing insights into ownership and custody of assets across blockchains.
  </Card>

  <Card title="Owner Details" icon="info" href="/data-catalog/curated/labels/owner-details">
    Comprehensive information about entities within the ecosystem, including their operational profiles, categories, and online presence.
  </Card>
</CardGroup>

## When to Use These Tables

* Identify counterparties in transaction analysis (exchanges, protocols, DAOs)
* Enrich compliance workflows with entity attribution
* Build address reputation and risk scoring systems
* Resolve ENS names to blockchain addresses and vice versa
* Track protocol treasury and operational addresses

## Query Performance

`labels.addresses` is a large table. Always filter on `blockchain` and use additional filters where possible.

```sql theme={null}
-- ✅ Good: chain + category filter
SELECT * FROM labels.addresses
WHERE blockchain = 'ethereum'
  AND label_type = 'cex'

-- ❌ Slow: searching by label name across all chains
SELECT * FROM labels.addresses
WHERE name LIKE '%Binance%'
```

## Methodology

Labels are maintained by Dune ([source code](https://github.com/duneanalytics/spellbook)). They aggregate address identifications from multiple sources: manually curated seed files (exchanges, protocols, DAOs), automated contract analysis (factory-deployed contracts, proxy patterns), ENS domain resolution, and community contributions. Labels include entity names, categories (e.g., `cex`, `dex`, `dao`, `bridge`), and metadata about the source of identification.

## Example Queries

**Find all labeled Binance addresses on Ethereum:**

```sql theme={null}
SELECT
  address,
  name,
  label_type,
  model_name
FROM labels.addresses
WHERE blockchain = 'ethereum'
  AND name LIKE '%Binance%'
```

**Resolve ENS name to address:**

```sql theme={null}
SELECT
  address,
  name
FROM labels.ens
WHERE name = 'vitalik.eth'
```

## Related Tables

* `cex.addresses` — CEX-specific address identification (more targeted than labels)
* `tokens.transfers` — Transfer events enriched by label data
* `cex.flows` — Exchange flows that rely on label-identified addresses

<CardGroup>
  <Card title="Enterprise Data Solutions" icon="building" href="https://dune.com/enterprise">
    Need custom address labeling or dedicated support? Talk to our enterprise team.
  </Card>

  <Card title="Build Custom Models" icon="code" href="/api-reference/connectors/overview">
    Build private address intelligence pipelines with the dbt Connector.
  </Card>
</CardGroup>


# labels.owner_addresses
Source: https://docs.dune.com/data-catalog/curated/labels/owner-addresses

Owner-to-address mapping data — associates blockchain addresses with known entities for tracking ownership, contract deployments, and operational scope

The `labels.owner_addresses` table on Dune provides detailed data on blockchain addresses associated with various owners within the ecosystem, enhancing visibility into ownership distributions, contract deployments, and operational scopes. It’s a crucial tool for analysts to track ownership and custody of assets across blockchains.

<Tip>
  You can find more details on the account owners and custody owners in the `labels.owner_details` table.
</Tip>

## Table Schema

| Column                    | Type        | Description                              |
| ------------------------- | ----------- | ---------------------------------------- |
| `address`                 | `VARBINARY` | Blockchain address                       |
| `blockchain`              | `VARCHAR`   | Blockchain the address belongs to        |
| `owner_key`               | `VARCHAR`   | Unique key linking to owner\_details     |
| `custody_owner`           | `VARCHAR`   | Entity that has custody of the address   |
| `account_owner`           | `VARCHAR`   | Entity that owns the account             |
| `contract_name`           | `VARCHAR`   | Name of the deployed contract            |
| `contract_version`        | `VARCHAR`   | Version of the deployed contract         |
| `eoa`                     | `VARCHAR`   | Whether the address is an EOA            |
| `factory_contract`        | `VARCHAR`   | Factory contract used to deploy          |
| `source`                  | `VARCHAR`   | Source of the label data                 |
| `identifying_transaction` | `VARCHAR`   | Transaction used to identify the address |
| `algorithm_name`          | `VARCHAR`   | Algorithm used for identification        |
| `source_website`          | `VARCHAR`   | Website source for the label             |
| `source_evidence`         | `VARCHAR`   | Evidence supporting the label            |
| `created_at`              | `TIMESTAMP` | When the record was created              |
| `created_by`              | `VARCHAR`   | Who created the record                   |
| `updated_at`              | `TIMESTAMP` | When the record was last updated         |
| `updated_by`              | `VARCHAR`   | Who last updated the record              |

## Table Sample

<TableSample />

## Example Query

The following SQL query demonstrates how to retrieve details about addresses owned by 'Coinbase':

```sql theme={null}
SELECT
  *
FROM
  labels.owner_addresses
 where custody_owner = 'Coinbase'
```

The other way around is also possible, to find the custody owner of specific addresses. Here we match entities that have deposited assets to the `0x00000000219ab540356cBB839Cbe05303d7705Fa` address, which is the ETH 2.0 deposit contract.

```sql theme={null}
Select
  "from",
  "to",
  value,
  block_date,
  hash,
  custody_owner
from
  ethereum.transactions
  inner join labels.owner_addresses on "from" = labels.owner_addresses.address
where
  "to" = 0x00000000219ab540356cBB839Cbe05303d7705Fa
```

<div>
  <DuneEmbed />
</div>


# labels.owner_details
Source: https://docs.dune.com/data-catalog/curated/labels/owner-details

Entity profile data — operational details, categories, social presence, and technical profiles for known blockchain entities

The `labels.owner_details` table on Dune provides essential information about various entities within the ecosystem, detailing their operational, social, and technical profiles.

Data in this table is sourced from community contributions and official documentation, offering a comprehensive overview of the entities' activities, categories, and online presence. Analysts can leverage this data to track the latest developments, partnerships, and projects associated with specific entities.

<Tip>
  You can find addresses associated with the account owners and custody owners in the `labels.owner_addresses` table.
</Tip>

## Table Schema

| Column                  | Type             | Description                                              |
| ----------------------- | ---------------- | -------------------------------------------------------- |
| `name`                  | `VARCHAR`        | Entity name                                              |
| `owner_key`             | `VARCHAR`        | Unique key linking to owner\_addresses                   |
| `website`               | `VARCHAR`        | Entity website URL                                       |
| `dune_team`             | `VARCHAR`        | Associated Dune team                                     |
| `project_documentation` | `VARCHAR`        | Link to project documentation                            |
| `project_github_url`    | `VARCHAR`        | Link to project GitHub repository                        |
| `social`                | `VARCHAR`        | Social media links                                       |
| `primary_category`      | `VARCHAR`        | Primary business category (e.g., Decentralized Exchange) |
| `category_tags`         | `ARRAY(VARCHAR)` | Additional category tags                                 |
| `country_name`          | `VARCHAR`        | Country of incorporation or operation                    |
| `description`           | `VARCHAR`        | Brief entity description                                 |
| `created_at`            | `TIMESTAMP`      | When the record was created                              |
| `created_by`            | `VARCHAR`        | Who created the record                                   |
| `updated_at`            | `TIMESTAMP`      | When the record was last updated                         |
| `updated_by`            | `VARCHAR`        | Who last updated the record                              |

## Table Sample

<TableSample />

## Example Query

The following SQL query demonstrates how to retrieve basic information about entities categorized as 'Decentralized Exchange':

```sql theme={null}
SELECT
  name,
  website,
  primary_category
FROM
  labels.owner_details
WHERE
  primary_category = 'Decentralized Exchange'
```


# safe.safes_all
Source: https://docs.dune.com/data-catalog/curated/labels/safe-safes-all

All Safe (formerly Gnosis Safe) multisig wallet addresses across supported chains, with creation version and creation time.

The `safe.safes_all` table lists all deployed Safe multisig wallets across supported EVM chains. Each row represents a unique Safe contract with its creation metadata.

## Table Schema

| Column             | Type        | Description                              |
| ------------------ | ----------- | ---------------------------------------- |
| `blockchain`       | `VARCHAR`   | Blockchain on which the Safe is deployed |
| `address`          | `VARBINARY` | Safe contract address                    |
| `creation_version` | `VARCHAR`   | Initial Safe version during creation     |
| `block_date`       | `DATE`      | Date of Safe creation                    |
| `creation_time`    | `TIMESTAMP` | Datetime of Safe creation                |
| `tx_hash`          | `VARBINARY` | Transaction hash of Safe creation        |

## Table sample

<TableSample />


# lending.borrow
Source: https://docs.dune.com/data-catalog/curated/lending/borrow

DeFi borrowing events — borrows and repayments across major lending protocols with rates and collateral context.

The `lending.borrow` table contains all borrow-side transactions across DeFi lending protocols — borrows, repayments, and borrow-side liquidations — across 15+ EVM chains.

## Table Schema

| Column                     | Type        | Description                                     |
| -------------------------- | ----------- | ----------------------------------------------- |
| `blockchain`               | `VARCHAR`   | Blockchain name                                 |
| `project`                  | `VARCHAR`   | Lending protocol name                           |
| `version`                  | `VARCHAR`   | Protocol contract version                       |
| `transaction_type`         | `VARCHAR`   | Transaction type (borrow, repay, liquidation)   |
| `loan_type`                | `VARCHAR`   | Type of loan                                    |
| `symbol`                   | `VARCHAR`   | Token symbol                                    |
| `token_address`            | `VARBINARY` | Token contract address                          |
| `borrower`                 | `VARBINARY` | Borrower wallet address                         |
| `on_behalf_of`             | `VARBINARY` | Wallet address the tx was executed on behalf of |
| `repayer`                  | `VARBINARY` | Repayer wallet address                          |
| `liquidator`               | `VARBINARY` | Liquidator wallet address                       |
| `amount`                   | `DOUBLE`    | Token amount in display units                   |
| `amount_raw`               | `UINT256`   | Raw token amount                                |
| `amount_usd`               | `DOUBLE`    | Token amount in USD                             |
| `block_month`              | `TIMESTAMP` | Block month (partition key)                     |
| `block_time`               | `TIMESTAMP` | Block timestamp in UTC                          |
| `block_number`             | `BIGINT`    | Block number                                    |
| `project_contract_address` | `VARBINARY` | Protocol contract address                       |
| `tx_hash`                  | `VARBINARY` | Transaction hash                                |
| `evt_index`                | `INTEGER`   | Event index                                     |

## Table sample

<TableSample />

## Query performance

Partition keys: `blockchain`, `project`, `block_month`. Always include `blockchain` and a time filter.

```sql theme={null}
-- ✅ Good: filters on partition keys
SELECT * FROM lending.borrow
WHERE blockchain = 'ethereum'
  AND block_month >= DATE '2025-01-01'
```


# lending.flashloans
Source: https://docs.dune.com/data-catalog/curated/lending/flashloans

Flash loan executions across DeFi protocols — borrowed amounts, fees, and initiator details.

The `lending.flashloans` table contains all flash loan transactions across DeFi lending protocols.

## Table Schema

| Column                     | Type        | Description                   |
| -------------------------- | ----------- | ----------------------------- |
| `blockchain`               | `VARCHAR`   | Blockchain name               |
| `project`                  | `VARCHAR`   | Lending protocol name         |
| `version`                  | `VARCHAR`   | Protocol contract version     |
| `token_address`            | `VARBINARY` | Token contract address        |
| `symbol`                   | `VARCHAR`   | Token symbol                  |
| `recipient`                | `VARBINARY` | Flashloan recipient address   |
| `amount`                   | `DOUBLE`    | Token amount in display units |
| `amount_raw`               | `UINT256`   | Raw token amount              |
| `amount_usd`               | `DOUBLE`    | Token amount in USD           |
| `fee`                      | `DOUBLE`    | Flashloan fee amount          |
| `project_contract_address` | `VARBINARY` | Protocol contract address     |
| `block_month`              | `TIMESTAMP` | Block month (partition key)   |
| `block_time`               | `TIMESTAMP` | Block timestamp in UTC        |
| `block_number`             | `BIGINT`    | Block number                  |
| `tx_hash`                  | `VARBINARY` | Transaction hash              |
| `evt_index`                | `INTEGER`   | Event index                   |

## Table sample

<TableSample />

## Query performance

Partition keys: `blockchain`, `project`. Always include `blockchain` in your filter.


# lending.info
Source: https://docs.dune.com/data-catalog/curated/lending/info

DeFi lending market snapshots — supply rates, borrow rates, utilization, and total value locked by protocol and asset.

The `lending.info` table provides static metadata about lending protocols, including display names, flash loan support, and social handles.

## Table Schema

| Column           | Type      | Description                              |
| ---------------- | --------- | ---------------------------------------- |
| `project`        | `VARCHAR` | Lending protocol codename                |
| `name`           | `VARCHAR` | Lending protocol display name            |
| `has_flashloans` | `BOOLEAN` | Whether the protocol supports flashloans |
| `x_username`     | `VARCHAR` | Protocol's X (Twitter) username          |

## Table sample

<TableSample />


# Lending
Source: https://docs.dune.com/data-catalog/curated/lending/overview

Curated DeFi lending datasets across 15+ EVM chains on Dune

Dune's lending tables provide standardized data on DeFi lending protocol activity — supply (deposit/withdraw), borrow (borrow/repay/liquidation), and flash loans — across 15+ EVM chains. All major lending protocols are aggregated into a single schema.

<Info>
  **Maintained by:** Dune · **Refresh:** \~20 min · **Chains:** 15 EVM chains
</Info>

<Card title="Get This Data" icon="database" href="https://dune.com/enterprise?dataset=lending">
  Access lending data via API, Datashare, or the Dune App.
</Card>

## Available Tables

<CardGroup>
  <Card title="lending.supply" icon="database" href="/data-catalog/curated/lending/supply">
    All supply-side transactions: deposits, withdrawals, and supply-side liquidations
  </Card>

  <Card title="lending.borrow" icon="database" href="/data-catalog/curated/lending/borrow">
    All borrow-side transactions: borrows, repayments, and borrow-side liquidations
  </Card>

  <Card title="lending.flashloans" icon="database" href="/data-catalog/curated/lending/flashloans">
    All flash loan transactions across lending protocols
  </Card>

  <Card title="lending.info" icon="database" href="/data-catalog/curated/lending/info">
    Static lookup of lending protocol metadata
  </Card>
</CardGroup>

## When to Use These Tables

* Track supply and borrow volumes across DeFi lending protocols
* Analyze liquidation events and at-risk positions
* Monitor flash loan activity and fees
* Compare lending protocol market share across chains
* Build lending analytics dashboards for protocol teams or investors

## Coverage

**Chains (15):** Arbitrum, Avalanche C-Chain, Base, BNB Chain, Celo, Ethereum, Fantom, Gnosis, Linea, Optimism, Polygon, Scroll, Sonic, zkSync, Unichain

**Protocols:** Aggregated from all integrated lending protocols including Aave, Compound, and others. Use `SELECT DISTINCT project FROM lending.supply` for the current list.

## Query Performance

**Partition keys:**

* `lending.supply`: `blockchain`, `project`, `block_month`
* `lending.borrow`: `blockchain`, `project`, `block_month`
* `lending.flashloans`: `blockchain`, `project`

Always include `blockchain` and `block_month` (or a `block_time` range) in your WHERE clause.

```sql theme={null}
-- ✅ Good: filters on partition keys
SELECT * FROM lending.supply
WHERE blockchain = 'ethereum'
  AND block_month >= DATE '2025-01-01'
  AND project = 'aave'

-- ❌ Slow: no partition filters
SELECT * FROM lending.supply
WHERE symbol = 'USDC'
```

## Methodology

Lending tables are maintained by Dune ([source code](https://github.com/duneanalytics/spellbook)). They aggregate data from protocol-specific base models (`lending_base_supply`, `lending_base_borrow`, `lending_base_flashloans`), which decode on-chain events from each protocol's smart contracts. Token amounts are decimal-adjusted and joined with Dune's price feeds (`prices.minute`, `prices.hour`, `prices.day`) for USD values.

## Example Queries

**Daily supply volume by protocol on Ethereum:**

```sql theme={null}
SELECT
  date_trunc('day', block_time) AS day,
  project,
  SUM(amount_usd) AS supply_volume_usd
FROM lending.supply
WHERE blockchain = 'ethereum'
  AND block_month >= DATE '2025-01-01'
  AND transaction_type = 'deposit'
GROUP BY 1, 2
ORDER BY 1 DESC, 3 DESC
```

**Top borrowers by total USD borrowed (last 30 days):**

```sql theme={null}
SELECT
  borrower,
  SUM(amount_usd) AS total_borrowed_usd,
  COUNT(*) AS num_borrows
FROM lending.borrow
WHERE blockchain = 'ethereum'
  AND block_time >= NOW() - INTERVAL '30' DAY
  AND transaction_type = 'borrow'
GROUP BY 1
ORDER BY 2 DESC
LIMIT 20
```

**Flash loan volume by chain:**

```sql theme={null}
SELECT
  blockchain,
  project,
  SUM(amount_usd) AS flashloan_volume_usd,
  COUNT(*) AS num_flashloans
FROM lending.flashloans
WHERE block_time >= NOW() - INTERVAL '7' DAY
GROUP BY 1, 2
ORDER BY 3 DESC
```

## Related Tables

* `dex.flashloans` — Flash loans from DEX protocols (Balancer, Uniswap, dYdX) as opposed to lending-native flash loans
* `prices.day` / `prices.hour` / `prices.minute` — Token price feeds
* `tokens.erc20` — Token metadata (symbols, decimals)

<CardGroup>
  <Card title="Enterprise Data Solutions" icon="building" href="https://dune.com/enterprise">
    Need custom lending datasets or dedicated support? Talk to our enterprise team.
  </Card>

  <Card title="Build Custom Models" icon="code" href="/api-reference/connectors/overview">
    Build private lending analytics pipelines with the dbt Connector.
  </Card>
</CardGroup>


# lending.supply
Source: https://docs.dune.com/data-catalog/curated/lending/supply

DeFi lending supply events — deposits and withdrawals across Aave, Compound, and other lending protocols.

The `lending.supply` table contains all supply-side transactions across DeFi lending protocols — deposits, withdrawals, and supply-side liquidations — across 15+ EVM chains.

## Table Schema

| Column                     | Type        | Description                                       |
| -------------------------- | ----------- | ------------------------------------------------- |
| `blockchain`               | `VARCHAR`   | Blockchain name                                   |
| `project`                  | `VARCHAR`   | Lending protocol name                             |
| `version`                  | `VARCHAR`   | Protocol contract version                         |
| `transaction_type`         | `VARCHAR`   | Transaction type (deposit, withdraw, liquidation) |
| `symbol`                   | `VARCHAR`   | Token symbol                                      |
| `token_address`            | `VARBINARY` | Token contract address                            |
| `depositor`                | `VARBINARY` | Depositor wallet address                          |
| `on_behalf_of`             | `VARBINARY` | Wallet address the tx was executed on behalf of   |
| `withdrawn_to`             | `VARBINARY` | Withdrawal recipient address                      |
| `liquidator`               | `VARBINARY` | Liquidator wallet address                         |
| `amount`                   | `DOUBLE`    | Token amount in display units                     |
| `amount_raw`               | `UINT256`   | Raw token amount                                  |
| `amount_usd`               | `DOUBLE`    | Token amount in USD                               |
| `block_month`              | `TIMESTAMP` | Block month (partition key)                       |
| `block_time`               | `TIMESTAMP` | Block timestamp in UTC                            |
| `block_number`             | `BIGINT`    | Block number                                      |
| `project_contract_address` | `VARBINARY` | Protocol contract address                         |
| `tx_hash`                  | `VARBINARY` | Transaction hash                                  |
| `evt_index`                | `INTEGER`   | Event index                                       |

## Table sample

<TableSample />

## Query performance

Partition keys: `blockchain`, `project`, `block_month`. Always include `blockchain` and a time filter.

```sql theme={null}
-- ✅ Good: filters on partition keys
SELECT * FROM lending.supply
WHERE blockchain = 'ethereum'
  AND block_month >= DATE '2025-01-01'
```


# NFT Metadata
Source: https://docs.dune.com/data-catalog/curated/nft-trades/evm/nft-metadata

Metadata for NFTs across EVM networks.

The `tokens.nft` table contains metadata for NFTs across all EVM-compatible networks indexed on Dune. This dataset provides essential information about NFTs, including:

* The blockchain on which the NFT exists
* The contract address of the NFT
* The name of the NFT collection
* The symbol of the NFT collection
* The standard used by the NFT (e.g., ERC721, ERC1155)

### Utility

The NFT metadata table offers valuable information for NFT analysis and integration, allowing you to:

* Identify NFT collections across different blockchains
* Retrieve essential NFT information for calculations and display
* Cross-reference NFT data with other tables like `tokens.nft_transfers`

## Table Schema

| Column             | Type        | Description                            |
| ------------------ | ----------- | -------------------------------------- |
| `blockchain`       | `VARCHAR`   | Blockchain on which the NFT exists     |
| `contract_address` | `VARBINARY` | Contract address of the NFT collection |
| `name`             | `VARCHAR`   | Name of the NFT collection             |
| `symbol`           | `VARCHAR`   | Symbol of the NFT collection           |
| `standard`         | `VARCHAR`   | Token standard (ERC721, ERC1155)       |

<TableSample />

### Network Coverage

NFT metadata is available for all EVM-compatible networks indexed by Dune.

## Sample Queries

**Query NFT collections on a specific blockchain**

This query returns NFT collections on the Ethereum blockchain:

```sql theme={null}
SELECT
    contract_address,
    name,
    symbol,
    standard
FROM tokens.nft
WHERE blockchain = 'ethereum'
LIMIT 100
```

**Find NFTs with a specific standard across blockchains**

This query finds all NFTs using the ERC721 standard across different blockchains:

```sql theme={null}
SELECT
    blockchain,
    contract_address,
    name,
    symbol
FROM tokens.nft
WHERE standard = 'erc721'
```

**List NFT collections with a specific keyword in their name**

This query lists NFT collections that have "Punk" in their name:

```sql theme={null}
SELECT
    blockchain,
    contract_address,
    name,
    symbol,
    standard
FROM tokens.nft
WHERE name LIKE '%Punk%'
ORDER BY blockchain, name
LIMIT 50
```


# nft.mints
Source: https://docs.dune.com/data-catalog/curated/nft-trades/evm/nft-mints

Dataset capturing NFT minting events across multiple blockchains, providing crucial insights into NFT creation and project launches.

## Table Description

The `nft.mints` table captures Non-Fungible Token (NFT) minting events across various blockchain networks. It provides insights into project launches, artist activity, and the growth of NFT collections.

<Warning>
  This table is not well maintained and misses coverage on chains and projects.
</Warning>

## Usage

The nft.mints table is a valuable tool for examining the NFT creation process. It offers detailed information about each NFT minting event, including data points such as the minting timestamp, the address of the minter, the contract address, and specifics about the minted NFT. This table enables analysts to explore trends in NFT creation, track the launch of new collections, and analyze patterns in minting behavior across different projects and blockchain networks.

## Coverage

<div>
  <DuneEmbed />
</div>

## Table Schema

| Column                     | Type        | Description                            |
| -------------------------- | ----------- | -------------------------------------- |
| `blockchain`               | `VARCHAR`   | Blockchain on which the mint occurred  |
| `project`                  | `VARCHAR`   | NFT marketplace/project name           |
| `version`                  | `VARCHAR`   | Contract version                       |
| `block_date`               | `DATE`      | UTC event block date                   |
| `block_month`              | `DATE`      | UTC event block month (partition key)  |
| `block_time`               | `TIMESTAMP` | UTC event block time                   |
| `token_id`                 | `UINT256`   | NFT token ID                           |
| `collection`               | `VARCHAR`   | NFT collection name                    |
| `amount_usd`               | `DOUBLE`    | USD value at time of mint              |
| `token_standard`           | `VARCHAR`   | Token standard (ERC721, ERC1155)       |
| `trade_type`               | `VARCHAR`   | Single or multiple NFTs minted         |
| `number_of_items`          | `UINT256`   | Number of items minted                 |
| `trade_category`           | `VARCHAR`   | Mint category (direct, auction, etc.)  |
| `evt_type`                 | `VARCHAR`   | Event type (Mint)                      |
| `seller`                   | `VARBINARY` | Seller/creator address                 |
| `buyer`                    | `VARBINARY` | Minter/buyer address                   |
| `amount_original`          | `DOUBLE`    | Amount in original currency            |
| `amount_raw`               | `UINT256`   | Raw amount before decimal adjustment   |
| `currency_symbol`          | `VARCHAR`   | Symbol of currency used for payment    |
| `currency_contract`        | `VARBINARY` | Contract address of payment token      |
| `nft_contract_address`     | `VARBINARY` | NFT contract address                   |
| `project_contract_address` | `VARBINARY` | Marketplace contract address           |
| `aggregator_name`          | `VARCHAR`   | Aggregator name if applicable          |
| `aggregator_address`       | `VARBINARY` | Aggregator contract address            |
| `tx_hash`                  | `VARBINARY` | Transaction hash                       |
| `block_number`             | `BIGINT`    | Block number                           |
| `tx_from`                  | `VARBINARY` | Address that initiated the transaction |
| `tx_to`                    | `VARBINARY` | Address that received the transaction  |
| `evt_index`                | `INTEGER`   | Event index                            |

## Table Sample

<TableSample />


# nft.trades
Source: https://docs.dune.com/data-catalog/curated/nft-trades/evm/nft-trades

NFT trade execution data across EVM chains — captures sales, bids, and listings across major marketplaces with pricing, buyer/seller details, and collection metadata

## Table Description

The nft.trades table on Dune is central to capturing and analyzing Non-Fungible Token (NFT) transactions across various marketplaces. It is a pivotal resource for dissecting the intricacies of NFT trade execution, market behavior, and collector activity within the NFT space.

## Usage

The nft.trades table serves as an essential tool for delving into the NFT market's complexities. It offers a detailed snapshot of each NFT transaction, encompassing data points such as sale price, transaction timestamp, buyer and seller addresses, and the specific NFT assets involved. This table allows analysts to explore trends in NFT valuation, trading volumes, and marketplace dynamics, providing insights into the evolving landscape of digital collectibles and art.

## Coverage

The `nft.trades` table is maintained by Dune and covers the following marketplaces and versions:

<div>
  <DuneEmbed />
</div>

## Table Schema

| Column                        | Type        | Description                                         |
| ----------------------------- | ----------- | --------------------------------------------------- |
| `blockchain`                  | `VARCHAR`   | Blockchain on which the trade occurred              |
| `project`                     | `VARCHAR`   | NFT marketplace name                                |
| `version`                     | `VARCHAR`   | Marketplace contract version                        |
| `block_date`                  | `DATE`      | UTC event block date                                |
| `block_month`                 | `DATE`      | UTC event block month (partition key)               |
| `block_time`                  | `TIMESTAMP` | UTC event block time                                |
| `token_id`                    | `DOUBLE`    | NFT token ID                                        |
| `collection`                  | `VARCHAR`   | NFT collection name                                 |
| `amount_usd`                  | `DOUBLE`    | USD value of the trade at time of execution         |
| `token_standard`              | `VARCHAR`   | Token standard (ERC721, ERC1155)                    |
| `trade_type`                  | `VARCHAR`   | Single or multiple NFTs traded                      |
| `number_of_items`             | `UINT256`   | Number of items traded                              |
| `trade_category`              | `VARCHAR`   | How the NFT was traded (direct buy, auction, etc.)  |
| `evt_type`                    | `VARCHAR`   | Event type (Trade, Mint, Burn)                      |
| `seller`                      | `VARBINARY` | Seller wallet address                               |
| `buyer`                       | `VARBINARY` | Buyer wallet address                                |
| `amount_original`             | `DOUBLE`    | Traded amount in original currency                  |
| `amount_raw`                  | `UINT256`   | Traded amount before decimals correction            |
| `currency_symbol`             | `VARCHAR`   | Symbol of currency used for payment                 |
| `currency_contract`           | `VARBINARY` | Contract address of payment token                   |
| `nft_contract_address`        | `VARBINARY` | NFT contract address                                |
| `project_contract_address`    | `VARBINARY` | Marketplace contract address                        |
| `aggregator_name`             | `VARCHAR`   | Aggregator name if trade went through an aggregator |
| `aggregator_address`          | `VARBINARY` | Aggregator contract address                         |
| `tx_hash`                     | `VARBINARY` | Transaction hash                                    |
| `block_number`                | `BIGINT`    | Block number                                        |
| `tx_from`                     | `VARBINARY` | Address that initiated the transaction              |
| `tx_to`                       | `VARBINARY` | Address that received the transaction               |
| `platform_fee_amount_raw`     | `UINT256`   | Raw platform fee amount                             |
| `platform_fee_amount`         | `DOUBLE`    | Platform fee in original currency                   |
| `platform_fee_amount_usd`     | `DOUBLE`    | Platform fee in USD                                 |
| `platform_fee_percentage`     | `DOUBLE`    | Platform fee as percentage of trade amount          |
| `royalty_fee_receive_address` | `VARBINARY` | Address receiving royalty fees                      |
| `royalty_fee_currency_symbol` | `VARCHAR`   | Symbol of the royalty fee currency                  |
| `royalty_fee_amount_raw`      | `UINT256`   | Raw royalty fee amount                              |
| `royalty_fee_amount`          | `DOUBLE`    | Royalty fee in original currency                    |
| `royalty_fee_amount_usd`      | `DOUBLE`    | Royalty fee in USD                                  |
| `royalty_fee_percentage`      | `DOUBLE`    | Royalty fee as percentage of trade amount           |
| `unique_trade_id`             | `VARCHAR`   | Unique trade identifier                             |

## Table Sample

<TableSample />


# NFT Transfers
Source: https://docs.dune.com/data-catalog/curated/nft-trades/evm/nft-transfers

NFT transfer events across EVM networks.

The `nft.transfers` table contains NFT transfer events across ERC721 and ERC1155 tokens for all EVM-compatible networks indexed on Dune. This dataset encompasses:

* Transfer events for ERC721 tokens
* Transfer events for ERC1155 tokens

<Info>
  This table covers all standard ERC-721 and ERC-1155 transfer events. Some NFTs may have non-standard transfer mechanisms and might not be included.
  You can check the logic for the transfers table [here](https://github.com/duneanalytics/spellbook/tree/main/dbt_subprojects/hourly_spellbook/models/_sector/nft/transfers). The level of detail of the transfers table will vary by chain.
</Info>

### Utility

The NFT transfers table provides a comprehensive view of NFT movement across networks, enabling you to:

* Track NFT flows between addresses
* Analyze NFT transaction volumes and patterns
* Identify significant NFT movements
* Monitor NFT marketplace and protocol activity

## Table Schema

| Column               | Type        | Description                               |
| -------------------- | ----------- | ----------------------------------------- |
| `blockchain`         | `VARCHAR`   | Blockchain on which the transfer occurred |
| `block_time`         | `TIMESTAMP` | UTC event block time                      |
| `block_month`        | `DATE`      | UTC event block month (partition key)     |
| `block_date`         | `DATE`      | UTC event block date                      |
| `block_number`       | `BIGINT`    | Block number                              |
| `token_standard`     | `VARCHAR`   | Token standard (ERC721, ERC1155)          |
| `transfer_type`      | `VARCHAR`   | Single or batch transfer                  |
| `evt_index`          | `INTEGER`   | Event index within the transaction        |
| `contract_address`   | `VARBINARY` | NFT contract address                      |
| `token_id`           | `UINT256`   | ID of the transferred token               |
| `amount`             | `UINT256`   | Number of tokens transferred              |
| `from`               | `VARBINARY` | Sender address                            |
| `to`                 | `VARBINARY` | Recipient address                         |
| `executed_by`        | `VARBINARY` | Address that executed the transaction     |
| `tx_hash`            | `VARBINARY` | Transaction hash                          |
| `unique_transfer_id` | `VARCHAR`   | Unique transfer identifier                |

<TableSample />

### Network Coverage

NFT transfer data is available for the following EVM-compatible networks:

<div>
  <DuneEmbed />
</div>

## Sample Queries

**Query recent NFT transfers for a specific address**

This query returns the most recent NFT transfers (both incoming and outgoing) for a specified address:

```sql theme={null}
SELECT
    block_time,
    token_standard,
    CASE 
        WHEN "from" = {{address}} THEN 'Outgoing'
        WHEN "to" = {{address}} THEN 'Incoming'
    END AS direction,
    contract_address,
    token_id,
    amount
FROM nft.transfers
WHERE ("from" = {{address}} OR "to" = {{address}})
    AND block_time > now() - interval '30' day
ORDER BY block_time DESC
LIMIT 100
```

**Calculate daily transfer volume for a specific NFT contract**

This query calculates the daily transfer volume for a specific NFT contract:

```sql theme={null}
SELECT
    block_date,
    COUNT(*) AS num_transfers,
    SUM(amount) AS total_amount
FROM nft.transfers
WHERE contract_address = {{contract_address}}
    AND block_time > now() - interval '30' day
    AND blockchain = 'ethereum'
GROUP BY 1
ORDER BY 1 DESC
```

**Identify most active NFT contracts in the last 24 hours**

This query finds the most active NFT contracts by transfer count in the last 24 hours:

```sql theme={null}
SELECT
    blockchain,
    contract_address,
    token_standard,
    COUNT(*) AS transfer_count
FROM nft.transfers
WHERE block_time > now() - interval '1' day
GROUP BY 1, 2, 3
ORDER BY transfer_count DESC
LIMIT 50
```


# nft.wash_trades
Source: https://docs.dune.com/data-catalog/curated/nft-trades/evm/nft-wash-trades

Dataset for identifying and analyzing potential wash trading activities in NFT transactions across various marketplaces and blockchains

## Table Description

The nft.wash\_trades table on Dune is crucial for identifying and analyzing potential wash trading activities in Non-Fungible Token (NFT) transactions across various marketplaces. It provides insights into the authenticity of NFT trades and helps in understanding market manipulation within the NFT space.

## Usage

The nft.wash\_trades table serves as an essential tool for analyzing the integrity of NFT market activities. It offers a detailed view of each NFT transaction, including data points such as blockchain, project, buyer and seller addresses, and various filters to detect potential wash trades. This table allows analysts to identify suspicious trading patterns, assess the prevalence of wash trading in different NFT projects, and gain insights into the overall health and authenticity of the NFT market.

## Coverage

The `nft.wash_trades` table is maintained by Dune and covers various blockchains and NFT projects, identifying potential wash trading activities using pattern-based detection.

<div>
  <DuneEmbed />
</div>

## Mechanism

The nft.wash\_trades table employs a multi-faceted approach to identify potential wash trades:

1. Basic Trade Information: Each entry includes details such as blockchain, project, NFT contract address, token ID, buyer, seller, and transaction specifics.

2. Funding Source Analysis: The table tracks the first funding sources for both buyers and sellers (buyer\_first\_funded\_by, seller\_first\_funded\_by) to identify potential connections between trading parties.

3. Wash Trade Filters: Several filters are applied to flag suspicious activities:
   * filter\_1\_same\_buyer\_seller: Identifies trades where the buyer and seller are the same.
   * filter\_2\_back\_and\_forth\_trade: Detects repetitive trading between the same parties.
   * filter\_3\_bought\_or\_sold\_3x: Flags NFTs that have been traded frequently in a short period.
   * filter\_4\_first\_funded\_by\_same\_wallet: Identifies trades where both parties were initially funded by the same wallet.
   * filter\_5\_flashloan: Detects trades potentially facilitated by flash loans.

4. Wash Trade Classification: The is\_wash\_trade column provides a final verdict on whether a trade is considered a wash trade based on the applied filters.

This mechanism allows for a comprehensive analysis of NFT trades, helping to distinguish genuine market activity from potential manipulation.

## Table Schema

| Column                                 | Type        | Description                                                        |
| -------------------------------------- | ----------- | ------------------------------------------------------------------ |
| `blockchain`                           | `VARCHAR`   | Blockchain on which the trade occurred                             |
| `project`                              | `VARCHAR`   | NFT marketplace name                                               |
| `version`                              | `VARCHAR`   | Contract version                                                   |
| `nft_contract_address`                 | `VARBINARY` | NFT contract address                                               |
| `token_id`                             | `DOUBLE`    | NFT token ID                                                       |
| `token_standard`                       | `VARCHAR`   | Token standard (ERC721, ERC1155)                                   |
| `trade_category`                       | `VARCHAR`   | How the NFT was traded                                             |
| `buyer`                                | `VARBINARY` | Buyer wallet address                                               |
| `seller`                               | `VARBINARY` | Seller wallet address                                              |
| `project_contract_address`             | `VARBINARY` | Marketplace contract address                                       |
| `aggregator_name`                      | `VARCHAR`   | Aggregator name if applicable                                      |
| `aggregator_address`                   | `VARBINARY` | Aggregator contract address                                        |
| `tx_from`                              | `VARBINARY` | Address that initiated the transaction                             |
| `tx_to`                                | `VARBINARY` | Address that received the transaction                              |
| `block_time`                           | `TIMESTAMP` | UTC event block time                                               |
| `block_date`                           | `DATE`      | UTC event block date                                               |
| `block_number`                         | `BIGINT`    | Block number                                                       |
| `tx_hash`                              | `VARBINARY` | Transaction hash                                                   |
| `unique_trade_id`                      | `VARCHAR`   | Unique trade identifier                                            |
| `buyer_first_funded_by`                | `VARBINARY` | Wallet that first funded the buyer in ETH                          |
| `seller_first_funded_by`               | `VARBINARY` | Wallet that first funded the seller in ETH                         |
| `filter_1_same_buyer_seller`           | `BOOLEAN`   | Whether buyer and seller are the same address                      |
| `filter_2_back_and_forth_trade`        | `BOOLEAN`   | Whether the NFT was traded back and forth between buyer and seller |
| `filter_3_bought_or_sold_3x`           | `BOOLEAN`   | Whether the same NFT was bought 3+ times (excluding ERC1155)       |
| `filter_4_first_funded_by_same_wallet` | `BOOLEAN`   | Whether the same wallet first funded both buyer and seller         |
| `filter_5_flashloan`                   | `BOOLEAN`   | Whether the transaction included a flashloan                       |
| `is_wash_trade`                        | `BOOLEAN`   | Final verdict: true if any filter was triggered                    |

## Table Sample

<TableSample />


# NFT Data
Source: https://docs.dune.com/data-catalog/curated/nft-trades/overview

Curated NFT market data across multiple blockchain networks

Non-fungible tokens (NFTs) have emerged as a major force in the crypto ecosystem, enabling unique digital assets and collectibles. Dune provides comprehensive coverage of NFT market activity through curated tables that capture trades, mints, transfers, and metadata across both EVM and Solana networks. These datasets enable analysis of sales volumes, collection trends, minting patterns, and market dynamics across major NFT marketplaces and networks.

<Info>
  **Maintained by:** Dune · **Refresh:** \~1 hour · **Chains:** 12 chains (EVM + Solana)
</Info>

<Card title="Get This Data" icon="database" href="https://dune.com/enterprise?dataset=nft.trades">
  Access NFT trading data via API, Datashare, or the Dune App.
</Card>

## Cross-Chain NFT Coverage

Our NFT data covers multiple blockchain ecosystems:

* **EVM Networks**: Ethereum, BNB, Polygon, Arbitrum, Optimism, zkSync, Blast, Ronin, Nova, Abstract, Apechain
* **Solana**: Comprehensive coverage of Solana NFT ecosystem and metadata

## Available Datasets

### EVM NFT Data

<CardGroup>
  <Card title="NFT Trades" icon="shop" href="/data-catalog/curated/nft-trades/evm/nft-trades">
    NFT sales across marketplaces like OpenSea, LooksRare, and more
  </Card>

  <Card title="NFT Mints" icon="plus" href="/data-catalog/curated/nft-trades/evm/nft-mints">
    Initial NFT creation and minting events
  </Card>

  <Card title="Wash Trades" icon="broom" href="/data-catalog/curated/nft-trades/evm/nft-wash-trades">
    Detected wash trading activity and suspicious patterns
  </Card>
</CardGroup>

### Solana NFT Data

<CardGroup>
  <Card title="NFT Transfers" icon="arrow-right-arrow-left" href="/data-catalog/curated/nft-trades/solana/solana-nft-transfers">
    Transfer events for Solana NFTs across the network
  </Card>

  <Card title="NFT Metadata" icon="hexagon-vertical-nft" href="/data-catalog/curated/nft-trades/solana/solana-nft-metadata">
    Comprehensive metadata for Solana NFTs including attributes and collections
  </Card>
</CardGroup>

## Key Features

* **Multi-Chain Coverage**: Analyze NFT activity across EVM and Solana ecosystems
* **Marketplace Integration**: Data from major NFT marketplaces and platforms
* **Wash Trade Detection**: Identify suspicious trading patterns (EVM)
* **Metadata Tracking**: Comprehensive NFT metadata and attributes
* **Collection Analytics**: Track performance at the collection level
* **Real-time Updates**: Data is updated continuously as new blocks are processed

## Sample Cross-Chain Analysis

Compare NFT trading activity across different blockchain networks:

```sql theme={null}
-- EVM NFT trades
SELECT 
    'EVM' as ecosystem,
    blockchain,
    DATE_TRUNC('day', block_time) as date,
    COUNT(*) as num_trades,
    SUM(amount_usd) as volume_usd
FROM nft.trades
WHERE block_time >= NOW() - INTERVAL '30' day
GROUP BY 1, 2, 3

UNION ALL

-- Solana NFT transfers (as proxy for activity)
SELECT 
    'Solana' as ecosystem,
    'solana' as blockchain,
    DATE_TRUNC('day', block_time) as date,
    COUNT(*) as num_transfers,
    NULL as volume_usd
FROM solana.nft_transfers
WHERE block_time >= NOW() - INTERVAL '30' day
GROUP BY 1, 2, 3

ORDER BY date DESC, volume_usd DESC NULLS LAST
```

## When to Use These Tables

* Analyze NFT sales volumes and trends across marketplaces
* Track collection floor prices, minting activity, and holder distribution
* Monitor wash trading and market manipulation patterns
* Build marketplace performance benchmarks (OpenSea vs Blur vs others)
* Research creator royalty flows and marketplace fee structures

## Query Performance

**Partition keys for `nft.trades`:** `blockchain`, `project`, `block_month`

Always include `blockchain` and a time filter for best performance.

```sql theme={null}
-- ✅ Good: partition key filters
SELECT * FROM nft.trades
WHERE blockchain = 'ethereum'
  AND block_month >= DATE '2025-01-01'

-- ❌ Slow: no partition filters
SELECT * FROM nft.trades
WHERE nft_contract_address = 0x...
```

## Methodology

NFT tables are maintained by Dune ([source code](https://github.com/duneanalytics/spellbook)). They aggregate data from marketplace-specific base models that decode trade events from each marketplace's smart contracts (OpenSea Seaport, Blur, LooksRare, etc.). Each trade is enriched with collection metadata, token pricing for payment tokens, and standardized trade type classification (buy, sell, offer accepted).

## Example Queries

**Daily NFT volume by marketplace on Ethereum:**

```sql theme={null}
SELECT
  date_trunc('day', block_time) AS day,
  project AS marketplace,
  SUM(amount_usd) AS volume_usd,
  COUNT(*) AS num_trades
FROM nft.trades
WHERE blockchain = 'ethereum'
  AND block_month >= DATE '2025-01-01'
  AND block_time >= NOW() - INTERVAL '30' DAY
GROUP BY 1, 2
ORDER BY 1 DESC, 3 DESC
```

**Top NFT collections by volume (last 7 days):**

```sql theme={null}
SELECT
  nft_contract_address,
  collection,
  SUM(amount_usd) AS volume_usd,
  COUNT(*) AS num_sales
FROM nft.trades
WHERE blockchain = 'ethereum'
  AND block_time >= NOW() - INTERVAL '7' DAY
GROUP BY 1, 2
ORDER BY 3 DESC
LIMIT 20
```

## Related Tables

* `prices.day` / `prices.hour` — Token pricing for payment token USD values
* `tokens.nft` — NFT collection metadata
* `nft.mints` — NFT minting events (separate from secondary market trades)

<CardGroup>
  <Card title="Enterprise Data Solutions" icon="building" href="https://dune.com/enterprise">
    Need custom NFT datasets or dedicated support? Talk to our enterprise team.
  </Card>

  <Card title="Build Custom Models" icon="code" href="/api-reference/connectors/overview">
    Build private NFT analytics pipelines with the dbt Connector.
  </Card>
</CardGroup>


# Solana NFT Metadata
Source: https://docs.dune.com/data-catalog/curated/nft-trades/solana/solana-nft-metadata

Metadata for non-fungible tokens (NFTs) on the Solana blockchain.

The `tokens_solana.nft` table contains metadata for non-fungible tokens (NFTs) on the Solana blockchain indexed on Dune. This dataset provides essential information about Solana NFTs, including:

* The NFT mint address and associated accounts
* Token details such as name, symbol, and URI
* Creator and collection information
* Transaction details of the NFT creation

### Utility

The Solana NFT metadata table offers valuable information for NFT analysis and integration, allowing you to:

* Identify and track NFTs on the Solana blockchain
* Retrieve essential NFT information for display and analysis
* Access creator and collection data for comprehensive NFT insights

## Table Schema

| Column             | Type        | Description                        |
| ------------------ | ----------- | ---------------------------------- |
| `account_mint`     | `VARCHAR`   | NFT mint address                   |
| `token_name`       | `VARCHAR`   | NFT name                           |
| `token_symbol`     | `VARCHAR`   | NFT symbol                         |
| `token_uri`        | `VARCHAR`   | NFT metadata URI                   |
| `token_standard`   | `VARCHAR`   | Token standard (e.g., NonFungible) |
| `collection_mint`  | `VARCHAR`   | Collection mint address            |
| `verified_creator` | `VARCHAR`   | Verified creator address           |
| `metadata_program` | `VARCHAR`   | Program used for metadata          |
| `call_block_time`  | `TIMESTAMP` | Block time of NFT creation         |
| `call_tx_signer`   | `VARCHAR`   | Transaction signer                 |
| `call_tx_id`       | `VARCHAR`   | Transaction ID                     |

<TableSample />

### Network Coverage

This table covers NFT metadata for the Solana blockchain.

## Sample Queries

**Query Solana NFTs**

This query returns NFTs on the Solana blockchain:

```sql theme={null}
SELECT
    account_mint,
    token_name,
    token_symbol,
    token_uri
FROM tokens_solana.nft
LIMIT 100
```

**Find NFTs from a specific collection**

This query finds all NFTs from a specific collection on Solana:

```sql theme={null}
SELECT
    account_mint,
    token_name,
    token_symbol,
    token_uri
FROM tokens_solana.nft
WHERE collection_mint = 'your_collection_mint_address_here'
LIMIT 50
```

**List NFTs by a specific creator**

This query lists NFTs created by a specific verified creator on Solana:

```sql theme={null}
SELECT
    account_mint,
    token_name,
    token_symbol,
    token_uri,
    call_block_time
FROM tokens_solana.nft
WHERE verified_creator = 'your_creator_address_here'
ORDER BY call_block_time DESC
LIMIT 50
```


# Solana NFT Transfers
Source: https://docs.dune.com/data-catalog/curated/nft-trades/solana/solana-nft-transfers

NFT transfer events on the Solana blockchain.

The `tokens_solana.nft` table contains NFT transfer events for tokens on the Solana blockchain indexed on Dune. This dataset encompasses transfer events for various Solana NFT standards.

<Info>
  This table covers all standard Solana NFT transfer events. Some Solana NFTs may have non-standard transfer mechanisms and might not be included.
  You can check the logic for the transfers table [here](https://github.com/duneanalytics/spellbook/blob/main/dbt_subprojects/solana/models/tokens/solana/tokens_solana_nft.sql).
</Info>

### Utility

The Solana NFT transfers table provides a comprehensive view of NFT movement on the Solana network, enabling you to:

* Track NFT flows between accounts
* Analyze NFT transaction volumes and patterns
* Identify significant NFT movements
* Monitor NFT marketplace and protocol activity on Solana

## Table Schema

| Column             | Type        | Description                |
| ------------------ | ----------- | -------------------------- |
| `account_mint`     | `VARCHAR`   | NFT mint address           |
| `token_name`       | `VARCHAR`   | NFT name                   |
| `token_symbol`     | `VARCHAR`   | NFT symbol                 |
| `token_uri`        | `VARCHAR`   | NFT metadata URI           |
| `token_standard`   | `VARCHAR`   | Token standard             |
| `collection_mint`  | `VARCHAR`   | Collection mint address    |
| `verified_creator` | `VARCHAR`   | Verified creator address   |
| `metadata_program` | `VARCHAR`   | Program used for metadata  |
| `call_block_time`  | `TIMESTAMP` | Block time of the transfer |
| `call_tx_signer`   | `VARCHAR`   | Transaction signer         |
| `call_tx_id`       | `VARCHAR`   | Transaction ID             |

<TableSample />

## Sample Queries

**Query recent NFT transfers for a specific account**

This query returns the most recent NFT transfers for a specified account:

```sql theme={null}
SELECT
    call_block_time,
    token_standard,
    account_mint,
    token_name,
    token_symbol,
    call_tx_signer
FROM tokens_solana.nft
WHERE call_tx_signer = '7F9KJm6rcW2PAgUkRmqXhzMmUpxWcQcLFjarE4bwniqZ'
    AND call_block_time > now() - interval '30' day
ORDER BY call_block_time DESC
LIMIT 100
```


# Curated Data Overview
Source: https://docs.dune.com/data-catalog/curated/overview

Pre-built, cross-chain datasets maintained by Dune — the fastest path from raw blockchain data to production analytics.

Dune's curated data tables are pre-built, validated datasets that normalize data from hundreds of protocols across dozens of chains into consistent schemas. Built and maintained by Dune's data team, they are production-ready for analytics, applications, and data pipelines.

For example, the `dex.trades` table aggregates data from multiple sources to provide a comprehensive view of all trades on decentralized exchanges across EVM networks, while `dex_solana.trades` provides similar coverage for Solana DEXs.

## Getting Started

You can access curated data tables in several ways:

<CardGroup>
  <Card title="Data Hub" icon="database" href="https://dune.com">
    Browse curated tables in the Data Hub within the Dune App. Use the data explorer to search tables, preview schemas, and see sample data.
  </Card>

  <Card title="Data Hub" icon="chart-mixed" href="https://dune.com">
    Write SQL queries against any curated table directly in the Data Hub — no infrastructure needed.
  </Card>

  <Card title="Data API" icon="code" href="/api-reference/overview/introduction">
    Access query results programmatically via the Dune API for application integrations and data pipelines.
  </Card>

  <Card title="Datashare" icon="warehouse" href="/datashare/datashare">
    Access curated tables directly in your own Snowflake, BigQuery, or Databricks environment via Datashare.
  </Card>
</CardGroup>

## Benefits of Curated Data Tables

* **Simplified Queries**: High-level views that abstract away raw data complexity.
* **Cross-Chain Analysis**: Consistent data models enable easy comparison between different blockchain networks.
* **Validated and Tested**: Automated quality checks at every pipeline stage.
* **Transparent Methodology**: Every dataset documents how it's built, design decisions, and limitations.

## Cross-Chain Coverage

Our curated data covers multiple blockchain ecosystems:

* **EVM Networks**: Ethereum, Arbitrum, Polygon, Base, Optimism, and 55+ other EVM chains
* **Solana**: Comprehensive coverage of Solana DeFi and NFT ecosystems
* **Non-EVM**: Bitcoin, Aptos, Sui, TON, Tron, and others for pricing and select datasets

Here is a non-exhaustive list of some of the curated data tables available:

<div>
  <DuneEmbed />
</div>

## Available Categories

<CardGroup>
  <Card title="DEX Trades" icon="shuffle" href="/data-catalog/curated/dex-trades/overview">
    Comprehensive DEX trading data across EVM and Solana networks
  </Card>

  <Card title="Prediction Markets" icon="chart-line" href="/data-catalog/curated/prediction-markets/overview">
    Polymarket and Kalshi market activity, positions, and pricing
  </Card>

  <Card title="NFT Trades" icon="image" href="/data-catalog/curated/nft-trades/overview">
    NFT trading, minting, and metadata across multiple blockchains
  </Card>

  <Card title="Token Transfers" icon="coins" href="/data-catalog/curated/token-transfers/overview">
    Token transfers and balances across EVM and Solana
  </Card>

  <Card title="Address Labels" icon="tag" href="/data-catalog/curated/labels/overview">
    Identify and categorize blockchain addresses
  </Card>

  <Card title="Token Prices" icon="dollar-sign" href="/data-catalog/curated/prices/overview">
    Historical and real-time token pricing data
  </Card>

  <Card title="Balances" icon="scale-balanced" href="/data-catalog/curated/balances/overview">
    Current and historical token balances by address
  </Card>

  <Card title="Token Metadata" icon="info" href="/data-catalog/curated/token-metadata/overview">
    Token names, symbols, decimals, and contract addresses
  </Card>

  <Card title="Stablecoins" icon="coins" href="/data-catalog/curated/stablecoins/overview">
    Stablecoin transfers, balances, and activity classification across EVM, Solana, and Tron
  </Card>

  <Card title="Lending" icon="hand-holding-dollar" href="/data-catalog/curated/lending/overview">
    DeFi lending protocol data — supply, borrow, flash loans, and liquidations across 15+ chains
  </Card>

  <Card title="Bridges" icon="bridge" href="/data-catalog/curated/bridges/overview">
    Cross-chain bridge transfers — deposits, withdrawals, and matched flows across 41 EVM chains
  </Card>

  <Card title="Staking" icon="layer-group" href="/data-catalog/curated/staking/overview">
    Ethereum beacon chain staking — deposits, withdrawals, and entity identification
  </Card>

  <Card title="CEX Flows" icon="building-columns" href="/data-catalog/curated/cex-flows/overview">
    Centralized exchange inflows and outflows across 29 chains
  </Card>

  <Card title="Gas & Fees" icon="gas-pump" href="/data-catalog/curated/gas-fees/overview">
    Transaction-level fee data across 55+ EVM chains and Solana
  </Card>

  <Card title="Rollup Economics" icon="chart-line" href="/data-catalog/curated/rollup-economics/overview">
    L2 rollup profitability — revenue vs L1 posting costs
  </Card>

  <Card title="Utilities" icon="wrench" href="/data-catalog/curated/utilities/overview">
    Time-series scaffolding tables for building continuous analytics
  </Card>
</CardGroup>

## Resources

<CardGroup>
  <Card title="Open-Source Models" icon="github" href="https://github.com/duneanalytics/spellbook">
    All curated data models are open-source — inspect the logic, contribute improvements, or build on top.
  </Card>

  <Card title="Model Documentation" icon="table" href="https://github.com/duneanalytics/spellbook">
    Browse model definitions, dependencies, and documentation for every curated table.
  </Card>

  <Card title="Contributing Guide" icon="book" href="https://github.com/duneanalytics/spellbook/tree/main/docs">
    Learn how to contribute new models or improve existing ones.
  </Card>

  <Card title="Adding Protocol Coverage" icon="code-pull-request" href="https://github.com/duneanalytics/spellbook/blob/main/dbt_subprojects/dex/README.md">
    Add your protocol's data to curated tables like dex.trades and nft.trades.
  </Card>
</CardGroup>


# All Prediction Market Tables
Source: https://docs.dune.com/data-catalog/curated/prediction-markets/all-tables-overview

Complete inventory of all prediction market tables available on Dune

## All Prediction Market Tables

| Protocol   | Table                                     | Description                                     | Docs                                                                             |
| ---------- | ----------------------------------------- | ----------------------------------------------- | -------------------------------------------------------------------------------- |
| Polymarket | `polymarket_polygon.market_trades`        | Trade-level activity across all market outcomes | [Open](/data-catalog/curated/prediction-markets/polymarket/market_trades)        |
| Polymarket | `polymarket_polygon.market_details`       | Enriched market metadata and resolution fields  | [Open](/data-catalog/curated/prediction-markets/polymarket/market_details)       |
| Polymarket | `polymarket_polygon.positions`            | Daily user position balances by outcome token   | [Open](/data-catalog/curated/prediction-markets/polymarket/positions)            |
| Polymarket | `polymarket_polygon.market_prices_hourly` | Hourly outcome token prices                     | [Open](/data-catalog/curated/prediction-markets/polymarket/market_prices_hourly) |
| Polymarket | `polymarket_polygon.market_prices_daily`  | Daily outcome token prices                      | [Open](/data-catalog/curated/prediction-markets/polymarket/market_prices_daily)  |
| Polymarket | `polymarket_polygon.market_prices_latest` | Latest price per outcome token                  | [Open](/data-catalog/curated/prediction-markets/polymarket/market_prices_latest) |
| Kalshi     | `kalshi.market_report`                    | Market-level metadata and lifecycle             | [Open](/data-catalog/curated/prediction-markets/kalshi/market_report)            |
| Kalshi     | `kalshi.trade_report`                     | Daily aggregated trade data                     | [Open](/data-catalog/curated/prediction-markets/kalshi/trade_report)             |


# kalshi.market_report
Source: https://docs.dune.com/data-catalog/curated/prediction-markets/kalshi/market_report

Kalshi market metadata — event contract details, categories, settlement rules, and current status.

The `kalshi.market_report` table contains market-level metadata for Kalshi event contracts, including ticker, title, category, and lifecycle status.

## Table Schema

| Column          | Type        | Description                                                              |
| --------------- | ----------- | ------------------------------------------------------------------------ |
| `block_volume`  | `DOUBLE`    | Trading volume for the block period                                      |
| `category`      | `VARCHAR`   | Category of the event contract (e.g., Politics, Economics, Sports, etc.) |
| `daily_volume`  | `DOUBLE`    | Total trading volume for the day                                         |
| `date`          | `VARCHAR`   | Date of the market report                                                |
| `high`          | `DOUBLE`    | Highest price reached during the reporting period                        |
| `low`           | `DOUBLE`    | Lowest price reached during the reporting period                         |
| `open_interest` | `DOUBLE`    | Total number of outstanding contracts                                    |
| `payout_type`   | `VARCHAR`   | Type of payout for the event contract                                    |
| `report_ticker` | `VARCHAR`   | Unique ticker identifier for the market report                           |
| `status`        | `VARCHAR`   | Current status of the event contract market                              |
| `ticker_name`   | `VARCHAR`   | Name or description of the event contract ticker                         |
| `_updated_at`   | `TIMESTAMP` | Last update timestamp                                                    |
| `_ingested_at`  | `TIMESTAMP` | Ingestion timestamp                                                      |

## Table sample

<TableSample />


# Kalshi
Source: https://docs.dune.com/data-catalog/curated/prediction-markets/kalshi/overview

Curated Kalshi prediction market datasets on Dune

Kalshi is a regulated prediction market (CFTC-regulated exchange) offering event contracts on real-world outcomes. Dune provides Kalshi market metadata and aggregated trade reporting data.

<Info>
  **Maintained by:** Dune (partner data) · **Refresh:** \~48 hours · **Source:** Off-chain (Kalshi public reporting)
</Info>

## Available Tables

<CardGroup>
  <Card title="kalshi.market_report" icon="database" href="/data-catalog/curated/prediction-markets/kalshi/market_report">
    Market-level metadata and lifecycle information
  </Card>

  <Card title="kalshi.trade_report" icon="database" href="/data-catalog/curated/prediction-markets/kalshi/trade_report">
    Daily aggregated trade data by ticker and price
  </Card>
</CardGroup>

## Notes

* Kalshi data is sourced from Kalshi's public reporting, not from on-chain events.
* `trade_report` contains daily aggregated data, not individual fills. A single date and ticker can have multiple rows at different price points.


# kalshi.trade_report
Source: https://docs.dune.com/data-catalog/curated/prediction-markets/kalshi/trade_report

Kalshi trade data — individual trades on event contracts with price, size, and execution details.

The `kalshi.trade_report` table contains daily aggregated trade data for Kalshi event contracts. Note that a single date and ticker can have multiple rows at different price points — this is not individual fill data.

## Table Schema

| Column             | Type        | Description                                      |
| ------------------ | ----------- | ------------------------------------------------ |
| `contracts_traded` | `DOUBLE`    | Number of contracts traded in the transaction    |
| `date`             | `VARCHAR`   | Date of the trade report                         |
| `price`            | `DOUBLE`    | Price at which the contracts were traded         |
| `report_ticker`    | `VARCHAR`   | Unique ticker identifier for the trade report    |
| `ticker_name`      | `VARCHAR`   | Name or description of the event contract ticker |
| `_updated_at`      | `TIMESTAMP` | Last update timestamp                            |
| `_ingested_at`     | `TIMESTAMP` | Ingestion timestamp                              |

## Table sample

<TableSample />


# Prediction Markets
Source: https://docs.dune.com/data-catalog/curated/prediction-markets/overview

Curated prediction market datasets for Polymarket and Kalshi on Dune

Prediction markets turn event outcomes into tradable instruments. Dune provides curated prediction market data combining onchain activity from **Polymarket** (the largest onchain prediction market) with regulated event-contract reporting from **Kalshi**.

<Info>
  **Maintained by:** Dune (Polymarket = project spell, Kalshi = partner data) · **Refresh:** \~24 hours · **Chains:** Polygon (Polymarket), Off-chain (Kalshi)
</Info>

<Card title="Get This Data" icon="database" href="https://dune.com/enterprise?dataset=prediction-markets">
  Access prediction market data via API, Datashare, or the Dune App.
</Card>

## Available Protocols

<CardGroup>
  <Card title="Polymarket (Polygon)" icon="database" href="/data-catalog/curated/prediction-markets/polymarket/overview">
    Onchain markets, trades, positions, and pricing across multiple granularities
  </Card>

  <Card title="Kalshi" icon="database" href="/data-catalog/curated/prediction-markets/kalshi/overview">
    Regulated event contract market and trade reports
  </Card>

  <Card title="All Tables" icon="table" href="/data-catalog/curated/prediction-markets/all-tables-overview">
    Complete inventory of all prediction market tables
  </Card>
</CardGroup>

## When to Use These Tables

Use prediction market tables when you need to:

* Track trading volumes, market activity, and implied probabilities on Polymarket
* Analyze event-contract pricing and settlement on Kalshi
* Monitor user positions and portfolio composition across prediction markets
* Research market resolution outcomes and pricing efficiency
* Compare prediction market activity across venues

## Query Performance

Polymarket tables are views. Always filter on `block_time` ranges for `market_trades`, and use `condition_id` or `question` for market-specific queries.

```sql theme={null}
-- ✅ Good: time-bounded with market filter
SELECT * FROM polymarket_polygon.market_trades
WHERE block_time >= NOW() - INTERVAL '7' DAY
  AND question LIKE '%election%'
```

## Methodology

**Polymarket** tables are maintained by Dune ([source code](https://github.com/duneanalytics/spellbook)). They combine decoded on-chain events from Polymarket's CTF Exchange and NegRisk contracts on Polygon with market metadata from the Polymarket API (stored in `dune.polymarket_markets`). Trading data includes three matching types: complementary (buyer matches seller), MINT (system mints new outcome tokens), and MERGE (system redeems YES+NO tokens for collateral).

**Kalshi** data is sourced from Kalshi's public reporting. `market_report` contains market-level metadata; `trade_report` contains daily aggregated trade data (not individual fills — a single date and ticker can have multiple rows at different price points).

## Example Queries

**Top Polymarket markets by volume (last 7 days):**

```sql theme={null}
SELECT
  event_market_name,
  question,
  SUM(amount) AS total_volume_usd,
  COUNT(*) AS num_trades
FROM polymarket_polygon.market_trades
WHERE block_time >= NOW() - INTERVAL '7' DAY
GROUP BY 1, 2
ORDER BY 3 DESC
LIMIT 20
```

**Price history for a specific Polymarket outcome:**

```sql theme={null}
SELECT
  d.day,
  d.token_outcome,
  d.price
FROM polymarket_polygon.market_prices_daily d
JOIN polymarket_polygon.market_details m
  ON d.condition_id = m.condition_id
  AND d.token_id = m.token_id
WHERE m.question = 'Will Trump win the 2024 US Presidential Election?'
ORDER BY d.day
```

## Related Tables

* `dex.trades` — DEX trading data (Polymarket uses Polygon DEX infrastructure)
* `prices.day` / `prices.hour` — Token pricing feeds

<CardGroup>
  <Card title="Enterprise Data Solutions" icon="building" href="https://dune.com/enterprise">
    Need custom prediction market datasets or dedicated support? Talk to our enterprise team.
  </Card>

  <Card title="Build Custom Models" icon="code" href="/api-reference/connectors/overview">
    Build private prediction market analytics pipelines with the dbt Connector.
  </Card>
</CardGroup>


# polymarket_polygon.market_details
Source: https://docs.dune.com/data-catalog/curated/prediction-markets/polymarket/market_details

Polymarket market metadata — questions, categories, resolution sources, and outcome token addresses.

The `polymarket_polygon.market_details` table contains enriched market metadata for Polymarket prediction markets, including lifecycle status, resolution fields, and human-readable market questions.

## Table Schema

| Column                     | Type        | Description                            |
| -------------------------- | ----------- | -------------------------------------- |
| `unique_key`               | `VARCHAR`   | Unique market identifier               |
| `condition_id`             | `VARCHAR`   | Market condition ID                    |
| `event_market_id`          | `VARCHAR`   | Event market ID                        |
| `event_market_name`        | `VARCHAR`   | Event market name                      |
| `event_market_description` | `VARCHAR`   | Event market description               |
| `question_id`              | `VARCHAR`   | Question ID                            |
| `question`                 | `VARCHAR`   | Market question text                   |
| `market_description`       | `VARCHAR`   | Market description                     |
| `token_id`                 | `UINT256`   | Token ID                               |
| `token_outcome`            | `VARCHAR`   | Token outcome (YES/NO)                 |
| `token_outcome_name`       | `VARCHAR`   | Token outcome display name             |
| `active`                   | `VARCHAR`   | Whether the market is active           |
| `archived`                 | `VARCHAR`   | Whether the market is archived         |
| `closed`                   | `VARCHAR`   | Whether the market is closed           |
| `accepting_orders`         | `VARCHAR`   | Whether the market is accepting orders |
| `enable_order_book`        | `VARCHAR`   | Whether the order book is enabled      |
| `neg_risk`                 | `VARCHAR`   | Whether it's a negative risk market    |
| `polymarket_link`          | `VARCHAR`   | Link to Polymarket event page          |
| `market_start_time`        | `VARCHAR`   | Market start time                      |
| `market_end_time`          | `VARCHAR`   | Market end time                        |
| `game_start_time`          | `VARCHAR`   | Game start time                        |
| `seconds_delay`            | `VARCHAR`   | Seconds delay                          |
| `fpmm`                     | `VARCHAR`   | Fixed Product Market Maker address     |
| `icon`                     | `VARCHAR`   | Market icon URL                        |
| `image`                    | `VARCHAR`   | Market image URL                       |
| `tags`                     | `VARCHAR`   | Market tags                            |
| `oracle`                   | `VARBINARY` | Oracle contract address                |
| `fee_bips`                 | `UINT256`   | Fee in basis points                    |
| `outcome`                  | `VARCHAR`   | Market outcome                         |
| `resolved_on_timestamp`    | `TIMESTAMP` | When the market was resolved           |
| `last_uploaded_at`         | `VARCHAR`   | Last data upload timestamp             |

## Table sample

<TableSample />


# polymarket_polygon.market_prices_daily
Source: https://docs.dune.com/data-catalog/curated/prediction-markets/polymarket/market_prices_daily

Polymarket daily price snapshots — outcome token prices aggregated by day.

The `polymarket_polygon.market_prices_daily` table contains daily Polymarket outcome token prices, derived from hourly pricing data.

## Table Schema

| Column         | Type        | Description                           |
| -------------- | ----------- | ------------------------------------- |
| `day`          | `TIMESTAMP` | Day for which the price is valid      |
| `condition_id` | `VARBINARY` | Unique market condition identifier    |
| `token_id`     | `UINT256`   | Token ID for the outcome              |
| `price`        | `DOUBLE`    | End-of-day price of the outcome token |

## Table sample

<TableSample />


# polymarket_polygon.market_prices_hourly
Source: https://docs.dune.com/data-catalog/curated/prediction-markets/polymarket/market_prices_hourly

Polymarket hourly price snapshots — outcome token prices aggregated by hour.

The `polymarket_polygon.market_prices_hourly` table contains hourly Polymarket outcome token prices.

## Table Schema

| Column         | Type        | Description                            |
| -------------- | ----------- | -------------------------------------- |
| `hour`         | `TIMESTAMP` | Hour for which the price is valid      |
| `condition_id` | `VARBINARY` | Unique market condition identifier     |
| `token_id`     | `UINT256`   | Token ID for the outcome               |
| `price`        | `DOUBLE`    | End-of-hour price of the outcome token |

## Table sample

<TableSample />


# polymarket_polygon.market_prices_latest
Source: https://docs.dune.com/data-catalog/curated/prediction-markets/polymarket/market_prices_latest

Polymarket latest prices — most recent outcome token prices for all active markets.

The `polymarket_polygon.market_prices_latest` table provides the most recent price for each Polymarket outcome token.

## Table Schema

| Column         | Type        | Description                            |
| -------------- | ----------- | -------------------------------------- |
| `timestamp`    | `TIMESTAMP` | When the price was last updated        |
| `condition_id` | `VARBINARY` | Unique market condition identifier     |
| `token_id`     | `UINT256`   | Token ID for the outcome               |
| `price`        | `DOUBLE`    | Most recent price of the outcome token |

## Table sample

<TableSample />


# polymarket_polygon.market_trades
Source: https://docs.dune.com/data-catalog/curated/prediction-markets/polymarket/market_trades

Polymarket trade events — buy/sell orders with prices, amounts, and trader addresses.

The `polymarket_polygon.market_trades` table contains trade-level activity across all Polymarket market outcomes on Polygon.

## Table Schema

| Column               | Type        | Description                                        |
| -------------------- | ----------- | -------------------------------------------------- |
| `block_number`       | `BIGINT`    | Block number                                       |
| `block_time`         | `TIMESTAMP` | UTC event block time                               |
| `tx_hash`            | `VARBINARY` | Transaction hash                                   |
| `evt_index`          | `INTEGER`   | Event index within the transaction                 |
| `action`             | `VARCHAR`   | Type of trade (CLOB or AMM)                        |
| `contract_address`   | `VARBINARY` | Contract address (CTF exchange or neg risk module) |
| `condition_id`       | `VARBINARY` | Unique identifier for the YES/NO pair              |
| `event_market_name`  | `VARCHAR`   | Overarching question for negRisk markets           |
| `question`           | `VARCHAR`   | Concrete outcome being bet on                      |
| `polymarket_link`    | `VARCHAR`   | Link to Polymarket page                            |
| `token_outcome`      | `VARCHAR`   | YES or NO token outcome                            |
| `neg_risk`           | `VARCHAR`   | Whether this is a neg\_risk market                 |
| `asset_id`           | `UINT256`   | ERC1155 token ID                                   |
| `price`              | `DOUBLE`    | Price of the outcome token                         |
| `amount`             | `DOUBLE`    | Amount in USD                                      |
| `shares`             | `DOUBLE`    | Number of shares transferred                       |
| `fee`                | `DOUBLE`    | Fees to Polymarket (currently not enabled)         |
| `maker`              | `VARBINARY` | Trader whose order is being filled                 |
| `taker`              | `VARBINARY` | Trader filling the order                           |
| `unique_key`         | `VARCHAR`   | Unique event/market key                            |
| `token_outcome_name` | `VARCHAR`   | Combined token outcome and question                |

## Table sample

<TableSample />

## Query performance

`market_trades` is a view — always include a `block_time` filter. For market-specific queries, also filter on `condition_id` or `question`.

```sql theme={null}
-- ✅ Good: time-bounded with market filter
SELECT * FROM polymarket_polygon.market_trades
WHERE block_time >= NOW() - INTERVAL '7' DAY
  AND condition_id = 0x...
```

## Example query

```sql theme={null}
-- Top markets by trading volume (last 7 days)
SELECT
  event_market_name,
  question,
  SUM(amount) AS total_volume_usd,
  COUNT(*) AS num_trades
FROM polymarket_polygon.market_trades
WHERE block_time >= NOW() - INTERVAL '7' DAY
GROUP BY 1, 2
ORDER BY 3 DESC
LIMIT 20
```


# Polymarket
Source: https://docs.dune.com/data-catalog/curated/prediction-markets/polymarket/overview

Curated Polymarket prediction market datasets on Dune

Polymarket is the leading onchain prediction market, operating on Polygon. Dune's curated Polymarket tables provide market metadata, trade-level activity, user positions, and pricing at multiple time granularities.

<Info>
  **Maintained by:** Dune · **Refresh:** \~24 hours · **Chain:** Polygon
</Info>

## Available Tables

<CardGroup>
  <Card title="polymarket_polygon.market_trades" icon="database" href="/data-catalog/curated/prediction-markets/polymarket/market_trades">
    Trade-level activity across all Polymarket market outcomes
  </Card>

  <Card title="polymarket_polygon.market_details" icon="database" href="/data-catalog/curated/prediction-markets/polymarket/market_details">
    Enriched market metadata, lifecycle status, and resolution fields
  </Card>

  <Card title="polymarket_polygon.positions" icon="database" href="/data-catalog/curated/prediction-markets/polymarket/positions">
    Daily user position balances by market outcome token
  </Card>

  <Card title="polymarket_polygon.market_prices_hourly" icon="database" href="/data-catalog/curated/prediction-markets/polymarket/market_prices_hourly">
    Hourly outcome token prices
  </Card>

  <Card title="polymarket_polygon.market_prices_daily" icon="database" href="/data-catalog/curated/prediction-markets/polymarket/market_prices_daily">
    Daily outcome token prices
  </Card>

  <Card title="polymarket_polygon.market_prices_latest" icon="database" href="/data-catalog/curated/prediction-markets/polymarket/market_prices_latest">
    Latest price per outcome token
  </Card>
</CardGroup>

## Notes

* `market_trades` includes three matching types: complementary trades (buyer ↔ seller), MINT (new outcome tokens created), and MERGE (YES+NO redeemed for collateral).
* Price tables are forward-filled from observed trade activity. `market_prices_hourly` is the highest-resolution pricing available.
* All tables use `condition_id` as the primary market identifier. Join with `market_details` for human-readable market questions.


# polymarket_polygon.positions
Source: https://docs.dune.com/data-catalog/curated/prediction-markets/polymarket/positions

Polymarket open positions — current outcome token holdings by address and market.

The `polymarket_polygon.positions` table contains daily user position balances by market outcome token on Polymarket.

## Table Schema

| Column              | Type        | Description                        |
| ------------------- | ----------- | ---------------------------------- |
| `condition_id`      | `VARBINARY` | Unique market condition identifier |
| `token_id`          | `UINT256`   | Token ID for the outcome           |
| `token_outcome`     | `VARCHAR`   | Token outcome (YES/NO)             |
| `address`           | `VARBINARY` | User wallet address                |
| `balance`           | `DOUBLE`    | Position balance in outcome tokens |
| `value_usd`         | `DOUBLE`    | Position value in USD              |
| `question`          | `VARCHAR`   | Market question text               |
| `event_market_name` | `VARCHAR`   | Event market name                  |
| `polymarket_link`   | `VARCHAR`   | Link to Polymarket page            |
| `unique_key`        | `VARCHAR`   | Unique position identifier         |

## Table sample

<TableSample />

## Example query

```sql theme={null}
-- Top position holders across all active markets
SELECT
  user_address,
  COUNT(DISTINCT condition_id) AS markets_held,
  SUM(position_value_usd) AS total_position_usd
FROM polymarket_polygon.positions
GROUP BY 1
ORDER BY 3 DESC
LIMIT 20
```


# polymarket_polygon.users_address_lookup
Source: https://docs.dune.com/data-catalog/curated/prediction-markets/polymarket/users_address_lookup

Mapping of Polymarket proxy wallets to owner addresses, with wallet type and initial funding details.

The `polymarket_polygon.users_address_lookup` table maps Polymarket proxy wallets (both Safe and Magic wallet types) to their owner addresses, including creation and first funding metadata.

## Table Schema

| Column                 | Type        | Description                                         |
| ---------------------- | ----------- | --------------------------------------------------- |
| `created_time`         | `TIMESTAMP` | Timestamp when the Polymarket wallet was created    |
| `block_number`         | `BIGINT`    | Block number when the Polymarket wallet was created |
| `wallet_type`          | `VARCHAR`   | Type of wallet (safe or magic)                      |
| `owner`                | `VARBINARY` | Owner address of the Polymarket wallet              |
| `polymarket_wallet`    | `VARBINARY` | Polymarket proxy wallet address                     |
| `created_tx_hash`      | `VARBINARY` | Transaction hash of the wallet creation             |
| `first_funded_time`    | `TIMESTAMP` | Timestamp of first funding received by the wallet   |
| `first_funded_by`      | `VARBINARY` | Address that first funded the wallet                |
| `first_funded_tx_hash` | `VARBINARY` | Transaction hash of first funding                   |
| `has_been_funded`      | `BOOLEAN`   | Whether the wallet has ever received funds          |

## Table sample

<TableSample />


# Prices overview
Source: https://docs.dune.com/data-catalog/curated/prices/overview

Token price data across multiple blockchains

Dune provides comprehensive, reliable token price data for use in your queries across 70+ blockchains. Our price system combines external market data with on-chain trading activity to deliver accurate pricing for both major tokens and the long tail of emerging assets. Whether you're building dashboards, conducting research, or powering applications, you can access consistent price data at multiple time granularities with transparent sourcing and quality controls.

<Info>
  **Maintained by:** Dune · **Refresh:** \~30 min · **Chains:** 70+ blockchains
</Info>

<Card title="Get This Data" icon="database" href="https://dune.com/enterprise?dataset=prices">
  Access price data via API, Datashare, or the Dune App.
</Card>

## Key Features

* **Multi-blockchain support**: Prices for tokens across 70+ blockchains
* **Multiple time granularities**: minute, hourly, daily, and latest price data
* **Source transparency**: Each price point includes its data source
* **Data quality**: Comprehensive filtering to ensure price reliability
* **Standardized native token addresses**: Native tokens (like ETH, BNB) have fixed contract addresses for consistency
* **Volume-weighted pricing**: Prices are calculated using volume-weighted averages for more accurate representation
* **Enhanced outlier detection**: Multi-layered filtering system to reduce impact of anomalous trades

## Available Tables

The `prices` schema exposes these main tables:

| Table           | Description                                         |
| --------------- | --------------------------------------------------- |
| `prices.latest` | The most recent price for each token                |
| `prices.day`    | Daily token prices using hybrid approach            |
| `prices.hour`   | Hourly token prices using hybrid approach           |
| `prices.minute` | Minute-by-minute token prices using hybrid approach |

## Methodology

### Hybrid Pricing Approach

All tables use the same methodology combining two data sources:

1. **Coinpaprika** (\~2,000 major tokens)
   * External market data from aggregated exchanges
   * Available at 5-minute intervals
   * Aggregated to hourly/daily, interpolated for minute-level

2. **DEX-derived** (long tail tokens)
   * On-chain trading activity from `dex.trades`
   * Quality filtering to reduce anomalous trades:
     * **VWMP Outlier Detection**: Prices deviating >3x from 7-day rolling median
     * **MAD Outlier Detection**: Prices deviating >2x median absolute deviation
     * **Transfer Outlier Detection**: Token amounts exceeding max transfer amounts
     * **Volume Outlier Detection**: Trades \<$0.01 or &gt;$1M
   * Aggregated into 1 hour intervals using volume-weighted averages
   * Minimum \$10k volume thresholds

3. **Forward-filling** when no activity exists:
   * Daily: 30 days max | Hourly: 7 days max | Minute: 2 days max

Token lists are defined in the [open-source repository](https://github.com/duneanalytics/spellbook/tree/main/dbt_subprojects/tokens/models/prices).

<Warning>
  Our dex-derived pricing represents our best-effort approach using comprehensive filtering and volume-weighted calculations to deliver accurate prices. While the methodology is designed to be as robust as possible, outliers and edge cases can occur in decentralized trading data. The methodology above provides full transparency into how prices are calculated.
</Warning>

## Coverage

* 900,000 unique tokens
* 70+ blockchains
* tokens are automatically added when they exceed a \$10k volume threshold

<DuneEmbed />

<CardGroup>
  <Card title="Check Price Coverage" href="https://dune.com/dune/does-dune-have-price-for-token" icon="magnifying-glass">
    You can test the coverage of the prices tables on this dashboard.
  </Card>
</CardGroup>

## Schema

All price tables share the following schema:

| Column             | Type        | Description                                              |
| ------------------ | ----------- | -------------------------------------------------------- |
| `blockchain`       | *varchar*   | Blockchain identifier (e.g., 'ethereum', 'arbitrum')     |
| `contract_address` | *varbinary* | Token contract address (fixed address for native tokens) |
| `symbol`           | *varchar*   | Token symbol (e.g., 'ETH', 'USDC')                       |
| `price`            | *double*    | USD price                                                |
| `timestamp`        | *timestamp* | Timestamp (start of minute, hour, or day)                |
| `decimals`         | *int*       | Token decimals                                           |
| `volume`           | *double*    | Trading volume in USD (from price source)                |
| `source`           | *varchar*   | Data source ('coinpaprika' or 'dex.trades')              |

## Technical Notes

* **Token identification**: Requires both `contract_address` AND `blockchain` (symbols are not unique)
* **Native tokens**: Use standardized addresses from `dune.blockchains` table. We mostly set native tokens to `0x000...`
* **Pricing independence**: Calculated separately per blockchain
* **Volume-weighted**: Uses volume-weighted averages for accuracy

### Solana Token Addresses

Solana tokens use base58-encoded mint addresses, but in Dune's price tables they are stored as `varbinary` in the `contract_address` column. To query Solana token prices, convert the base58 mint address to varbinary using `from_base58()`:

```sql theme={null}
SELECT 
  symbol,
  price,
  timestamp
FROM prices.day
WHERE blockchain = 'solana'
AND contract_address = from_base58('So11111111111111111111111111111111111111112') -- Wrapped SOL
AND timestamp >= NOW() - INTERVAL '7' DAY
```

To discover available Solana tokens and their addresses:

```sql theme={null}
SELECT DISTINCT 
  symbol, 
  contract_address, 
  to_base58(contract_address) as mint_address
FROM prices.usd
WHERE blockchain = 'solana'
LIMIT 100
```

### Source-Specific Variants

For specialized analysis, each granularity offers source-specific tables:

**Coinpaprika-only tables:**

* `prices_external.day`, `prices_external.hour`, `prices_external.minute`, `prices_external.latest`

**DEX-derived tables:**

* `prices_dex.day`, `prices_dex.hour`, `prices_dex.minute`, `prices_dex.latest`

*See individual granularity pages for detailed documentation on these variants.*

**Performance tip:** Use the coarsest granularity that meets your needs. Minute-level queries over long periods are resource-intensive.

## Usage Examples

Here are some examples of how to use the prices tables.

### Basic query to get the latest ETH price:

```sql theme={null}
SELECT price
FROM prices.latest
WHERE blockchain = 'ethereum' 
AND contract_address = 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 -- WETH
```

### Getting historical price data:

```sql theme={null}
SELECT
  timestamp,
  price
FROM prices.day
WHERE blockchain = 'ethereum'
AND contract_address = 0x1f9840a85d5af5bf1d1762f925bdaddc4201f984 -- UNI
AND timestamp >= NOW() - INTERVAL '30' DAY
```

### Finding the right native token address:

```sql theme={null}
-- Query to get the native token address for a specific blockchain
SELECT 
  name,
  token_address,
  token_symbol
FROM dune.blockchains
WHERE name = 'arbitrum'
```

## Legacy Tables

The following tables are maintained for historical compatibility:

* `prices.usd` - **View of `prices_external.minute`** (maintains legacy schema)

Note: `prices.usd` is a view of `prices_external.minute` while preserving the legacy schema for backward compatibility.

## When to Use These Tables

* Calculate USD values for token transfers, balances, and DeFi positions
* Build portfolio valuation tools and wallet trackers
* Power price feeds for dashboards, alerts, and automated reports
* Analyze token price movements and correlations across chains
* Benchmark token performance against market indices

## Query Performance

**Partition keys for `prices.day`, `prices.hour`, `prices.minute`:** `blockchain`, `contract_address`

Always filter on `blockchain` and a time range. For specific tokens, also filter on `contract_address` or `symbol`.

```sql theme={null}
-- ✅ Good: chain + time + token filter
SELECT * FROM prices.hour
WHERE blockchain = 'ethereum'
  AND contract_address = 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 -- USDC
  AND minute >= NOW() - INTERVAL '7' DAY

-- ✅ Good: using prices.latest for current values
SELECT * FROM prices.latest
WHERE blockchain = 'ethereum'
  AND symbol = 'WETH'
```

## Related Tables

* `tokens.erc20` — Token metadata (symbols, decimals) for joining with price data
* `dex.trades` — DEX trading data (prices are partially derived from on-chain trades)
* `tokens.transfers` — Token transfers that can be valued using price tables

<CardGroup>
  <Card title="Enterprise Data Solutions" icon="building" href="https://dune.com/enterprise">
    Need custom pricing feeds or dedicated support? Talk to our enterprise team.
  </Card>

  <Card title="Build Custom Models" icon="code" href="/api-reference/connectors/overview">
    Build private pricing pipelines with the dbt Connector.
  </Card>
</CardGroup>


# Daily Prices
Source: https://docs.dune.com/data-catalog/curated/prices/prices_day

Daily token price data across 70+ blockchains - hybrid approach combining centralized exchange and decentralized exchange data for comprehensive coverage

The `prices.day` table provides daily token prices using a **hybrid approach** that combines multiple data sources for maximum coverage:

1. **Coinpaprika prices** for tokens where we have reliable external data (\~2,000 major tokens, defined in [token lists](https://github.com/duneanalytics/spellbook/tree/main/dbt_subprojects/tokens/models/prices))
2. **DEX-derived prices** for the long tail of tokens not covered by coinpaprika

This hybrid methodology ensures comprehensive token coverage while maintaining price quality through different data sources optimized for different token categories.

## Table Schema

| Column            | Type      | Description                                              |
| ----------------- | --------- | -------------------------------------------------------- |
| blockchain        | varchar   | Blockchain identifier (e.g., 'ethereum', 'arbitrum')     |
| contract\_address | varbinary | Token contract address (fixed address for native tokens) |
| symbol            | varchar   | Token symbol (e.g., 'ETH', 'USDC')                       |
| timestamp         | timestamp | Date timestamp (00:00 UTC of each day)                   |
| price             | double    | Token price in USD (volume-weighted average)             |
| decimals          | int       | Token decimals                                           |
| volume            | double    | Trading volume in USD (from price source)                |
| source            | varchar   | Data source ('coinpaprika' or 'dex.trades')              |

## Table Sample

<TableSample />

## Implementation Details

The daily prices are built through these steps:

1. **Source prioritization**: Coinpaprika prices take precedence where available, DEX-derived prices fill gaps
2. **Token list management**: Lists defining which tokens use coinpaprika vs DEX are managed in the [open-source repository](https://github.com/duneanalytics/spellbook/tree/main/dbt_subprojects/tokens/models/prices)
3. **Data aggregation**: Group by day, calculating volume-weighted average price per day
4. **Forward filling**: Fill missing days with the previous day's price (forward filling)
5. **Expiration**: Set a 30-day expiration for forward filling to avoid stale data

### Alternative Tables

If you need prices from specific sources only:

#### `prices_external.day`

For purely coinpaprika-based daily prices:

* **Coverage**: Only tokens with Coinpaprika listings (\~2,000 tokens)
* **Source**: External exchange-aggregated pricing
* **Use case**: When you need stable, externally-validated daily pricing
* **Special note**: Used by `tokens.transfers` for stable pricing
* **Schema**: Same as `prices.day` but `source` is always 'coinpaprika'

#### `prices_dex.day`

For purely DEX algorithm-based daily prices:

* **Coverage**: All tokens with sufficient DEX trading volume
* **Source**: On-chain DEX trading activity only (from `dex.trades` table)
* **Use case**: When you need pricing that reflects actual on-chain liquidity and trading activity
* **Methodology**: Comprehensive outlier detection and quality filtering applied to DEX trades
* **Key difference**: Even tokens with coinpaprika coverage use DEX-derived prices for consistency
* **Schema**: Same as `prices.day` but `source` is always 'dex.trades'

**Example - Compare DEX vs combined pricing:**

```sql theme={null}
SELECT
  d.timestamp,
  d.symbol,
  d.price as dex_price,
  c.price as combined_price,
  (d.price - c.price) / c.price * 100 as price_diff_pct
FROM prices_dex.day d
JOIN prices.day c 
  ON d.blockchain = c.blockchain 
  AND d.contract_address = c.contract_address 
  AND d.timestamp = c.timestamp
WHERE d.blockchain = 'ethereum'
AND d.contract_address = 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 -- WETH
AND d.timestamp >= NOW() - INTERVAL '30' DAY
ORDER BY d.timestamp
```

## Usage

This table provides comprehensive daily price coverage by combining coinpaprika and DEX-derived sources. It's ideal for:

* Daily price trend analysis
* Portfolio valuations
* Day-over-day price comparisons
* General token price lookups

**Note**: The underlying data sources are aligned to 5-minute intervals for consistency and improved data quality.

**For specific use cases**: If you need purely coinpaprika or purely DEX-derived prices, use the dedicated source-specific tables instead.

## Latency and Update Frequency

The `prices.day` table is updated daily at 00:00 UTC, providing the closing price for the previous day. Data is typically available within 30 minutes of the daily close.

## Usage Examples

### Get ETH price history for the last month:

```sql theme={null}
SELECT
  timestamp,
  price
FROM prices.day
WHERE blockchain = 'ethereum'
AND contract_address = 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 -- WETH
AND timestamp >= NOW() - INTERVAL '30' DAY
ORDER BY timestamp
```

### Calculate monthly average price for multiple tokens:

```sql theme={null}
SELECT
  blockchain,
  symbol, -- Symbol included for readable output only
  date_trunc('month', timestamp) as month,
  avg(price) as avg_price
FROM prices.day
WHERE blockchain = 'ethereum'
AND contract_address IN (
  0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2, -- WETH
  0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48, -- USDC
  0x2260fac5e5542a773aa44fbcfedf7c193bc2c599  -- WBTC
)
AND timestamp >= NOW() - INTERVAL '90' DAY
GROUP BY 1,2,3
ORDER BY 1,2,3
```

### Get native token price using dune.blockchains:

```sql theme={null}
-- First get the native token address
WITH native_token AS (
  SELECT token_address
  FROM dune.blockchains
  WHERE name = 'ethereum'
)
-- Then use it to query the price
SELECT
  timestamp,
  price
FROM prices.day, native_token
WHERE blockchain = 'ethereum'
AND contract_address = token_address
AND timestamp >= NOW() - INTERVAL '30' DAY
ORDER BY timestamp
```

## Data Quality Notes

* Prices older than 30 days will not be forward-filled to avoid using stale data
* Native tokens (like ETH, BNB) are assigned fixed addresses for consistency
* For native tokens, use `dune.blockchains` table to get the standardized address for each blockchain
* The same token may have different prices on different blockchains due to bridging inefficiencies
* Always use `contract_address` and `blockchain` for precise token identification, never use `symbol` for joins or filters
* Prices are calculated using volume-weighted averages for more accurate representation
* **Quality Filtering**: The system includes filtering mechanisms to reduce the impact of anomalous trades
* **DEX-derived limitations**: DEX-derived prices can contain errors due to low liquidity, market manipulation, or anomalous trades
* **Fallback option**: For critical applications, consider using `prices_external.day` for more reliable pricing where available
* **Data validation**: Always validate prices for critical applications, especially for lesser-known tokens


# Hourly Prices
Source: https://docs.dune.com/data-catalog/curated/prices/prices_hour

Hourly token price data across 70+ blockchains - hybrid approach combining centralized exchange and decentralized exchange data for comprehensive coverage

The `prices.hour` table provides hourly token prices using the same **hybrid approach** as all other price tables:

1. **Coinpaprika prices** for tokens where we have reliable external data (\~2,000 major tokens)
2. **DEX-derived prices** for the long tail of tokens not covered by coinpaprika

This provides volume-weighted average prices for each hour, ensuring a continuous time series for more granular price analysis than daily data.

## Table Schema

| Column            | Type      | Description                                              |
| ----------------- | --------- | -------------------------------------------------------- |
| blockchain        | varchar   | Blockchain identifier (e.g., 'ethereum', 'arbitrum')     |
| contract\_address | varbinary | Token contract address (fixed address for native tokens) |
| symbol            | varchar   | Token symbol (e.g., 'ETH', 'USDC')                       |
| timestamp         | timestamp | Hour timestamp (00:00, 01:00, etc. UTC of each hour)     |
| price             | double    | Token price in USD (volume-weighted average)             |
| decimals          | int       | Token decimals                                           |
| volume            | double    | Trading volume in USD (from price source)                |
| source            | varchar   | Data source ('coinpaprika' or 'dex.trades')              |

## Table Sample

<TableSample />

## Implementation Details

The hourly prices are built through these steps:

1. **Source prioritization**: Coinpaprika prices for \~2,000 major tokens, DEX-derived prices for long tail tokens
2. **Data aggregation**: Group by hour, calculating volume-weighted average price per hour
3. **Forward filling**: Fill missing hours with the previous hour's price (forward filling)
4. **Expiration**: Set a 7-day (168 hour) expiration for forward filling to avoid stale data

### Source-Specific Variants

#### `prices_external.hour`

For purely coinpaprika-based hourly prices:

* **Coverage**: Only tokens with Coinpaprika listings (\~2,000 tokens)
* **Source**: External exchange-aggregated hourly pricing
* **Use case**: When you need stable, externally-validated hourly pricing
* **Schema**: Same as `prices.hour` but `source` is always 'coinpaprika'

#### `prices_dex.hour`

For purely DEX-derived hourly prices:

* **Coverage**: All tokens with sufficient DEX trading volume
* **Source**: On-chain DEX trading activity only
* **Use case**: When you need pricing that reflects actual on-chain liquidity
* **Schema**: Same as `prices.hour` but `source` is always 'dex.trades'

## Usage

This table is useful for intraday analysis and tracking price movements with higher granularity than daily data. It's suitable for examining price patterns within a day or across multiple days.

**Note**: The underlying data sources are aligned to 5-minute intervals for consistency and improved data quality.

## Latency and Update Frequency

The `prices.hour` table is updated hourly based on the upstream data pipeline. As a result, prices typically have a latency of approximately 1 hour from real-time.

## Usage Examples

Here are some examples of how to use the prices tables.

### Get hourly ETH prices for the last day:

```sql theme={null}
SELECT
  timestamp,
  price
FROM prices.hour
WHERE blockchain = 'ethereum'
AND contract_address = 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 -- WETH
AND timestamp >= NOW() - INTERVAL '1' DAY
ORDER BY timestamp
```

### Calculate volatility by hour of day:

```sql theme={null}
SELECT
  extract(hour from timestamp) as hour_of_day,
  avg(abs(price - lag(price) OVER (PARTITION BY blockchain, contract_address ORDER BY timestamp))
      / lag(price) OVER (PARTITION BY blockchain, contract_address ORDER BY timestamp)) as avg_hourly_change
FROM prices.hour
WHERE blockchain = 'ethereum'
AND contract_address = 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 -- WETH
AND timestamp >= NOW() - INTERVAL '30' DAY
GROUP BY 1
ORDER BY 1
```

## Data Quality Notes

* Prices older than 7 days (168 hours) will not be forward-filled to avoid using stale data
* Native tokens (like ETH, BNB) are assigned fixed addresses for consistency
* Hourly data is useful for analyzing intraday patterns and short-term price movements
* Always use `contract_address` and `blockchain` for precise token identification, never use `symbol` for joins or filters
* Prices are calculated using volume-weighted averages for more accurate representation
* **Quality Filtering**: The system includes filtering mechanisms to reduce the impact of anomalous trades
* **DEX-derived limitations**: DEX-derived prices can contain errors due to low liquidity, market manipulation, or anomalous trades
* **Fallback option**: For critical applications, consider using `prices_external.hour` for more reliable pricing where available
* **Data validation**: Always validate prices for critical applications, especially for lesser-known tokens


# Latest Prices
Source: https://docs.dune.com/data-catalog/curated/prices/prices_latest

Most recent price data for tokens across all supported blockchains

The `prices.latest` table provides the most recently available price for each token across all supported blockchains. This table is ideal for calculating current token values or displaying up-to-date prices.

## Table Schema

| Column            | Type      | Description                                              |
| ----------------- | --------- | -------------------------------------------------------- |
| blockchain        | varchar   | Blockchain identifier (e.g., 'ethereum', 'arbitrum')     |
| contract\_address | varbinary | Token contract address (fixed address for native tokens) |
| symbol            | varchar   | Token symbol (e.g., 'ETH', 'USDC')                       |
| price             | double    | Most recent token price in USD                           |
| decimals          | int       | Token decimals                                           |
| timestamp         | timestamp | Timestamp when this price was recorded                   |
| volume            | double    | Trading volume in USD (from price source)                |
| source            | varchar   | Data source ('coinpaprika' or 'dex.trades')              |

## Table Sample

<TableSample />

## Implementation Details

The latest prices are built by:

1. Taking the most recent price observation from each data source
2. Selecting the latest observation per token across all sources
3. Refreshed hourly to ensure prices stay current

## Usage

This table is perfect for querying the current price of tokens without needing to filter by timestamp or perform additional aggregations. It's designed for efficiency when you just need the most recent price.

## Usage Examples

Here are some examples of how to use the prices tables.

### Get current prices for major tokens:

```sql theme={null}
SELECT
  blockchain,
  symbol, -- Symbol included for readable output only
  price,
  timestamp
FROM prices.latest
WHERE (blockchain, contract_address) IN (
  ('ethereum', 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2), -- WETH
  ('ethereum', 0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48), -- USDC
  ('ethereum', 0x2260fac5e5542a773aa44fbcfedf7c193bc2c599), -- WBTC
  ('arbitrum', 0x82af49447d8a07e3bd95bd0d56f35241523fbab1), -- WETH on Arbitrum
  ('optimism', 0x4200000000000000000000000000000000000006)  -- WETH on Optimism
)
```

### Calculate total USD value of token holdings:

```sql theme={null}
WITH token_balances AS (
  SELECT
    token_address,
    sum(amount) as total_tokens
  FROM my_token_balance_table
  GROUP BY 1
)

SELECT
  b.token_address,
  p.symbol, -- Symbol included for readable output only
  b.total_tokens,
  b.total_tokens * p.price as usd_value
FROM token_balances b
JOIN prices.latest p
  ON p.blockchain = 'ethereum'
  AND p.contract_address = b.token_address
```

### Get prices for native tokens across multiple blockchains:

```sql theme={null}
-- Join with dune.blockchains to get native token prices
SELECT
  b.name as blockchain,
  b.token_symbol as native_token_symbol,
  p.price as native_token_price,
  p.timestamp
FROM dune.blockchains b
JOIN prices.latest p
  ON p.blockchain = b.name
  AND p.contract_address = b.token_address
WHERE b.name IN ('ethereum', 'arbitrum', 'optimism', 'polygon', 'gnosis', 'solana')
```

## Data Quality Notes

* Native tokens (like ETH, BNB) are assigned fixed addresses for consistency
* For native tokens, use `dune.blockchains` table to get the standardized address for each blockchain
* The timestamp column shows when the price was last updated, useful for determining freshness
* For historical analysis, use `prices.day`, `prices.hour`, or `prices.minute` instead
* Always use `contract_address` and `blockchain` for precise token identification, never use `symbol` for joins or filters
* **Quality Filtering**: The system includes filtering mechanisms to reduce the impact of anomalous trades
* **Data Limitations**: While filtering helps improve data quality, users should always validate prices for critical applications


# Minute Prices
Source: https://docs.dune.com/data-catalog/curated/prices/prices_minute

Minute-by-minute token price data across 70+ blockchains - hybrid approach combining centralized exchange and decentralized exchange data for comprehensive coverage

<Warning>
  `prices.minute` can produce unexpected results and high query costs for broad historical analysis. This table is interpolated from hourly anchor points (not direct minute-level trades), and DEX-derived rows can still contain outliers for low-liquidity tokens.

  For safer pricing in production or valuation-critical workflows, use `prices_external.minute` where coverage exists. For most historical analysis, prefer `prices.hour` (or `prices.day`) for better performance and stability.
</Warning>

The `prices.minute` table provides minute-level price data for tokens across multiple blockchains using the same **hybrid approach** as all other price tables:

1. **Coinpaprika prices** for tokens where we have reliable external data (\~2,000 major tokens)
2. **DEX-derived prices** for the long tail of tokens not covered by coinpaprika

Minute-level data uses interpolation from hourly anchor points to provide smooth, continuous pricing.

<Info>
  Minute-level data uses interpolation between hourly anchor points for smooth pricing. Forward-filling is applied for up to 48 hours when no trading activity exists.
</Info>

## Table Schema

| Column            | Type      | Description                                              |
| ----------------- | --------- | -------------------------------------------------------- |
| blockchain        | varchar   | Blockchain identifier (e.g., 'ethereum', 'arbitrum')     |
| contract\_address | varbinary | Token contract address (fixed address for native tokens) |
| symbol            | varchar   | Token symbol (e.g., 'ETH', 'USDC')                       |
| timestamp         | timestamp | Minute timestamp                                         |
| price             | double    | Token price in USD (volume-weighted average)             |
| decimals          | int       | Token decimals                                           |
| volume            | double    | Trading volume in USD (from price source)                |
| source            | varchar   | Data source ('coinpaprika' or 'dex.trades')              |

## Table Sample

<TableSample />

## Implementation Details

The minute prices are built using the hybrid approach with interpolation:

1. **Source prioritization**: Coinpaprika prices for \~2,000 major tokens, DEX-derived prices for long tail tokens
2. **Hourly interpolation**: Uses hourly data as anchor points for linear interpolation
3. **Linear interpolation**: Implements interpolation between hourly anchor points to create smooth minute-level data
4. **Noise reduction**: Reduces noise and outliers by using stable hourly data points as anchors
5. **Forward-filling**: The system forward-fills with the last available price for a maximum of 48 hours (2880 minutes) to avoid stale data
6. **Continuous time series**: Provides minute-by-minute data points for every minute between hourly anchors

### Source-Specific Variants

#### `prices_external.minute`

For purely coinpaprika-based minute prices:

* **Coverage**: Only tokens with Coinpaprika listings (\~2,000 tokens)
* **Source**: External exchange-aggregated minute pricing with interpolation
* **Use case**: When you need minute-level external price validation
* **Key role**: Serves as the underlying source for the `prices.usd` legacy view
* **Schema**: Same as `prices.minute` but `source` is always 'coinpaprika'

#### `prices_dex.minute`

For purely DEX-derived minute prices:

* **Coverage**: All tokens with sufficient DEX trading volume
* **Source**: On-chain DEX trading activity with interpolation
* **Use case**: When you need minute-level pricing that reflects on-chain activity
* **Schema**: Same as `prices.minute` but `source` is always 'dex.trades'

## Usage

This table is ideal for high-frequency analysis and examining short-term price movements. It's particularly useful for studying price impacts of specific events or transactions with high temporal precision.

**Important Notes**:

* The minute-level data is interpolated from hourly anchor points using the hybrid approach
* Provides comprehensive token coverage through coinpaprika and DEX-derived sources
* Provides smooth and consistent pricing while reducing the impact of noise and outliers

## Latency and Update Frequency

The `prices.minute` table is updated hourly based on the upstream data pipeline. As a result, prices typically have a latency of approximately 1 hour from real-time.

## Usage Examples

Here are some examples of how to use the prices tables.

### Get minute-by-minute ETH prices during a specific event:

```sql theme={null}
SELECT
  timestamp,
  price
FROM prices.minute
WHERE
  blockchain = 'ethereum'
  AND contract_address = 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 -- WETH
  AND timestamp >= NOW() - INTERVAL '2' HOUR
  AND timestamp <= NOW() - INTERVAL '1' HOUR
ORDER BY timestamp
```

### Analyze price volatility within short time frames:

```sql theme={null}
SELECT
  date_trunc('hour', timestamp) as hour,
  max(price) - min(price) as price_range,
  (max(price) - min(price)) / min(price) * 100 as volatility_pct
FROM prices.minute
WHERE
  blockchain = 'ethereum'
  AND contract_address = 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 -- WETH
  AND timestamp >= NOW() - INTERVAL '1' DAY
GROUP BY 1
ORDER BY 1
```

## Data Quality Notes

* Due to its high granularity, queries on this table may be more resource-intensive
* Consider using `prices.hour` or `prices.day` for longer time ranges if minute-level precision is not required
* **Comprehensive coverage**: Includes both coinpaprika and DEX-derived tokens through hybrid approach
* Native tokens (like ETH, BNB) are assigned fixed addresses for consistency
* Always use `contract_address` and `blockchain` for precise token identification, never use `symbol` for joins or filters
* **Interpolated Pricing**: Minute-level data is interpolated from hourly anchor points using hybrid methodology
* **Reduced Noise**: The interpolation approach reduces the impact of noise and outliers
* **48-Hour Forward-Fill**: The system forward-fills with the last available price for a maximum of 48 hours (2880 minutes) to avoid stale data
* **External source reliability**: Coinpaprika data provides stable, exchange-aggregated pricing
* **DEX-derived limitations**: DEX-derived prices can contain errors due to low liquidity, market manipulation, or anomalous trades
* **Safe pricing recommendation**: For valuation-critical or safety-sensitive use cases, prefer `prices_external.minute` where coverage exists
* **Minute interpolation caveat**: Values are derived via interpolation between hourly anchor points, not direct minute-level market observations
* **Volume caveat**: The `volume` column may be sparse (including null values) in parts of the dataset, especially on less liquid DEX-derived coverage
* **Data validation**: Always validate prices for critical applications, especially for lesser-known tokens


# USD Prices (Legacy)
Source: https://docs.dune.com/data-catalog/curated/prices/prices_usd

Legacy price tables with limited token coverage

These tables continue to work and update regularly, so you can keep using them if they meet your needs. However, for broader token coverage and improved functionality, consider the modern price tables.

<Info>
  **`prices.usd`** is based on coinpaprika data and covers \~2,800 tokens. For comprehensive coverage including newer tokens, use `prices.minute`, `prices.hour`, or `prices.day` which include both coinpaprika and DEX-derived pricing.
</Info>

## Why Consider Modern Tables?

* **More tokens**: 900,000+ vs \~2,800 in legacy tables
* **Hybrid approach**: Combines coinpaprika and DEX-derived pricing for maximum coverage
* **Same reliability**: Coinpaprika data quality maintained in modern tables
* **Additional features**: Source transparency, quality filtering, and standardized native token addresses

## Available Legacy Tables

| Table               | Coverage       | Description                                          |
| ------------------- | -------------- | ---------------------------------------------------- |
| `prices.usd`        | \~2,800 tokens | Historical prices with timestamps (coinpaprika data) |
| `prices.usd_daily`  | \~2,800 tokens | Daily historical prices                              |
| `prices.usd_latest` | \~2,800 tokens | Latest available price per token                     |

## Modern Alternatives (Recommended)

For broader coverage and additional features:

| Modern Table    | Coverage        | Best For                           |
| --------------- | --------------- | ---------------------------------- |
| `prices.day`    | 900,000+ tokens | Daily analysis with hybrid pricing |
| `prices.hour`   | 900,000+ tokens | Intraday analysis                  |
| `prices.minute` | 900,000+ tokens | High-frequency analysis            |
| `prices.latest` | 900,000+ tokens | latest prices                      |

**Migration examples:**

### Simple price lookup

```sql theme={null}
-- Legacy:
SELECT price, minute FROM prices.usd 
WHERE contract_address = 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 AND blockchain = 'ethereum'

-- Modern equivalent:
SELECT price, timestamp FROM prices.minute 
WHERE contract_address = 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 AND blockchain = 'ethereum'
```

### Daily aggregation (much faster with modern tables)

```sql theme={null}
-- Legacy - manually aggregate minute data:
SELECT 
  DATE(timestamp) as date,
  AVG(price) as avg_daily_price
FROM prices.usd 
WHERE contract_address = 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 
  AND blockchain = 'ethereum'
  AND timestamp >= NOW() - INTERVAL '30' DAY
GROUP BY DATE(timestamp)

-- Modern - use pre-aggregated daily table:
SELECT 
  timestamp as date,
  price as avg_daily_price
FROM prices.day 
WHERE contract_address = 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 
  AND blockchain = 'ethereum'
  AND timestamp >= NOW() - INTERVAL '30' DAY
```

### Token coverage comparison

```sql theme={null}
-- See the difference in token coverage:
SELECT COUNT(*) FROM prices.usd_latest;          -- ~2,800 tokens
SELECT COUNT(*) FROM prices.latest;              -- 900,000+ tokens
```

## Legacy Table Schema

All legacy tables share a similar schema:

| Column             | Type      | Description                                         |
| ------------------ | --------- | --------------------------------------------------- |
| `contract_address` | varbinary | Token contract address                              |
| `symbol`           | varchar   | Token symbol                                        |
| `price`            | double    | USD price                                           |
| `minute`           | timestamp | Price timestamp (`prices.usd_latest` excludes this) |
| `blockchain`       | varchar   | Blockchain identifier                               |

## Key Differences from Modern Tables

* **Token coverage**: Limited to \~2,800 tokens vs 900,000+ in modern tables
* **Data sources**: Coinpaprika only vs hybrid approach in modern tables
* **Schema**: Legacy format vs standardized modern schema with `source` column
* **Native tokens**: May use different address conventions vs standardized addresses

## Still Need Legacy Tables?

**No problem!** These tables continue to update and work reliably. You can:

* Keep using them if they cover your token needs
* Mix legacy and modern tables in your queries
* Gradually migrate to modern tables when convenient

For comprehensive documentation on the modern pricing system, see [Prices Overview](/data-catalog/curated/prices/overview).


# rollup_economics_ethereum.l1_fees
Source: https://docs.dune.com/data-catalog/curated/rollup-economics/l1_fees

L2 rollup posting costs — data availability and verification fees paid to Ethereum L1 by each rollup.

The `rollup_economics_ethereum.l1_fees` table contains daily fees paid by each Ethereum L2 rollup to post data and proofs on L1, broken down by calldata, blob, and verification costs.

## Table Schema

| Column                    | Type        | Description                    |
| ------------------------- | ----------- | ------------------------------ |
| `day`                     | `TIMESTAMP` | Day when transactions occurred |
| `name`                    | `VARCHAR`   | Rollup name                    |
| `data_fee_native`         | `DOUBLE`    | Calldata gas fee in ETH        |
| `data_fee_usd`            | `DOUBLE`    | Calldata gas fee in USD        |
| `calldata_gas_used`       | `BIGINT`    | Calldata gas consumed          |
| `verification_fee_native` | `DOUBLE`    | Proof verification fee in ETH  |
| `verification_fee_usd`    | `DOUBLE`    | Proof verification fee in USD  |
| `blob_fee_native`         | `DOUBLE`    | Blob gas fee in ETH            |
| `blob_fee_usd`            | `DOUBLE`    | Blob gas fee in USD            |
| `l1_fee_native`           | `DOUBLE`    | Total L1 fees paid in ETH      |
| `l1_fee_usd`              | `DOUBLE`    | Total L1 fees paid in USD      |

## Table sample

<TableSample />


# rollup_economics_ethereum.l2_revenue
Source: https://docs.dune.com/data-catalog/curated/rollup-economics/l2_revenue

L2 rollup revenue — transaction fees collected from users on each rollup.

The `rollup_economics_ethereum.l2_revenue` table contains daily gas fee revenue earned by each Ethereum L2 rollup.

## Table Schema

| Column       | Type        | Description                    |
| ------------ | ----------- | ------------------------------ |
| `day`        | `TIMESTAMP` | Day when transactions occurred |
| `name`       | `VARCHAR`   | Rollup name                    |
| `l2_rev`     | `DOUBLE`    | L2 gas fee revenue in ETH      |
| `l2_rev_usd` | `DOUBLE`    | L2 gas fee revenue in USD      |

## Table sample

<TableSample />


# Rollup Economics
Source: https://docs.dune.com/data-catalog/curated/rollup-economics/overview

Curated rollup profitability datasets for Ethereum L2s on Dune

Dune's rollup economics tables track the financial performance of Ethereum L2 rollups by comparing their revenue (gas fees earned from users on L2) against their costs (fees paid to post data and proofs on Ethereum L1).

<Info>
  **Maintained by:** Dune · **Refresh:** \~1 hour · **Coverage:** 10 rollups (revenue), 25 rollups (L1 costs)
</Info>

<Card title="Get This Data" icon="database" href="https://dune.com/enterprise?dataset=rollup-economics">
  Access rollup economics data via API, Datashare, or the Dune App.
</Card>

## Available Tables

<CardGroup>
  <Card title="rollup_economics_ethereum.l2_revenue" icon="database" href="/data-catalog/curated/rollup-economics/l2_revenue">
    Daily gas fee revenue earned by each rollup on L2
  </Card>

  <Card title="rollup_economics_ethereum.l1_fees" icon="database" href="/data-catalog/curated/rollup-economics/l1_fees">
    Daily fees paid by each rollup to post data/proofs on Ethereum L1
  </Card>
</CardGroup>

## When to Use These Tables

* Analyze rollup profitability (L2 revenue minus L1 costs)
* Compare L1 posting costs across rollups
* Track the impact of EIP-4844 blobs on rollup costs
* Benchmark rollup revenue and growth over time

## Coverage

**L2 Revenue (10 rollups):** Scroll, Mantle, Zora, Linea, Arbitrum, zkSync Era, OP Mainnet, Base, Polygon zkEVM, Blast

**L1 Fees (25 rollups):** Orderly Network, Starknet, Mode, Starkware, Base, Boba, Polygon zkEVM, Blast, Hypr Network, Scroll, Lyra, Public Goods Network, Zora, Mantle, Linea, IMX, zkSync Lite, Loopring, Metis, Aevo, Arbitrum, Manta Pacific, zkSync Era, OP Mainnet, Fraxtal

<Tip>
  L1 fees covers more rollups because tracking posting costs only requires monitoring known addresses on Ethereum, while L2 revenue requires Dune to have indexed each L2 chain directly.
</Tip>

<Info>
  **Need a rollup that's not listed?** We can add new rollup coverage. [Contact our enterprise team →](https://dune.com/enterprise)
</Info>

## Query Performance

Both tables are incremental with daily granularity. Filter on `day` and optionally `name`.

```sql theme={null}
-- ✅ Good: time-bounded
SELECT * FROM rollup_economics_ethereum.l2_revenue
WHERE day >= DATE '2025-01-01'
  AND name = 'base'
```

## Methodology

These tables are maintained by Dune ([source code](https://github.com/duneanalytics/spellbook)).

**L2 Revenue** aggregates total gas fees from `gas.fees` for each rollup's chain, grouped by day.

**L1 Fees** monitors known rollup batch-posting and proof-verification addresses on Ethereum, decomposing costs into: calldata gas costs, proof verification costs (ZK rollups), and EIP-4844 blob gas costs (post-Dencun).

## Example Queries

**Rollup profitability (revenue minus costs):**

```sql theme={null}
SELECT
  r.name,
  r.day,
  r.l2_rev_usd,
  f.l1_fee_usd,
  r.l2_rev_usd - f.l1_fee_usd AS profit_usd
FROM rollup_economics_ethereum.l2_revenue r
JOIN rollup_economics_ethereum.l1_fees f
  ON r.name = f.name AND r.day = f.day
WHERE r.day >= DATE '2025-01-01'
ORDER BY r.day DESC, profit_usd DESC
```

**L1 cost breakdown: calldata vs blobs vs verification:**

```sql theme={null}
SELECT
  name,
  SUM(data_fee_usd) AS calldata_costs,
  SUM(blob_fee_usd) AS blob_costs,
  SUM(verification_fee_usd) AS verification_costs,
  SUM(l1_fee_usd) AS total_l1_costs
FROM rollup_economics_ethereum.l1_fees
WHERE day >= DATE '2025-01-01'
GROUP BY 1
ORDER BY 5 DESC
```

## Related Tables

* `gas.fees` — Transaction-level gas data used to compute L2 revenue

<CardGroup>
  <Card title="Enterprise Data Solutions" icon="building" href="https://dune.com/enterprise">
    Need custom rollup analytics or additional L2 coverage? Talk to our enterprise team.
  </Card>

  <Card title="Build Custom Models" icon="code" href="/api-reference/connectors/overview">
    Build private rollup profitability dashboards with the dbt Connector.
  </Card>
</CardGroup>


# Stablecoin Activity Enriched (EVM)
Source: https://docs.dune.com/data-catalog/curated/stablecoins/activity-enriched/stablecoins-evm-activity-enriched

Transfer-level stablecoin activity classification across 37 supported EVM chains

The `stablecoins_evm.activity_enriched` table classifies each stablecoin transfer into an activity category (for example DEX, CEX, bridge, lending, issuer).

<PremiumDatasetAccessCard />

## Why these enriched tables matter

Stablecoin analysis comes down to two fundamental questions:

1. Where are stablecoins right now? (balances)
2. How did they get there? (activity)

This activity-enriched table answers the second question by tracing the economic path of transfers across categories such as DEX trading, lending, borrowing, bridging, internal transfers, and payment-like flows.

### What this dataset is designed to do

* Explain how stablecoin balances move through the ecosystem.
* Attribute transfer activity with transparent, reproducible logic.
* Provide a defensible foundation for flow analysis.

The goal is to turn stablecoin flow data from noise into structured economic insight.

## Table schema

| Column               | Type        | Description                             |
| -------------------- | ----------- | --------------------------------------- |
| `blockchain`         | `VARCHAR`   | Chain name                              |
| `block_month`        | `DATE`      | First day of month (partition column)   |
| `block_date`         | `DATE`      | Transaction date                        |
| `block_time`         | `TIMESTAMP` | Transaction timestamp                   |
| `block_number`       | `BIGINT`    | Block number                            |
| `tx_hash`            | `VARBINARY` | Transaction hash                        |
| `evt_index`          | `BIGINT`    | Transfer event index                    |
| `activity_evt_index` | `BIGINT`    | Matched activity event index (nullable) |
| `trace_address`      | `VARCHAR`   | Trace address (nullable)                |
| `token_standard`     | `VARCHAR`   | Token standard (`erc20`)                |
| `token_address`      | `VARBINARY` | Token contract address                  |
| `token_symbol`       | `VARCHAR`   | Token symbol                            |
| `currency`           | `VARCHAR`   | ISO 4217 code                           |
| `amount_raw`         | `UINT256`   | Raw transfer amount                     |
| `amount`             | `DOUBLE`    | Decimals-adjusted amount                |
| `price_usd`          | `DOUBLE`    | USD price used for valuation            |
| `amount_usd`         | `DOUBLE`    | USD amount                              |
| `from_address`       | `VARBINARY` | Sender                                  |
| `to_address`         | `VARBINARY` | Recipient                               |
| `category`           | `VARCHAR`   | Activity category                       |
| `activity`           | `VARCHAR`   | Activity label                          |
| `project_address`    | `VARBINARY` | Matched project address (nullable)      |
| `project_name`       | `VARCHAR`   | Matched project name (nullable)         |
| `project_version`    | `VARCHAR`   | Matched project version (nullable)      |
| `unique_key`         | `VARCHAR`   | Unique transfer identifier              |

## Value possibilities

The `category` and `activity` columns are intentionally standardized so downstream models, dashboards, and monitoring can rely on deterministic value vocabularies.

| `category`      | Allowed `activity` values                                               | Description                                                                                |
| --------------- | ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ |
| `dex_swap`      | `dex_swap`                                                              | Direct swaps on decentralized exchanges and DEX aggregators (Uniswap, Curve, 1inch, etc.). |
| `flashloan`     | `flashloan_borrow`, `flashloan_repay`                                   | Atomic borrow-and-repay within a single transaction.                                       |
| `issuer`        | `issuer_peg_rebalance`                                                  | Peg stability module operations (e.g. Sky PSM, Spark PSM). Ethereum only.                  |
| `yield`         | `yield_deposit`, `yield_withdraw`                                       | Deposits and withdrawals from yield strategy contracts. Ethereum only.                     |
| `cex`           | `cex_deposit`, `cex_withdraw`, `cex_internal_transfer`                  | Transfers to/from known centralized exchange wallets.                                      |
| `lending`       | `lending_supply`, `lending_borrow`, `lending_repay`, `lending_withdraw` | Supply, borrow, repay, and withdraw on lending protocols.                                  |
| `bridge`        | `bridge_deposit`, `bridge_withdraw`                                     | Cross-chain transfers via bridge contracts.                                                |
| `dex_liquidity` | `dex_liquidity_supply`, `dex_liquidity_withdraw`                        | Non-swap transfers to/from DEX contracts (liquidity adds/removes).                         |
| `unidentified`  | `unidentified_activity`                                                 | Transfers not matched to any known activity pattern.                                       |

This mapping enables consistent flow segmentation, KPI rollups, and alerting logic without custom per-dashboard label handling.

As protocol coverage expands, new values may be added in backward-compatible fashion.

## Methodology

Classification is done at the transfer level, not the transaction level.

1. Start from curated stablecoin transfer rows in `stablecoins_evm.transfers`.
2. Build candidate matches for each transfer against activity-specific datasets (for example DEX, bridge, CEX, flashloan, lending, and issuer signals) using transfer-level keys such as `tx_hash`, token identity, and amount context.
3. Resolve conflicts with a deterministic precedence order, so each transfer gets exactly one winning category.
4. Write unmatched transfers as `unidentified` to preserve full coverage instead of dropping rows.

### Important interpretation details

* One transaction can map to multiple categories if it contains multiple stablecoin transfers.
* `project_address`, `project_name`, and `project_version` are populated only when a protocol/entity match exists.
* Priority rules improve consistency, but edge cases still exist when protocols emit similar transfer patterns in the same transaction.

## Sample query

```sql theme={null}
SELECT
    a.block_date
    , a.category
    , COUNT(*) AS transfers
    , SUM(a.amount_usd) AS volume_usd
FROM stablecoins_evm.activity_enriched AS a
WHERE a.blockchain = 'ethereum'
    AND a.block_date >= CURRENT_DATE - INTERVAL '30' DAY
GROUP BY a.block_date, a.category
ORDER BY a.block_date DESC, volume_usd DESC
```

## Notes

* One transfer maps to one output row (highest-priority match wins).
* For performance, filter by `blockchain` and `block_month`.


# Stablecoin Activity Enriched (Solana)
Source: https://docs.dune.com/data-catalog/curated/stablecoins/activity-enriched/stablecoins-solana-activity-enriched

Transfer-level stablecoin activity classification on Solana

The `stablecoins_solana.activity_enriched` table classifies each stablecoin transfer on Solana into an activity category.

<PremiumDatasetAccessCard />

## Why these enriched tables matter

Stablecoin analysis comes down to two fundamental questions:

1. Where are stablecoins right now? (balances)
2. How did they get there? (activity)

This activity-enriched table answers the second question by tracing the economic path of transfers across categories such as DEX trading, lending, borrowing, bridging, internal transfers, and payment-like flows.

### What this dataset is designed to do

* Explain how stablecoin balances move through the ecosystem.
* Attribute transfer activity with transparent, reproducible logic.
* Provide a defensible foundation for flow analysis.

The goal is to turn stablecoin flow data from noise into structured economic insight.

## Table schema

| Column                    | Type        | Description                           |
| ------------------------- | ----------- | ------------------------------------- |
| `blockchain`              | `VARCHAR`   | Chain name (`solana`)                 |
| `block_month`             | `DATE`      | First day of month (partition column) |
| `block_date`              | `DATE`      | Transaction date                      |
| `block_time`              | `TIMESTAMP` | Transaction timestamp                 |
| `block_slot`              | `BIGINT`    | Solana slot number                    |
| `tx_id`                   | `VARCHAR`   | Transaction signature                 |
| `outer_instruction_index` | `BIGINT`    | Outer instruction index               |
| `inner_instruction_index` | `BIGINT`    | Inner instruction index (nullable)    |
| `token_mint_address`      | `VARCHAR`   | Token mint address                    |
| `token_symbol`            | `VARCHAR`   | Token symbol                          |
| `currency`                | `VARCHAR`   | ISO 4217 code                         |
| `from_owner`              | `VARCHAR`   | Sender wallet                         |
| `to_owner`                | `VARCHAR`   | Receiver wallet                       |
| `amount_raw`              | `UINT256`   | Raw transfer amount                   |
| `amount`                  | `DOUBLE`    | Decimals-adjusted amount              |
| `amount_usd`              | `DOUBLE`    | USD amount                            |
| `outer_executing_account` | `VARCHAR`   | Program executing instruction         |
| `category`                | `VARCHAR`   | Activity category                     |
| `activity`                | `VARCHAR`   | Activity label                        |
| `project_address`         | `VARCHAR`   | Matched project address (nullable)    |
| `project_name`            | `VARCHAR`   | Matched project name (nullable)       |
| `project_version`         | `VARCHAR`   | Matched project version (nullable)    |
| `unique_key`              | `VARCHAR`   | Unique transfer identifier            |

## Value possibilities

The `category` and `activity` columns are intentionally standardized so downstream models, dashboards, and monitoring can rely on deterministic value vocabularies.

| `category`                  | Allowed `activity` values                                                                       | Description                                                   |
| --------------------------- | ----------------------------------------------------------------------------------------------- | ------------------------------------------------------------- |
| `dex_swap`                  | `dex_swap`                                                                                      | Direct swaps on decentralized exchanges.                      |
| `cex`                       | `cex_deposit`, `cex_withdraw`, `cex_internal_transfer`                                          | Transfers to/from known centralized exchange wallets.         |
| `issuer`                    | `issuer_mint`, `issuer_burn`, `issuer_unidentified`                                             | Stablecoin minting, redemption, and peg stability operations. |
| `flashloan`                 | `flashloan_borrow`, `flashloan_repay`, `flashloan_unidentified`                                 | Atomic borrow-and-repay within a single transaction.          |
| `lending`                   | `lending_supply`, `lending_borrow`, `lending_repay`, `lending_withdraw`, `lending_unidentified` | Supply, borrow, repay, and withdraw on lending protocols.     |
| `yield`                     | `yield_unidentified`                                                                            | Transfers to/from yield strategy or wrapper programs.         |
| `bridge`                    | `bridge_deposit`, `bridge_withdraw`                                                             | Cross-chain transfers via bridge programs.                    |
| `unidentified`              | `unidentified_activity`                                                                         | Transfers not matched to any known activity pattern.          |
| `unidentified_bot_activity` | `unidentified_bot_activity`                                                                     | High-volume automated program patterns not yet classified.    |

This mapping enables consistent flow segmentation, KPI rollups, and alerting logic without custom per-dashboard label handling.

As protocol coverage expands, new values may be added in backward-compatible fashion.

## Methodology

Classification is done at the transfer level, not the transaction level.

1. Start from curated stablecoin transfer rows in `stablecoins_solana.transfers`.
2. Evaluate each transfer against category-specific detection logic using Solana-native context (transaction signature, instruction indexes, token mint, transfer amount, and known program/address labels).
3. Apply deterministic priority rules when multiple category matches exist for a transfer.
4. Keep full transfer coverage by assigning unmatched rows to `unidentified` (or `unidentified_bot_activity` for high-volume automated program patterns).

### Important interpretation details

* The same transaction can produce different categories across its individual transfers.
* Instruction index context is important on Solana for distinguishing activity legs inside one transaction.
* `project_address`, `project_name`, and `project_version` are populated only when a confident protocol/entity match exists.

## Sample query

```sql theme={null}
SELECT
    a.block_date
    , a.category
    , COUNT(*) AS transfers
    , SUM(a.amount_usd) AS volume_usd
FROM stablecoins_solana.activity_enriched AS a
WHERE a.block_date >= CURRENT_DATE - INTERVAL '30' DAY
GROUP BY a.block_date, a.category
ORDER BY a.block_date DESC, volume_usd DESC
```

## Notes

* One transfer maps to one output row (highest-priority match wins).
* For performance, filter by `blockchain` and `block_month`.


# Stablecoin Activity Enriched (Tron)
Source: https://docs.dune.com/data-catalog/curated/stablecoins/activity-enriched/stablecoins-tron-activity-enriched

Planned transfer-level stablecoin activity classification on Tron

This page is reserved for `stablecoins_tron.activity_enriched`.

<Info>
  Coming soon. This dataset is planned to follow the same transfer-level activity classification pattern as EVM and Solana enriched activity tables.
</Info>

For methodology details today, see:

* `/data-catalog/curated/stablecoins/activity-enriched/stablecoins-evm-activity-enriched`
* `/data-catalog/curated/stablecoins/activity-enriched/stablecoins-solana-activity-enriched`


# Stablecoin Balances Enriched (EVM)
Source: https://docs.dune.com/data-catalog/curated/stablecoins/balances-enriched/stablecoins-evm-balances-enriched

Daily stablecoin balances and circulating supply with address-type enrichment across 37 supported EVM chains.

The `stablecoins_evm.balances_enriched` table extends EVM stablecoin balances with address classification, entity tags, whale flags, and a circulating supply flag.

<PremiumDatasetAccessCard />

## Why these enriched tables matter

Stablecoin analysis comes down to two fundamental questions:

1. Where are stablecoins right now? (balances)
2. How did they get there? (activity)

This balances-enriched table answers the first question by going beyond raw balances and adding attribution for where capital sits: CEX, lending, treasury, yield, bridge, whale concentration, and more.

## Table schema

| Column                | Type        | Description                                                                                                                                                                                                                                                                                                        |
| --------------------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `blockchain`          | `VARCHAR`   | Chain name                                                                                                                                                                                                                                                                                                         |
| `day`                 | `DATE`      | Balance date (partition column)                                                                                                                                                                                                                                                                                    |
| `address`             | `VARBINARY` | Holder address                                                                                                                                                                                                                                                                                                     |
| `token_symbol`        | `VARCHAR`   | Token symbol                                                                                                                                                                                                                                                                                                       |
| `token_address`       | `VARBINARY` | Token contract address                                                                                                                                                                                                                                                                                             |
| `token_standard`      | `VARCHAR`   | Token standard (`erc20`)                                                                                                                                                                                                                                                                                           |
| `token_id`            | `VARCHAR`   | Always `NULL`                                                                                                                                                                                                                                                                                                      |
| `balance_raw`         | `UINT256`   | Raw balance                                                                                                                                                                                                                                                                                                        |
| `balance`             | `DOUBLE`    | Decimals-adjusted balance                                                                                                                                                                                                                                                                                          |
| `balance_usd`         | `DOUBLE`    | USD value                                                                                                                                                                                                                                                                                                          |
| `currency`            | `VARCHAR`   | ISO 4217 code                                                                                                                                                                                                                                                                                                      |
| `address_category`    | `VARCHAR`   | Address category (see below)                                                                                                                                                                                                                                                                                       |
| `address_subcategory` | `VARCHAR`   | Address subcategory                                                                                                                                                                                                                                                                                                |
| `address_project`     | `VARCHAR`   | Project/entity name (nullable)                                                                                                                                                                                                                                                                                     |
| `address_version`     | `VARCHAR`   | Project version (nullable)                                                                                                                                                                                                                                                                                         |
| `address_label`       | `VARCHAR`   | Label value (nullable)                                                                                                                                                                                                                                                                                             |
| `is_smart_contract`   | `BOOLEAN`   | Contract flag                                                                                                                                                                                                                                                                                                      |
| `is_whale`            | `BOOLEAN`   | Address holds >= \$10M total stablecoins that day                                                                                                                                                                                                                                                                  |
| `is_circulating`      | `BOOLEAN`   | `true` when the balance contributes to circulating supply. `false` for lock-and-mint / rollup-escrow / check-balance / non-minting bridge escrows, issuer bridge escrow, and CEX locked-token wallets (e.g., Binance Stablecoin Proof of Assets). Use `WHERE is_circulating = true` to compute circulating supply. |
| `last_updated`        | `TIMESTAMP` | Last balance update time                                                                                                                                                                                                                                                                                           |

## Address categories

Every address receives exactly one `address_category` — no double counting is possible by construction. When an address matches a curated label, that label wins. Unlabeled addresses fall through: smart contract → `unidentified_smart_contract`, EOA with >= \$10M → `unidentified_whale`, otherwise → `unidentified`.

When an address appears in multiple label sets, a fixed priority order resolves the conflict (table is ordered by priority, highest first):

| `address_category`            | Allowed `address_subcategory` values           | Description                                                                            |
| ----------------------------- | ---------------------------------------------- | -------------------------------------------------------------------------------------- |
| `erc20_contract`              | `erc20_contract`                               | Canonical stablecoin token contracts defining supply. Not deployed capital.            |
| `dex`                         | `dex_liquidity`, `dex_execution`               | Stablecoins in decentralized exchange pools and routing contracts.                     |
| `lending`                     | `lending_liquidity`, `lending_execution`       | Stablecoins deployed as credit in lending protocols.                                   |
| `bridge`                      | `bridge_liquidity`                             | Stablecoins escrowed or locked for cross-chain transfers.                              |
| `yield`                       | `yield_liquidity`, `yield_execution`           | Stablecoins in strategy or wrapper contracts earning passive yield.                    |
| `issuer`                      | `issuer_operations`, `issuer_treasury`         | Stablecoin monetary infrastructure — minting, redemption, peg management.              |
| `treasury_or_governance`      | `treasury`, `treasury_collector`, `governance` | Protocol-controlled capital for governance, reserves, or fees.                         |
| `cex`                         | `cex`                                          | Known exchange-controlled wallets (hot and cold). Not user deposit addresses.          |
| `burn`                        | `burn`                                         | Irrecoverable token sinks (dead/burn addresses).                                       |
| `unidentified_smart_contract` | `unidentified_smart_contract`                  | Contracts detected onchain but not yet categorized.                                    |
| `unidentified_whale`          | `unidentified_whale`                           | Unlabeled EOAs holding >= \$10M total stablecoin balance that day. Recalculated daily. |
| `unidentified`                | `unidentified`                                 | Addresses with no known classification.                                                |

As label coverage expands, new values may be added in backward-compatible fashion.

## Methodology

1. Start from daily rows in `stablecoins_evm.balances`.
2. Join curated address labels to assign `address_category`, subcategory, and project metadata where a label exists.
3. Derive `is_smart_contract` (from creation traces), `is_whale` (>= \$10M total stablecoin balance), and `is_circulating` (true unless the address is a bridge escrow / issuer bridge escrow / CEX locked-token wallet) flags per address per day.
4. Apply the priority waterfall for unlabeled addresses to maintain complete coverage.

Category totals should be interpreted as "where balances sit" rather than ownership or liability accounting. Labels represent the best-known economic function of an address and can evolve as coverage improves.

## Sample query

```sql theme={null}
SELECT
    b.address_category
    , b.token_symbol
    , SUM(b.balance_usd) AS total_usd
FROM stablecoins_evm.balances_enriched AS b
WHERE b.blockchain = 'ethereum'
    AND b.day = CURRENT_DATE
    AND b.balance > 0
GROUP BY b.address_category, b.token_symbol
ORDER BY total_usd DESC
```

## Notes

* For performance, filter by `blockchain` and `day`.
* For circulating supply, filter `WHERE is_circulating = true`. For bridge exposure, filter `WHERE address_category = 'bridge'`. Both are intentionally retained in the table.

<StablecoinBalancesSupplyNote />


# Stablecoin Balances Enriched (Solana)
Source: https://docs.dune.com/data-catalog/curated/stablecoins/balances-enriched/stablecoins-solana-balances-enriched

Daily stablecoin balances and circulating supply with address-type enrichment on Solana.

The `stablecoins_solana.balances_enriched` table extends Solana stablecoin balances with address classification, whale flags, and a circulating supply flag.

<PremiumDatasetAccessCard />

## Why these enriched tables matter

Stablecoin analysis comes down to two fundamental questions:

1. Where are stablecoins right now? (balances)
2. How did they get there? (activity)

This balances-enriched table answers the first question by going beyond raw balances and adding attribution for where capital sits: CEX, lending, treasury, yield, bridge, whale concentration, and more.

## Table schema

| Column                | Type        | Description                                                                                                                                                                                                                                                                          |
| --------------------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `blockchain`          | `VARCHAR`   | Chain name (`solana`)                                                                                                                                                                                                                                                                |
| `day`                 | `DATE`      | Balance date (partition column)                                                                                                                                                                                                                                                      |
| `address`             | `VARCHAR`   | Wallet address                                                                                                                                                                                                                                                                       |
| `token_symbol`        | `VARCHAR`   | Token symbol                                                                                                                                                                                                                                                                         |
| `token_address`       | `VARCHAR`   | Token mint address                                                                                                                                                                                                                                                                   |
| `token_standard`      | `VARCHAR`   | Token standard (`spl_token` or `token2022`)                                                                                                                                                                                                                                          |
| `token_id`            | `VARCHAR`   | Always `NULL`                                                                                                                                                                                                                                                                        |
| `balance_raw`         | `UINT256`   | Raw balance                                                                                                                                                                                                                                                                          |
| `balance`             | `DOUBLE`    | Decimals-adjusted balance                                                                                                                                                                                                                                                            |
| `balance_usd`         | `DOUBLE`    | USD value                                                                                                                                                                                                                                                                            |
| `currency`            | `VARCHAR`   | ISO 4217 code                                                                                                                                                                                                                                                                        |
| `address_category`    | `VARCHAR`   | Address category (see below)                                                                                                                                                                                                                                                         |
| `address_subcategory` | `VARCHAR`   | Address subcategory (nullable)                                                                                                                                                                                                                                                       |
| `address_project`     | `VARCHAR`   | Project/entity name (nullable)                                                                                                                                                                                                                                                       |
| `address_version`     | `VARCHAR`   | Project version (nullable)                                                                                                                                                                                                                                                           |
| `address_label`       | `VARCHAR`   | Label value (nullable)                                                                                                                                                                                                                                                               |
| `is_whale`            | `BOOLEAN`   | Address holds >= \$10M total stablecoins that day                                                                                                                                                                                                                                    |
| `is_circulating`      | `BOOLEAN`   | `true` when the balance contributes to circulating supply. `false` for bridge escrows (lock-and-mint, rollup-escrow, check-balance, non-minting subcategories), issuer bridge escrow, and CEX locked-token wallets. Use `WHERE is_circulating = true` to compute circulating supply. |
| `last_updated`        | `TIMESTAMP` | Last balance update time                                                                                                                                                                                                                                                             |

## Address categories

Every address receives exactly one `address_category` — no double counting is possible by construction. When an address matches a curated label, that label wins. Unlabeled addresses fall through: >= \$10M balance → `unidentified_whale`, otherwise → `unidentified`.

When an address appears in multiple label sets, a fixed priority order resolves the conflict (table is ordered by priority, highest first):

| `address_category`       | Allowed `address_subcategory` values           | Description                                                                                 |
| ------------------------ | ---------------------------------------------- | ------------------------------------------------------------------------------------------- |
| `bridge`                 | `bridge_liquidity`                             | Stablecoins escrowed or locked for cross-chain transfers.                                   |
| `dex`                    | `dex_liquidity`, `dex_execution`               | Stablecoins in decentralized exchange pools and routing contracts.                          |
| `lending`                | `lending_liquidity`, `lending_execution`       | Stablecoins deployed as credit in lending protocols.                                        |
| `yield`                  | `yield_liquidity`, `yield_execution`           | Stablecoins in strategy or wrapper contracts earning passive yield.                         |
| `issuer`                 | `issuer_operations`, `issuer_treasury`         | Stablecoin monetary infrastructure — minting, redemption, peg management.                   |
| `treasury_or_governance` | `treasury`, `treasury_collector`, `governance` | Protocol-controlled capital for governance, reserves, or fees.                              |
| `cex`                    | `cex`                                          | Known exchange-controlled wallets (hot and cold). Not user deposit addresses.               |
| `burn`                   | `burn`                                         | Irrecoverable token sinks (dead/burn addresses).                                            |
| `unidentified_whale`     | `unidentified_whale`                           | Unlabeled addresses holding >= \$10M total stablecoin balance that day. Recalculated daily. |
| `unidentified`           | `unidentified`                                 | Addresses with no known classification.                                                     |

As label coverage expands, new values may be added in backward-compatible fashion.

## Methodology

1. Start from daily rows in `stablecoins_solana.balances`.
2. Join curated Solana address labels to assign category, subcategory, and project metadata where available.
3. Derive `is_whale` (>= \$10M total stablecoin balance) and `is_circulating` (true unless the address is a bridge escrow / issuer bridge escrow / CEX locked-token wallet) flags per address per day.
4. Apply the priority waterfall for unlabeled addresses to maintain complete coverage.

Category totals should be interpreted as "where balances sit" rather than ownership or liability accounting. Labels represent the best-known economic function of an address and can evolve as coverage improves.

## Sample query

```sql theme={null}
SELECT
    b.address_category
    , b.token_symbol
    , SUM(b.balance_usd) AS total_usd
FROM stablecoins_solana.balances_enriched AS b
WHERE b.day = CURRENT_DATE
    AND b.balance > 0
GROUP BY b.address_category, b.token_symbol
ORDER BY total_usd DESC
```

## Notes

* For performance, filter by `blockchain` and `day`.
* For circulating supply, filter `WHERE is_circulating = true`. For bridge exposure, filter `WHERE address_category = 'bridge'`. Both are intentionally retained in the table.

<StablecoinBalancesSupplyNote />


# Stablecoin Balances Enriched (Tron)
Source: https://docs.dune.com/data-catalog/curated/stablecoins/balances-enriched/stablecoins-tron-balances-enriched

Planned daily stablecoin balances and circulating supply with address-type enrichment on Tron.

This page is reserved for `stablecoins_tron.balances_enriched`.

<Info>
  Coming soon. This dataset is planned to follow the same address-classification pattern as EVM and Solana enriched balance tables, including the `is_circulating` flag for computing circulating supply.
</Info>

For methodology details today, see:

* `/data-catalog/curated/stablecoins/balances-enriched/stablecoins-evm-balances-enriched`
* `/data-catalog/curated/stablecoins/balances-enriched/stablecoins-solana-balances-enriched`

When this table is live, it will follow the same balance-interpretation rules: balances include bridge-locked, issuer-escrow, and CEX-locked funds by default. Filter `WHERE is_circulating = true` to compute circulating supply.


# Stablecoin Balances (EVM)
Source: https://docs.dune.com/data-catalog/curated/stablecoins/balances/stablecoins-evm-balances

Daily stablecoin balances per address across 37 supported EVM chains

The `stablecoins_evm.balances` table contains daily stablecoin balances per address across 37 supported EVM chains.

One row represents one address-token balance snapshot for a specific day. Coverage is ERC20 stablecoin balances.

<PrepackagedEnrichedCtaCard href="/data-catalog/curated/stablecoins/balances-enriched/stablecoins-evm-balances-enriched" />

## Table schema

| Column           | Type        | Description               |
| ---------------- | ----------- | ------------------------- |
| `blockchain`     | `VARCHAR`   | Chain name                |
| `day`            | `DATE`      | Balance date              |
| `address`        | `VARBINARY` | Holder address            |
| `token_symbol`   | `VARCHAR`   | Token symbol              |
| `token_address`  | `VARBINARY` | Token contract address    |
| `token_standard` | `VARCHAR`   | Token standard (`erc20`)  |
| `token_id`       | `VARCHAR`   | Token id (typically NULL) |
| `balance_raw`    | `UINT256`   | Raw balance               |
| `balance`        | `DOUBLE`    | Decimals-adjusted balance |
| `balance_usd`    | `DOUBLE`    | USD value                 |
| `currency`       | `VARCHAR`   | ISO 4217 currency code    |
| `last_updated`   | `TIMESTAMP` | Last balance update time  |

<TableSample />

## Sample Queries

```sql theme={null}
SELECT
    b.blockchain
    , b.token_symbol
    , SUM(b.balance_usd) AS total_supply_usd
FROM stablecoins_evm.balances AS b
WHERE b.day = CURRENT_DATE
    AND b.balance > 0
GROUP BY b.blockchain, b.token_symbol
ORDER BY total_supply_usd DESC
```

## Notes

* Balances are forward-filled by day.
* For best performance, filter by `blockchain` and `day`.
* For multichain aggregate balances, see `stablecoins_multichain.balances`.

<StablecoinBalancesSupplyNote />


# Stablecoin Balances (Multichain)
Source: https://docs.dune.com/data-catalog/curated/stablecoins/balances/stablecoins-multichain-balances

Normalized daily stablecoin balances across EVM, Solana, and Tron

The `stablecoins_multichain.balances` table is a normalized multichain balance view across:

<PrepackagedEnrichedCtaCard href="/data-catalog/curated/stablecoins/overview" title="Use the prepackaged enriched versions" />

* EVM stablecoin balances
* Solana stablecoin balances
* Tron stablecoin balances

It standardizes `address` and `token_address` fields as `VARCHAR` for cross-chain analysis.

One row represents one address-token balance snapshot for a specific day after cross-chain normalization.

## Table schema

| Column           | Type        | Description                              |
| ---------------- | ----------- | ---------------------------------------- |
| `blockchain`     | `VARCHAR`   | Chain name                               |
| `day`            | `DATE`      | Balance date                             |
| `address`        | `VARCHAR`   | Holder address (normalized)              |
| `token_symbol`   | `VARCHAR`   | Token symbol                             |
| `token_address`  | `VARCHAR`   | Token contract/mint address (normalized) |
| `token_standard` | `VARCHAR`   | Token standard                           |
| `token_id`       | `VARCHAR`   | Token id (typically NULL)                |
| `balance_raw`    | `UINT256`   | Raw balance                              |
| `balance`        | `DOUBLE`    | Decimals-adjusted balance                |
| `balance_usd`    | `DOUBLE`    | USD value                                |
| `currency`       | `VARCHAR`   | ISO 4217 currency code                   |
| `last_updated`   | `TIMESTAMP` | Last balance update time                 |

<TableSample />

## Sample Queries

```sql theme={null}
SELECT
    b.blockchain
    , SUM(b.balance_usd) AS total_supply_usd
FROM stablecoins_multichain.balances AS b
WHERE b.day = CURRENT_DATE
    AND b.balance > 0
GROUP BY b.blockchain
ORDER BY total_supply_usd DESC
```

## Notes

* This is currently the stablecoin multichain aggregate table.
* For chain-specific analysis, use `stablecoins_evm.balances`, `stablecoins_solana.balances`, and `stablecoins_tron.balances`.

<StablecoinBalancesSupplyNote />


# Stablecoin Balances (Solana)
Source: https://docs.dune.com/data-catalog/curated/stablecoins/balances/stablecoins-solana-balances

Daily stablecoin balances per wallet on Solana

The `stablecoins_solana.balances` table contains daily stablecoin balances per wallet on Solana.

One row represents one wallet-token balance snapshot for a specific day. Coverage includes both SPL and SPL2022 stablecoin balances.

<PrepackagedEnrichedCtaCard href="/data-catalog/curated/stablecoins/balances-enriched/stablecoins-solana-balances-enriched" />

## Table schema

| Column           | Type        | Description                                |
| ---------------- | ----------- | ------------------------------------------ |
| `blockchain`     | `VARCHAR`   | Chain name (`solana`)                      |
| `day`            | `DATE`      | Balance date                               |
| `address`        | `VARCHAR`   | Wallet address                             |
| `token_symbol`   | `VARCHAR`   | Token symbol                               |
| `token_address`  | `VARCHAR`   | Token mint address                         |
| `token_standard` | `VARCHAR`   | Token standard (`spl_token` / `token2022`) |
| `token_id`       | `VARCHAR`   | Token id (typically NULL)                  |
| `currency`       | `VARCHAR`   | ISO 4217 currency code                     |
| `balance_raw`    | `UINT256`   | Raw balance                                |
| `balance`        | `DOUBLE`    | Decimals-adjusted balance                  |
| `balance_usd`    | `DOUBLE`    | USD value                                  |
| `last_updated`   | `TIMESTAMP` | Last balance update time                   |

<TableSample />

## Sample Queries

```sql theme={null}
SELECT
    b.day
    , b.token_symbol
    , SUM(b.balance_usd) AS total_supply_usd
FROM stablecoins_solana.balances AS b
WHERE b.balance > 0
    AND b.day >= CURRENT_DATE - INTERVAL '30' DAY
GROUP BY b.day, b.token_symbol
ORDER BY b.day DESC, total_supply_usd DESC
```

## Notes

* Balances are forward-filled by day.
* For best performance, filter by `day`.
* For multichain aggregate balances, see `stablecoins_multichain.balances`.

<StablecoinBalancesSupplyNote />


# Stablecoin Balances (Tron)
Source: https://docs.dune.com/data-catalog/curated/stablecoins/balances/stablecoins-tron-balances

Daily stablecoin balances per wallet on Tron

The `stablecoins_tron.balances` table contains daily stablecoin balances per wallet on Tron.

One row represents one wallet-token balance snapshot for a specific day. Coverage is TRC20 stablecoin balances.

<PrepackagedEnrichedCtaCard href="/data-catalog/curated/stablecoins/balances-enriched/stablecoins-tron-balances-enriched" />

It includes both 0x-format and base58-format address fields.

## Table schema

| Column             | Type        | Description                     |
| ------------------ | ----------- | ------------------------------- |
| `blockchain`       | `VARCHAR`   | Chain name (`tron`)             |
| `day`              | `DATE`      | Balance date                    |
| `address`          | `VARBINARY` | Holder address (0x)             |
| `address_varchar`  | `VARCHAR`   | Holder address (base58)         |
| `token_symbol`     | `VARCHAR`   | Token symbol                    |
| `token_address`    | `VARCHAR`   | Token contract address (base58) |
| `contract_address` | `VARBINARY` | Token contract address (0x)     |
| `token_standard`   | `VARCHAR`   | Token standard (`trc20`)        |
| `token_id`         | `VARCHAR`   | Token id (typically NULL)       |
| `balance_raw`      | `UINT256`   | Raw balance                     |
| `balance`          | `DOUBLE`    | Decimals-adjusted balance       |
| `balance_usd`      | `DOUBLE`    | USD value                       |
| `currency`         | `VARCHAR`   | ISO 4217 currency code          |
| `last_updated`     | `TIMESTAMP` | Last balance update time        |

<TableSample />

## Sample Queries

```sql theme={null}
SELECT
    b.day
    , b.token_symbol
    , SUM(b.balance_usd) AS total_supply_usd
FROM stablecoins_tron.balances AS b
WHERE b.balance > 0
    AND b.day >= CURRENT_DATE - INTERVAL '30' DAY
GROUP BY b.day, b.token_symbol
ORDER BY b.day DESC
```

## Notes

* Balances are forward-filled by day.
* For best performance, filter by `day`.
* For multichain aggregate balances, see `stablecoins_multichain.balances`.

<StablecoinBalancesSupplyNote />


# Stablecoins
Source: https://docs.dune.com/data-catalog/curated/stablecoins/overview

Curated stablecoin transfers and balances across EVM, Solana, Tron, and multichain views

Two questions define stablecoin analysis: **where are balances right now**, and **how did they get there**. Foundation tables provide normalized transfer and balance records for chain and multichain analysis, while enriched tables classify transfer intent and address behavior with transparent methodology across EVM, Solana, and Tron.

<Info>
  **Maintained by:** Dune · **Chains:** 37 EVM chains, Solana, Tron
</Info>

<Card title="Get This Data" icon="database" href="https://dune.com/collection/stablecoins/overview?dataset=stablecoins">
  Access stablecoin data via API, Datashare, or the Dune App.
</Card>

<Info>
  Explore these datasets in the [stablecoins collection](https://dune.com/collection/stablecoins/overview) with interactive dashboards you can filter, compare, and drill into.
</Info>

***

<Info>
  The enriched datasets in the `Balances enriched` and `Activity enriched` sections are refreshed daily.
</Info>

## Balances enriched

<Note>Premium dataset — requires additional access.</Note>

**Every balance, labeled by holder type.**

Measure where stablecoin balances sit across CEX, DEX, bridge, lending, treasury, yield, issuer, burn, and unlabeled buckets. Daily snapshots with standardized address-category taxonomy and EOA versus smart-contract differentiation help track deployment patterns, concentration risk, and structural balance shifts over time.

**Use cases**

* Track balance migration across holder categories over time
* Monitor lending and CEX balance share by chain and token
* Compare EOA and smart-contract balance share by category

**Tables**

<CardGroup>
  <Card title="EVM balances enriched" href="/data-catalog/curated/stablecoins/balances-enriched/stablecoins-evm-balances-enriched">
    Daily EVM balances with address classification and whale flags
  </Card>

  <Card title="Solana balances enriched" href="/data-catalog/curated/stablecoins/balances-enriched/stablecoins-solana-balances-enriched">
    Daily Solana balances with address classification and whale flags
  </Card>

  <Card title="Tron balances enriched" href="/data-catalog/curated/stablecoins/balances-enriched/stablecoins-tron-balances-enriched">
    Planned daily Tron balances with address classification
  </Card>
</CardGroup>

`Updated daily · 35+ chains · Standardized address taxonomy · EOA and smart-contract split · Premium dataset`

***

## Activity enriched

<Note>Premium dataset — requires additional access.</Note>

**From transfer noise to signal.**

Track why stablecoins move, not just how much they move. Transfer volume on its own is often ambiguous, so each transfer is qualified with trigger-aware logic and classified into an economic action. Use this to separate DEX, bridge, CEX, lending, and issuer flows.

**Use cases**

* Turn raw transfer counts into intent-level flow analysis
* Decompose multi-leg transactions into economic actions
* Detect regime shifts by category, chain, and token

**Tables**

<CardGroup>
  <Card title="EVM activity enriched" href="/data-catalog/curated/stablecoins/activity-enriched/stablecoins-evm-activity-enriched">
    Transfer-level activity classification across 37 supported EVM chains
  </Card>

  <Card title="Solana activity enriched" href="/data-catalog/curated/stablecoins/activity-enriched/stablecoins-solana-activity-enriched">
    Transfer-level activity classification on Solana
  </Card>

  <Card title="Tron activity enriched" href="/data-catalog/curated/stablecoins/activity-enriched/stablecoins-tron-activity-enriched">
    Planned transfer-level activity classification on Tron
  </Card>
</CardGroup>

`Updated daily · Transfer-level intent classification · One transfer, one category · Premium dataset`

***

## Foundation tables

**The raw data behind the enriched layers.**

Raw transfer events and daily balance snapshots across EVM, Solana, and Tron, plus a multichain balances view, with no labels or enrichment applied. These tables give you full history, token-level granularity, and USD-denominated amounts for building your own analytics.

**Use cases**

* Compute net flows between any pair of addresses
* Build custom holder-concentration metrics from raw balances
* Backtest strategies against full transfer history

### Transfers

Every stablecoin transfer event with sender, receiver, amount, token metadata, and USD value.

<Info>
  **Refresh:** \~1 hour
</Info>

<CardGroup>
  <Card title="EVM transfers" href="/data-catalog/curated/stablecoins/transfers/stablecoins-evm-transfers">
    Stablecoin transfers across supported EVM networks
  </Card>

  <Card title="Solana transfers" href="/data-catalog/curated/stablecoins/transfers/stablecoins-solana-transfers">
    Stablecoin transfers on Solana
  </Card>

  <Card title="Tron transfers" href="/data-catalog/curated/stablecoins/transfers/stablecoins-tron-transfers">
    Stablecoin transfers on Tron with 0x and base58 fields
  </Card>

  <Card title="Multichain transfers" href="/data-catalog/curated/stablecoins/transfers/stablecoins-multichain-transfers">
    Normalized transfers across EVM, Solana, and Tron
  </Card>
</CardGroup>

### Balances

Daily end-of-day stablecoin balances per address with token metadata and USD value.

<Info>
  **Refresh:** daily (data as of yesterday)
</Info>

<CardGroup>
  <Card title="EVM balances" href="/data-catalog/curated/stablecoins/balances/stablecoins-evm-balances">
    Daily stablecoin balances for addresses on EVM networks
  </Card>

  <Card title="Solana balances" href="/data-catalog/curated/stablecoins/balances/stablecoins-solana-balances">
    Daily stablecoin balances for addresses on Solana
  </Card>

  <Card title="Tron balances" href="/data-catalog/curated/stablecoins/balances/stablecoins-tron-balances">
    Daily stablecoin balances for addresses on Tron
  </Card>

  <Card title="Multichain balances" href="/data-catalog/curated/stablecoins/balances/stablecoins-multichain-balances">
    Normalized stablecoin balances across EVM, Solana, and Tron
  </Card>
</CardGroup>

### Reference

<CardGroup>
  <Card title="Multichain tokens" href="/data-catalog/curated/stablecoins/stablecoins-multichain-tokens">
    Reference table of all tracked stablecoins with token metadata
  </Card>
</CardGroup>

`Updated daily · Chain + multichain coverage · Raw transfers and balances`


# Stablecoin Tokens (Multichain)
Source: https://docs.dune.com/data-catalog/curated/stablecoins/stablecoins-multichain-tokens

Reference table of all tracked stablecoins across EVM, Solana, and Tron with token metadata.

The `stablecoins_multichain.tokens` table is a reference table listing all tracked stablecoins across EVM, Solana, and Tron ecosystems with enriched symbol and decimals metadata.

One row represents one stablecoin token on one blockchain.

This table is useful for:

* Looking up which stablecoins are tracked per chain
* Joining with transfer or balance tables for token metadata
* Filtering stablecoin activity by currency peg (USD, EUR, etc.)

## Table Schema

| Column          | Type      | Description                                        |
| --------------- | --------- | -------------------------------------------------- |
| `blockchain`    | `VARCHAR` | Chain name                                         |
| `token_address` | `VARCHAR` | Token contract/mint address                        |
| `currency`      | `VARCHAR` | ISO 4217 currency code the stablecoin is pegged to |
| `symbol`        | `VARCHAR` | Token symbol                                       |
| `decimals`      | `BIGINT`  | Token decimals                                     |

<TableSample />

## Sample Queries

```sql theme={null}
SELECT
    t.blockchain
    , t.symbol
    , t.currency
    , t.token_address
FROM stablecoins_multichain.tokens AS t
ORDER BY t.blockchain, t.symbol
```


# Stablecoin Transfers (EVM)
Source: https://docs.dune.com/data-catalog/curated/stablecoins/transfers/stablecoins-evm-transfers

Stablecoin transfer events across 37 supported EVM chains

The `stablecoins_evm.transfers` table contains curated stablecoin transfer records across 37 supported EVM chains.

One row represents one ERC20 stablecoin transfer event at log granularity.

<PrepackagedEnrichedCtaCard href="/data-catalog/curated/stablecoins/activity-enriched/stablecoins-evm-activity-enriched" />

This table is useful for:

* stablecoin flow analysis by chain, token, and address
* transfer volume analysis in native units and USD
* cross-chain stablecoin transfer comparisons

## Table schema

| Column           | Type        | Description                           |
| ---------------- | ----------- | ------------------------------------- |
| `blockchain`     | `VARCHAR`   | Chain name                            |
| `block_month`    | `DATE`      | First day of month (partition column) |
| `block_date`     | `DATE`      | Transaction date                      |
| `block_time`     | `TIMESTAMP` | Transaction timestamp                 |
| `block_number`   | `BIGINT`    | Block number                          |
| `tx_hash`        | `VARBINARY` | Transaction hash                      |
| `evt_index`      | `BIGINT`    | Transfer event index                  |
| `trace_address`  | `VARCHAR`   | Trace address (nullable)              |
| `token_standard` | `VARCHAR`   | Token standard (`erc20`)              |
| `token_address`  | `VARBINARY` | Token contract address                |
| `token_symbol`   | `VARCHAR`   | Token symbol                          |
| `currency`       | `VARCHAR`   | ISO 4217 currency code                |
| `amount_raw`     | `UINT256`   | Raw transfer amount                   |
| `amount`         | `DOUBLE`    | Decimals-adjusted amount              |
| `price_usd`      | `DOUBLE`    | USD price used for valuation          |
| `amount_usd`     | `DOUBLE`    | USD amount                            |
| `from`           | `VARBINARY` | Sender address                        |
| `to`             | `VARBINARY` | Recipient address                     |
| `unique_key`     | `VARCHAR`   | Unique transfer identifier            |

<TableSample />

## Sample Queries

```sql theme={null}
SELECT
    t.block_date
    , t.blockchain
    , t.token_symbol
    , SUM(t.amount_usd) AS volume_usd
    , COUNT(*) AS transfers
FROM stablecoins_evm.transfers AS t
WHERE t.block_date >= CURRENT_DATE - INTERVAL '7' DAY
GROUP BY t.block_date, t.blockchain, t.token_symbol
ORDER BY t.block_date DESC, volume_usd DESC
```

## Notes

* For partition pruning, filter by `blockchain` and `block_month`.


# Stablecoin Transfers (Multichain)
Source: https://docs.dune.com/data-catalog/curated/stablecoins/transfers/stablecoins-multichain-transfers

Unified stablecoin transfer events across EVM, Solana, and Tron in a single cross-chain view.

The `stablecoins_multichain.transfers` table unions stablecoin transfer records from all supported ecosystems — EVM (37 chains), Solana, and Tron — into a single cross-chain view with normalized address and hash types (VARCHAR).

One row represents one stablecoin transfer event.

This table is useful for:

* Cross-ecosystem stablecoin flow analysis
* Aggregate transfer volume across all supported chains
* Comparing stablecoin movement patterns across EVM, Solana, and Tron

## Table Schema

| Column           | Type        | Description                                          |
| ---------------- | ----------- | ---------------------------------------------------- |
| `blockchain`     | `VARCHAR`   | Chain name                                           |
| `block_month`    | `DATE`      | First day of month (partition column)                |
| `block_date`     | `DATE`      | Transaction date                                     |
| `block_time`     | `TIMESTAMP` | Transaction timestamp                                |
| `block_number`   | `BIGINT`    | Block number (null for Solana)                       |
| `tx_hash`        | `VARCHAR`   | Transaction hash                                     |
| `evt_index`      | `BIGINT`    | Event index within the transaction (null for Solana) |
| `token_standard` | `VARCHAR`   | Token standard (e.g. `erc20`, `spl_token`)           |
| `token_address`  | `VARCHAR`   | Token contract/mint address                          |
| `token_symbol`   | `VARCHAR`   | Token symbol                                         |
| `currency`       | `VARCHAR`   | ISO 4217 currency code                               |
| `amount_raw`     | `UINT256`   | Raw transfer amount                                  |
| `amount`         | `DOUBLE`    | Decimals-adjusted amount                             |
| `price_usd`      | `DOUBLE`    | USD price per unit                                   |
| `amount_usd`     | `DOUBLE`    | USD value of transfer                                |
| `from`           | `VARCHAR`   | Sender address                                       |
| `to`             | `VARCHAR`   | Recipient address                                    |
| `unique_key`     | `VARCHAR`   | Unique transfer identifier                           |

<TableSample />

## Sample Queries

```sql theme={null}
SELECT
    t.block_date
    , t.blockchain
    , t.token_symbol
    , SUM(t.amount_usd) AS volume_usd
    , COUNT(*) AS transfers
FROM stablecoins_multichain.transfers AS t
WHERE t.block_date >= CURRENT_DATE - INTERVAL '7' DAY
GROUP BY t.block_date, t.blockchain, t.token_symbol
ORDER BY t.block_date DESC, volume_usd DESC
```

## Notes

* Addresses and hashes are cast to VARCHAR for cross-ecosystem compatibility.
* For partition pruning, filter by `blockchain` and `block_month`.


# Stablecoin Transfers (Solana)
Source: https://docs.dune.com/data-catalog/curated/stablecoins/transfers/stablecoins-solana-transfers

Stablecoin transfer events on Solana

The `stablecoins_solana.transfers` table contains curated stablecoin transfer records on Solana.

One row represents one transfer instruction call at instruction granularity. Coverage includes both SPL and SPL2022 stablecoin transfers.

<PrepackagedEnrichedCtaCard href="/data-catalog/curated/stablecoins/activity-enriched/stablecoins-solana-activity-enriched" />

## Table schema

| Column                    | Type        | Description                                        |
| ------------------------- | ----------- | -------------------------------------------------- |
| `blockchain`              | `VARCHAR`   | Chain name (`solana`)                              |
| `block_month`             | `DATE`      | First day of month (partition column)              |
| `block_date`              | `DATE`      | Transaction date                                   |
| `block_time`              | `TIMESTAMP` | Transaction timestamp                              |
| `block_slot`              | `BIGINT`    | Solana slot number                                 |
| `tx_id`                   | `VARCHAR`   | Transaction signature                              |
| `tx_index`                | `BIGINT`    | Transaction index in slot                          |
| `outer_instruction_index` | `BIGINT`    | Outer instruction index                            |
| `inner_instruction_index` | `BIGINT`    | Inner instruction index                            |
| `token_version`           | `VARCHAR`   | Token standard version (`spl_token` / `token2022`) |
| `token_mint_address`      | `VARCHAR`   | Token mint address                                 |
| `token_symbol`            | `VARCHAR`   | Token symbol                                       |
| `currency`                | `VARCHAR`   | ISO 4217 currency code                             |
| `amount_raw`              | `UINT256`   | Raw transfer amount                                |
| `amount`                  | `DOUBLE`    | Decimals-adjusted amount                           |
| `price_usd`               | `DOUBLE`    | USD price used for valuation                       |
| `amount_usd`              | `DOUBLE`    | USD amount                                         |
| `from_owner`              | `VARCHAR`   | Sender wallet                                      |
| `to_owner`                | `VARCHAR`   | Receiver wallet                                    |
| `from_token_account`      | `VARCHAR`   | Source token account                               |
| `to_token_account`        | `VARCHAR`   | Destination token account                          |
| `tx_signer`               | `VARCHAR`   | Transaction signer                                 |
| `outer_executing_account` | `VARCHAR`   | Program executing outer instruction                |
| `action`                  | `VARCHAR`   | Transfer action label                              |
| `unique_key`              | `VARCHAR`   | Unique transfer identifier                         |

<TableSample />

## Sample Queries

```sql theme={null}
SELECT
    t.block_date
    , t.token_symbol
    , SUM(t.amount_usd) AS volume_usd
    , COUNT(*) AS transfers
FROM stablecoins_solana.transfers AS t
WHERE t.block_date >= CURRENT_DATE - INTERVAL '7' DAY
GROUP BY t.block_date, t.token_symbol
ORDER BY t.block_date DESC, volume_usd DESC
```

## Notes

* For partition pruning, filter by `block_month`.


# Stablecoin Transfers (Tron)
Source: https://docs.dune.com/data-catalog/curated/stablecoins/transfers/stablecoins-tron-transfers

Stablecoin transfer events on Tron

The `stablecoins_tron.transfers` table contains curated stablecoin transfer records on Tron.

One row represents one TRC20 transfer event at event-log granularity.

<PrepackagedEnrichedCtaCard href="/data-catalog/curated/stablecoins/activity-enriched/stablecoins-tron-activity-enriched" />

It includes both `VARBINARY` (0x) and `VARCHAR` (base58) address/hash representations.

## Table schema

| Column                     | Type        | Description                           |
| -------------------------- | ----------- | ------------------------------------- |
| `blockchain`               | `VARCHAR`   | Chain name (`tron`)                   |
| `block_month`              | `DATE`      | First day of month (partition column) |
| `block_date`               | `DATE`      | Transaction date                      |
| `block_time`               | `TIMESTAMP` | Transaction timestamp                 |
| `block_number`             | `BIGINT`    | Block number                          |
| `tx_hash`                  | `VARBINARY` | Transaction hash (0x)                 |
| `evt_index`                | `BIGINT`    | Event index                           |
| `trace_address`            | `VARCHAR`   | Trace address (nullable)              |
| `token_standard`           | `VARCHAR`   | Token standard (`trc20`)              |
| `token_address`            | `VARCHAR`   | Token contract address (base58)       |
| `token_symbol`             | `VARCHAR`   | Token symbol                          |
| `currency`                 | `VARCHAR`   | ISO 4217 currency code                |
| `amount_raw`               | `UINT256`   | Raw transfer amount                   |
| `amount`                   | `DOUBLE`    | Decimals-adjusted amount              |
| `price_usd`                | `DOUBLE`    | USD price used for valuation          |
| `amount_usd`               | `DOUBLE`    | USD amount                            |
| `from`                     | `VARBINARY` | Sender address (0x)                   |
| `to`                       | `VARBINARY` | Recipient address (0x)                |
| `unique_key`               | `VARCHAR`   | Unique transfer identifier            |
| `tx_from`                  | `VARBINARY` | Transaction sender (0x)               |
| `tx_to`                    | `VARBINARY` | Transaction receiver (0x)             |
| `tx_index`                 | `BIGINT`    | Transaction index                     |
| `contract_address`         | `VARBINARY` | Token contract (0x)                   |
| `tx_hash_varchar`          | `VARCHAR`   | Transaction hash (base58)             |
| `contract_address_varchar` | `VARCHAR`   | Token contract (base58)               |
| `from_varchar`             | `VARCHAR`   | Sender address (base58)               |
| `to_varchar`               | `VARCHAR`   | Recipient address (base58)            |
| `tx_from_varchar`          | `VARCHAR`   | Transaction sender (base58)           |
| `tx_to_varchar`            | `VARCHAR`   | Transaction receiver (base58)         |

<TableSample />

## Sample Queries

```sql theme={null}
SELECT
    t.block_date
    , SUM(t.amount_usd) AS volume_usd
    , COUNT(*) AS transfers
FROM stablecoins_tron.transfers AS t
WHERE t.token_symbol = 'USDT'
    AND t.block_date >= CURRENT_DATE - INTERVAL '30' DAY
GROUP BY t.block_date
ORDER BY t.block_date DESC
```

## Notes

* For partition pruning, filter by `block_month`.


# staking_ethereum.deposits
Source: https://docs.dune.com/data-catalog/curated/staking/deposits

Ethereum beacon chain deposit events — validator activations with amounts, withdrawal credentials, and entity attribution.

The `staking_ethereum.deposits` table contains all ETH staking deposits to the beacon chain with entity attribution.

## Table Schema

| Column                        | Type        | Description                            |
| ----------------------------- | ----------- | -------------------------------------- |
| `block_time`                  | `TIMESTAMP` | Block time of deposit transaction      |
| `block_number`                | `BIGINT`    | Block number                           |
| `amount_staked`               | `DOUBLE`    | Amount of ETH staked                   |
| `depositor_address`           | `VARBINARY` | Address of the depositor               |
| `entity`                      | `VARCHAR`   | Name of depositor entity if identified |
| `entity_unique_name`          | `VARCHAR`   | Unique name of identified entity       |
| `entity_category`             | `VARCHAR`   | Category of identified entity          |
| `sub_entity`                  | `VARCHAR`   | Sub-entity name if identified          |
| `sub_entity_unique_name`      | `VARCHAR`   | Unique name of sub-entity              |
| `sub_entity_category`         | `VARCHAR`   | Category of sub-entity                 |
| `tx_hash`                     | `VARBINARY` | Transaction hash                       |
| `tx_from`                     | `VARBINARY` | Address that executed the transaction  |
| `deposit_index`               | `BIGINT`    | Deposit index                          |
| `pubkey`                      | `VARBINARY` | Validator public key                   |
| `signature`                   | `VARBINARY` | Deposit signature                      |
| `withdrawal_address`          | `VARBINARY` | Defined withdrawal address             |
| `withdrawal_credentials_type` | `VARBINARY` | Withdrawal credentials type            |
| `withdrawal_credentials`      | `VARBINARY` | Withdrawal credentials                 |
| `evt_index`                   | `INTEGER`   | Event index                            |

## Table sample

<TableSample />


# staking_ethereum.entities
Source: https://docs.dune.com/data-catalog/curated/staking/entities

Ethereum staking entities — known operators, institutional stakers, and liquid staking protocols.

The `staking_ethereum.entities` table provides entity identification mapping for staking depositor addresses — linking wallet addresses to known staking operators and protocols.

## Table Schema

| Column                   | Type        | Description                                    |
| ------------------------ | ----------- | ---------------------------------------------- |
| `depositor_address`      | `VARBINARY` | Address of identified depositor entity         |
| `tx_from`                | `VARBINARY` | Address that initiated the staking deposit     |
| `pubkey`                 | `VARBINARY` | Public key of identified validator             |
| `withdrawal_credentials` | `VARBINARY` | Withdrawal credentials of identified validator |
| `entity`                 | `VARCHAR`   | Identified entity name (e.g., Lido, Coinbase)  |
| `entity_unique_name`     | `VARCHAR`   | Unique name of identified entity               |
| `category`               | `VARCHAR`   | Category of entity (e.g., Liquid Staking, CEX) |
| `sub_entity`             | `VARCHAR`   | Sub-entity name (e.g., specific operator)      |
| `sub_entity_unique_name` | `VARCHAR`   | Unique name of sub-entity                      |
| `sub_entity_category`    | `VARCHAR`   | Category of sub-entity                         |

## Table sample

<TableSample />


# staking_ethereum.flows
Source: https://docs.dune.com/data-catalog/curated/staking/flows

Ethereum staking net flows — ETH movements in and out of the beacon chain by entity over time.

The `staking_ethereum.flows` table combines deposits and withdrawals into a unified view for analyzing net staking flows over time.

## Table Schema

| Column                        | Type        | Description                              |
| ----------------------------- | ----------- | ---------------------------------------- |
| `block_time`                  | `TIMESTAMP` | Block time                               |
| `block_number`                | `BIGINT`    | Block number                             |
| `amount_staked`               | `DOUBLE`    | Amount of ETH staked (deposits)          |
| `depositor_address`           | `VARBINARY` | Address of the depositor                 |
| `entity`                      | `VARCHAR`   | Name of entity if identified             |
| `entity_unique_name`          | `VARCHAR`   | Unique name of identified entity         |
| `entity_category`             | `VARCHAR`   | Category of entity                       |
| `sub_entity`                  | `VARCHAR`   | Sub-entity name                          |
| `sub_entity_unique_name`      | `VARCHAR`   | Unique name of sub-entity                |
| `sub_entity_category`         | `VARCHAR`   | Category of sub-entity                   |
| `tx_from`                     | `VARBINARY` | Address that executed the transaction    |
| `deposit_index`               | `BIGINT`    | Deposit index                            |
| `withdrawal_index`            | `BIGINT`    | Withdrawal index                         |
| `validator_index`             | `BIGINT`    | Validator index                          |
| `pubkey`                      | `VARBINARY` | Validator public key                     |
| `signature`                   | `VARBINARY` | Signature                                |
| `withdrawal_address`          | `VARBINARY` | Withdrawal address                       |
| `withdrawal_credentials_type` | `VARBINARY` | Withdrawal credentials type              |
| `withdrawal_credentials`      | `VARBINARY` | Withdrawal credentials                   |
| `amount_full_withdrawn`       | `DOUBLE`    | Amount from full validator withdrawal    |
| `amount_partial_withdrawn`    | `DOUBLE`    | Amount from partial (rewards) withdrawal |
| `tx_hash`                     | `VARBINARY` | Transaction hash                         |
| `evt_index`                   | `INTEGER`   | Event index                              |

## Table sample

<TableSample />


# staking_ethereum.info
Source: https://docs.dune.com/data-catalog/curated/staking/info

Ethereum validator snapshots — current status, balance, activation epoch, and entity attribution.

The `staking_ethereum.info` table provides static metadata about known staking entities.

## Table Schema

| Column       | Type      | Description                   |
| ------------ | --------- | ----------------------------- |
| `entity`     | `VARCHAR` | Staking entity name           |
| `x_username` | `VARCHAR` | Entity's X (Twitter) username |

## Table sample

<TableSample />


# Staking
Source: https://docs.dune.com/data-catalog/curated/staking/overview

Curated Ethereum staking datasets with entity identification on Dune

Dune's staking tables provide comprehensive data on Ethereum's Proof-of-Stake beacon chain — validator deposits, withdrawals, and entity identification. These tables map staking activity to known entities like Lido, Coinbase, Rocket Pool, and dozens of others.

<Info>
  **Maintained by:** Dune · **Refresh:** \~30 min · **Chain:** Ethereum only
</Info>

<Card title="Get This Data" icon="database" href="https://dune.com/enterprise?dataset=staking">
  Access staking data via API, Datashare, or the Dune App.
</Card>

## Available Tables

<CardGroup>
  <Card title="staking_ethereum.deposits" icon="database" href="/data-catalog/curated/staking/deposits">
    All ETH staking deposits with entity attribution
  </Card>

  <Card title="staking_ethereum.flows" icon="database" href="/data-catalog/curated/staking/flows">
    Combined deposits and withdrawals in a unified view
  </Card>

  <Card title="staking_ethereum.entities" icon="database" href="/data-catalog/curated/staking/entities">
    Entity identification mapping for depositor addresses
  </Card>

  <Card title="staking_ethereum.info" icon="database" href="/data-catalog/curated/staking/info">
    Static metadata about staking entities
  </Card>
</CardGroup>

## When to Use These Tables

* Track ETH staking deposits and withdrawals over time
* Analyze staking entity market share (Lido vs Coinbase vs solo stakers)
* Monitor validator activity and withdrawal patterns
* Identify which entities control staking infrastructure
* Assess staking concentration risk

## Coverage

**Chain:** Ethereum only (beacon chain staking is Ethereum-specific)

**Entity identification via:** Depositor addresses, smart contract analysis, transaction origin addresses, withdrawal credentials, batch contract patterns, and protocol-specific identification for Coinbase, Binance, Lido, Rocket Pool, and many others.

## Query Performance

`staking_ethereum.deposits` is an incremental table. Filter on `block_time` ranges for best performance.

```sql theme={null}
-- ✅ Good: time-bounded
SELECT * FROM staking_ethereum.deposits
WHERE block_time >= DATE '2025-01-01'

-- ❌ Slow: full table scan
SELECT * FROM staking_ethereum.deposits
WHERE entity = 'Lido'
```

## Methodology

Staking tables are maintained by Dune ([source code](https://github.com/duneanalytics/spellbook)). They decode events from Ethereum's beacon chain deposit contract, enrich them with entity identification from multiple sources (on-chain traces, known address mappings, withdrawal credential analysis), and join with beacon chain validator data for withdrawal tracking.

Entity identification uses a layered approach: first matching depositor addresses to known entities, then analyzing smart contract patterns and withdrawal credentials, and finally using batch deposit heuristics for staking pools.

## Example Queries

**Staking entity market share:**

```sql theme={null}
SELECT
  entity,
  entity_category,
  SUM(amount_staked) AS total_eth_staked,
  COUNT(*) AS num_deposits
FROM staking_ethereum.deposits
GROUP BY 1, 2
ORDER BY 3 DESC
LIMIT 20
```

**Monthly staking deposits vs withdrawals:**

```sql theme={null}
SELECT
  date_trunc('month', block_time) AS month,
  SUM(amount_staked) AS eth_deposited,
  SUM(amount_full_withdrawn) AS eth_full_withdrawn,
  SUM(amount_partial_withdrawn) AS eth_partial_withdrawn,
  SUM(amount_staked) - SUM(amount_full_withdrawn) - SUM(amount_partial_withdrawn) AS net_staking_flow
FROM staking_ethereum.flows
WHERE block_time >= DATE '2024-01-01'
GROUP BY 1
ORDER BY 1
```

## Related Tables

* `labels.addresses` — Additional address labels beyond staking entities
* `cex.addresses` — Identifies CEX-controlled addresses, useful for understanding CEX staking

<CardGroup>
  <Card title="Enterprise Data Solutions" icon="building" href="https://dune.com/enterprise">
    Need custom staking analytics or dedicated support? Talk to our enterprise team.
  </Card>

  <Card title="Build Custom Models" icon="code" href="/api-reference/connectors/overview">
    Build private staking analytics pipelines with the dbt Connector.
  </Card>
</CardGroup>


# ERC20 Token Metadata
Source: https://docs.dune.com/data-catalog/curated/token-metadata/evm/erc20-metadata

Metadata like symbol, name, decimals, and contract address for ERC20 tokens across EVM networks.

The `tokens.erc20` table contains metadata for ERC20 tokens across all EVM-compatible networks indexed on Dune. This dataset provides essential information about ERC20 tokens, including:

* The blockchain on which the token exists
* The contract address of the token
* The token symbol
* The token name
* The number of decimals used by the token

### Coverage

This table covers tokens across all EVM chains on Dune. Tokens are automatically detected and included when they meet the following criteria:

* Have emitted ERC20 Transfer events
* Have at least 1 transfer recorded on-chain

New tokens meeting these criteria are added to the table within approximately 1 hour of detection.

### Data Sources

We use [Sim API](https://docs.sim.dune.com/evm/token-info) to retrieve token metadata for all qualifying contracts. For chains not supported on Sim API, we fall back to [DefinedFi](https://docs.defined.fi/reference/token) as our metadata provider.

Native tokens are also included in this dataset, using metadata information from `dune.blockchains`.

### Utility

The ERC20 metadata table offers valuable information for token analysis and integration, allowing you to:

* Identify tokens across different blockchains
* Retrieve essential token information for calculations and display

## Table Schema

| Column             | Type        | Description                                |
| ------------------ | ----------- | ------------------------------------------ |
| `blockchain`       | `VARCHAR`   | Blockchain on which the token exists       |
| `contract_address` | `VARBINARY` | Token contract address                     |
| `symbol`           | `VARCHAR`   | Token ticker symbol                        |
| `name`             | `VARCHAR`   | Full token name                            |
| `decimals`         | `INTEGER`   | Number of decimal places used by the token |
| `_updated_at`      | `TIMESTAMP` | When this record was last updated          |

<TableSample />

## Sample Queries

**Query ERC20 tokens on a specific blockchain**

This query returns ERC20 tokens on the Ethereum blockchain:

```sql theme={null}
SELECT
    contract_address,
    symbol,
    decimals
FROM tokens.erc20
WHERE blockchain = 'ethereum'
LIMIT 100
```

**Find tokens with a specific symbol across blockchains**

This query finds all tokens with the symbol "USDC" across different blockchains:

```sql theme={null}
SELECT
    blockchain,
    contract_address,
    symbol,
    decimals
FROM tokens.erc20
WHERE symbol = 'USDC'
```

**List tokens with non-standard decimal places**

This query lists tokens that don't use the standard 18 decimal places:

```sql theme={null}
SELECT
    blockchain,
    contract_address,
    symbol,
    decimals
FROM tokens.erc20
WHERE decimals != 18
ORDER BY decimals DESC
LIMIT 50
```

**Count tokens by blockchain**

This query shows the distribution of tokens across different blockchains:

```sql theme={null}
SELECT
    blockchain,
    COUNT(*) as token_count
FROM tokens.erc20
GROUP BY blockchain
ORDER BY token_count DESC
```


# Token Metadata
Source: https://docs.dune.com/data-catalog/curated/token-metadata/overview

Comprehensive token metadata across blockchain networks

Dune provides comprehensive token metadata that enables identification and analysis of digital assets across blockchain networks. Token metadata includes essential information such as token names, symbols, decimals, and contract addresses, which are fundamental for any token-related analysis.

<Info>
  **Maintained by:** Dune · **Refresh:** N/A · **Chains:** All EVM chains, Solana
</Info>

<Card title="Get This Data" icon="database" href="https://dune.com/enterprise?dataset=token-metadata">
  Access token metadata via API, Datashare, or the Dune App.
</Card>

## Available Datasets

### EVM Token Metadata

<CardGroup>
  <Card title="ERC20 Token Metadata" icon="info" href="/data-catalog/curated/token-metadata/evm/erc20-metadata">
    Metadata for ERC20 tokens across EVM networks including name, symbol, decimals, and contract address
  </Card>
</CardGroup>

### Solana Token Metadata

<CardGroup>
  <Card title="Token Metadata" icon="info" href="/data-catalog/curated/token-metadata/solana/token-metadata">
    Metadata for fungible tokens on the Solana blockchain
  </Card>

  <Card title="Token Accounts" icon="piggy-bank" href="/data-catalog/curated/token-metadata/solana/token-accounts">
    Information about token accounts on the Solana blockchain including account addresses, owners, and mint relationships
  </Card>
</CardGroup>

## Key Features

* **Multi-Chain Coverage**: Token metadata across EVM and Solana ecosystems
* **Automatic Detection**: New tokens are automatically added when detected on-chain
* **Standardized Schema**: Consistent data structure for cross-chain analysis
* **Essential Token Information**: Names, symbols, decimals, and contract addresses

## When to Use These Tables

* Resolve token contract addresses to human-readable names and symbols
* Look up decimal precision for raw amount conversions
* Enrich transfer and trading data with token metadata
* Build token registries and search interfaces
* Validate token contract addresses across chains

## Methodology

Token metadata tables are maintained by Dune ([source code](https://github.com/duneanalytics/spellbook)). EVM token metadata (`tokens.erc20`) is compiled from multiple sources: on-chain contract reads for name/symbol/decimals, community-contributed seed files, and automated detection from token transfer events. Solana token metadata (`tokens_solana.fungible`) uses on-chain Metaplex metadata and SPL token registry data.

## Example Queries

**Look up token metadata by contract address:**

```sql theme={null}
SELECT
  contract_address,
  symbol,
  decimals,
  name
FROM tokens.erc20
WHERE blockchain = 'ethereum'
  AND contract_address = 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48
```

**Find all tokens with a specific symbol:**

```sql theme={null}
SELECT
  blockchain,
  contract_address,
  symbol,
  decimals
FROM tokens.erc20
WHERE symbol = 'USDC'
ORDER BY blockchain
```

## Related Tables

* `prices.day` / `prices.hour` — Token pricing (joins on blockchain + contract\_address)
* `tokens.transfers` — Token transfer events (uses same contract addresses)
* `dex.trades` — DEX trading data with token references

<CardGroup>
  <Card title="Enterprise Data Solutions" icon="building" href="https://dune.com/enterprise">
    Need custom token data or dedicated support? Talk to our enterprise team.
  </Card>

  <Card title="Build Custom Models" icon="code" href="/api-reference/connectors/overview">
    Build private token registries with the dbt Connector.
  </Card>
</CardGroup>


# Token Accounts
Source: https://docs.dune.com/data-catalog/curated/token-metadata/solana/token-accounts

Information about token accounts on the Solana blockchain.

The `solana_utils.token_accounts` table contains information about token accounts on the Solana blockchain. Token accounts are used to hold balances of specific tokens for Solana wallets.

This table provides essential data about token accounts, including:

* The token account address
* The owner of the token balance
* The mint address of the token
* The type of account (e.g., associated token account or regular token account)

### Utility

The Solana token accounts table is useful for:

* Tracking token balances for specific wallets
* Analyzing the distribution of token holdings
* Identifying associated token accounts for wallets
* Understanding the relationship between token mints and token accounts

This table can be joined with other Solana tables to provide rich insights into token ownership and transfers on the Solana blockchain.

## Table Schema

| Column                | Type      | Description                                 |
| --------------------- | --------- | ------------------------------------------- |
| `address`             | `VARCHAR` | Token account address                       |
| `address_prefix`      | `VARCHAR` | Address prefix for indexing                 |
| `token_mint_address`  | `VARCHAR` | Mint address of the token held              |
| `token_balance_owner` | `VARCHAR` | Owner of the token balance (wallet address) |
| `account_type`        | `VARCHAR` | Type of token account (associated, regular) |

<TableSample />

## Sample Query

**Query token accounts for a specific wallet**

This query returns all token accounts associated with a specific wallet address:

```sql theme={null}
SELECT
    address AS token_account_address,
    token_balance_owner AS wallet_address,
    token_mint_address,
    account_type
FROM solana_utils.token_accounts
WHERE token_balance_owner = 'FG4Y3yX4AAchp1HvNZ7LfzFTewF2f6nDoMDCohTFrdpk'
LIMIT 10
```

This query will show you the token accounts owned by the specified wallet, including the specific token mint addresses and account types.


# Token Metadata
Source: https://docs.dune.com/data-catalog/curated/token-metadata/solana/token-metadata

Metadata for fungible tokens on the Solana blockchain.

The `tokens_solana.fungible` table contains metadata for fungible tokens on the Solana blockchain indexed on Dune. This dataset provides essential information about Solana tokens, including:

* The token mint address
* The token name and symbol
* The number of decimals used by the token
* Additional metadata such as token URI and creation details

### Utility

The Solana fungible token metadata table offers valuable information for token analysis and integration, allowing you to:

* Identify tokens on the Solana blockchain
* Retrieve essential token information for calculations and display
* Access additional metadata for more comprehensive token analysis

## Table Schema

| Column               | Type        | Description                                   |
| -------------------- | ----------- | --------------------------------------------- |
| `token_mint_address` | `VARCHAR`   | Fungible token mint address                   |
| `address_prefix`     | `VARCHAR`   | Address prefix for indexing                   |
| `decimals`           | `BIGINT`    | Number of decimal places for the token        |
| `name`               | `VARCHAR`   | Token name                                    |
| `symbol`             | `VARCHAR`   | Token symbol                                  |
| `token_uri`          | `VARCHAR`   | Token metadata URI                            |
| `metadata_program`   | `VARCHAR`   | Program used for creating token metadata      |
| `token_version`      | `VARCHAR`   | Token program version (spl\_token, token2022) |
| `init_tx`            | `VARCHAR`   | Transaction that initialized the mint         |
| `created_at`         | `TIMESTAMP` | When the token mint was created               |

<TableSample />

### Network Coverage

This table covers fungible token metadata for the Solana blockchain.

## Sample Queries

**Query Solana fungible tokens**

This query returns fungible tokens on the Solana blockchain:

```sql theme={null}
SELECT
    token_mint_address,
    symbol,
    name,
    decimals
FROM tokens_solana.fungible
LIMIT 100
```

**Find tokens with a specific symbol**

This query finds all tokens with the symbol "USDC" on Solana:

```sql theme={null}
SELECT
    token_mint_address,
    symbol,
    name,
    decimals,
    created_at
FROM tokens_solana.fungible
WHERE symbol = 'USDC'
```

**List tokens with non-standard decimal places**

This query lists tokens that don't use the standard 9 decimal places on Solana:

```sql theme={null}
SELECT
    token_mint_address,
    symbol,
    name,
    decimals
FROM tokens_solana.fungible
WHERE decimals != 9
ORDER BY decimals DESC
LIMIT 50
```


# Aptos Token Transfers
Source: https://docs.dune.com/data-catalog/curated/token-transfers/aptos/aptos-token-transfers

Curated and enriched fungible token transfer activity on the Aptos blockchain.

The `tokens_aptos.transfers` table contains curated fungible token transfer activity for Aptos assets indexed on Dune. It normalizes balance-changing activity across Aptos' legacy Coin standard and the newer Fungible Asset (FA) standard into one transfer table.

This dataset includes:

* Standard transfers reconstructed from paired debit and credit activity within the same transaction
* Residual mint and burn rows when only one side of the balance change exists
* Metadata enrichment for symbol and decimals
* USD valuation when an hourly USD price is available for the token

<Info>
  The table aims to capture standard Aptos fungible token transfers. Some non-standard token implementations or custom transfer hooks may not map cleanly into sender and receiver semantics for every transaction.
</Info>

### Utility

The Aptos transfers table provides a consistent view of fungible token movement on Aptos, enabling you to:

* Track token flows between accounts
* Analyze transfer volume by token, wallet, and day
* Separate regular transfers from mint and burn activity
* Investigate issuer, exchange, and protocol-related fund movement

### Methodology

Aptos token movement is modeled differently than EVM token transfers. According to the official Aptos docs, the legacy Coin standard emits `0x1::coin::DepositEvent` and `0x1::coin::WithdrawEvent`, while the Fungible Asset standard emits `0x1::fungible_asset::Deposit` and `0x1::fungible_asset::Withdraw` events from primary stores. Dune's Aptos transfers model aligns to that event model and reconstructs transfer rows from those balance-changing activities.

The `tokens_aptos.transfers` table is built as follows:

* It starts from Aptos fungible asset activity rows for supported Coin and FA deposit/withdraw event types.
* Debit and credit events are paired within the same transaction and `asset_type` using FIFO-style overlap logic to reconstruct transfer rows.
* Unpaired residual activity is emitted as `mint` or `burn` in `transfer_type`.
* Symbol and decimals are enriched from Aptos asset metadata, while `tx_from` is sourced from `aptos.user_transactions`.
* When multiple assets share overlapping symbols, the model keeps canonical asset types for key stablecoins to avoid duplicate symbol-level rows.
* `amount_usd` is calculated from `prices_external.hour` for Aptos when hourly pricing is available.

### Pricing Methodology

The `price_usd` and `amount_usd` columns come from Dune's external hourly price feed for Aptos tokens. If a token has a price for that hour, the transfer row gets a USD price and value. If not, both columns stay `NULL`.

This approach is meant to keep transfer valuations stable and avoid obvious outliers from thin or noisy onchain pricing. For tokens outside Dune's trusted token set, very large computed USD values are set to `NULL` instead of being shown.

For more details on Dune's pricing methodology, see the [Prices documentation](/data-catalog/curated/prices/overview).

## Table Schema

| Column                    | Type        | Description                                                                 |
| ------------------------- | ----------- | --------------------------------------------------------------------------- |
| `unique_key`              | `VARCHAR`   | Surrogate key to identify a unique transfer row                             |
| `blockchain`              | `VARCHAR`   | Blockchain identifier (`aptos`)                                             |
| `block_month`             | `DATE`      | Month bucket derived from `block_time`                                      |
| `block_date`              | `DATE`      | Block date                                                                  |
| `block_time`              | `TIMESTAMP` | Block timestamp                                                             |
| `tx_version`              | `UINT256`   | Aptos transaction version                                                   |
| `tx_hash`                 | `VARBINARY` | Transaction hash                                                            |
| `event_index`             | `INTEGER`   | Primary event index used for the transfer row                               |
| `counterpart_event_index` | `INTEGER`   | Matched opposite-side event index for paired transfers                      |
| `token_standard`          | `VARCHAR`   | Aptos token standard label used for the activity                            |
| `tx_from`                 | `VARBINARY` | Transaction sender                                                          |
| `tx_to`                   | `VARBINARY` | Transaction receiver field reserved for future enrichment; currently `NULL` |
| `from`                    | `VARBINARY` | Transfer sender owner address                                               |
| `to`                      | `VARBINARY` | Transfer receiver owner address                                             |
| `contract_address`        | `VARBINARY` | Package address parsed from `asset_type`                                    |
| `asset_type`              | `VARCHAR`   | Fully qualified Aptos asset type                                            |
| `from_storage_id`         | `VARBINARY` | Sender-side fungible store identifier                                       |
| `to_storage_id`           | `VARBINARY` | Receiver-side fungible store identifier                                     |
| `symbol`                  | `VARCHAR`   | Token symbol from Aptos asset metadata                                      |
| `decimals`                | `INTEGER`   | Display decimals from Aptos asset metadata                                  |
| `tx_index`                | `INTEGER`   | Transaction index within the block                                          |
| `amount_raw`              | `UINT256`   | Raw token amount before decimal adjustment                                  |
| `amount`                  | `DOUBLE`    | Transfer amount in display units                                            |
| `price_usd`               | `DOUBLE`    | Hourly USD price used to calculate `amount_usd`                             |
| `amount_usd`              | `DOUBLE`    | USD value of the transfer                                                   |
| `transfer_type`           | `VARCHAR`   | Transfer classification (`transfer`, `mint`, or `burn`)                     |
| `_updated_at`             | `TIMESTAMP` | Timestamp when this row was last written                                    |

<TableSample />

## Sample Queries

**Query recent token transfers for a specific Aptos address**

This query returns the most recent incoming and outgoing token transfers for a wallet:

```sql theme={null}
SELECT
    block_time,
    tx_version,
    symbol,
    transfer_type,
    CASE
        WHEN "from" = 0x8fc24635538e870786e8444e89ed1458449a1f0788ad21f27c4f8188333138f9 THEN 'Outgoing'
        WHEN "to" = 0x8fc24635538e870786e8444e89ed1458449a1f0788ad21f27c4f8188333138f9 THEN 'Incoming'
    END AS direction,
    amount,
    amount_usd
FROM tokens_aptos.transfers
WHERE (
        "from" = 0x8fc24635538e870786e8444e89ed1458449a1f0788ad21f27c4f8188333138f9
        OR "to" = 0x8fc24635538e870786e8444e89ed1458449a1f0788ad21f27c4f8188333138f9
    )
    AND block_time > now() - interval '30' day
ORDER BY block_time DESC
LIMIT 100
```

**Calculate daily transfer volume for a specific Aptos asset**

This query aggregates daily transfer activity for a single Aptos asset:

```sql theme={null}
SELECT
    block_date,
    symbol,
    COUNT(*) AS num_rows,
    SUM(amount) AS total_amount,
    SUM(amount_usd) AS total_amount_usd
FROM tokens_aptos.transfers
WHERE contract_address = 0xbae207659db88bea0cbead6da0ed00aac12edcdda169e591cd41c94180b46f3b
    AND transfer_type = 'transfer'
    AND block_date >= current_date - interval '30' day
GROUP BY 1, 2
ORDER BY 1 DESC
```

**Split transfer activity into transfers, mints, and burns**

This query helps distinguish normal transfers from supply-changing events:

```sql theme={null}
SELECT
    block_date,
    transfer_type,
    COUNT(*) AS num_rows,
    SUM(amount) AS total_amount,
    SUM(amount_usd) AS total_amount_usd
FROM tokens_aptos.transfers
WHERE block_date >= current_date - interval '30' day
    AND symbol = 'APT'
GROUP BY 1, 2
ORDER BY 1 DESC, 2
```


# Token Transfers
Source: https://docs.dune.com/data-catalog/curated/token-transfers/evm/token-transfers

Curated and enriched token transfer events across all EVM networks for fungible tokens.

The `tokens.transfers` table contains token transfer events across ERC20 tokens and native tokens for all EVM-compatible networks indexed on Dune. This dataset encompasses:

* Transfer events for ERC20 tokens
* ERC4626 fallback mint and burn transfers for supported vaults
* WETH deposits and withdrawals
* Native currency transfers
  * Transaction value transfers
  * Trace value transfers
  * Gas used transfers

<Info>
  Some ERC20 tokens and native currencies have non-standard ways of being transferred and might not be included in the transfers table.
  You can check the logic for the transfers table [here](https://github.com/duneanalytics/spellbook/tree/main/dbt_subprojects/tokens/models/transfers_and_balances). The level of detail of the transfers table will vary by chain.
</Info>

### Utility

The transfers table provides a comprehensive view of token movement across networks, enabling you to:

* Track token flows between addresses
* Analyze transaction volumes and patterns
* Identify significant token movements
* Monitor exchange and DeFi protocol activity

### Pricing Methodology

<Warning>
  **Important**: The USD values in `tokens.transfers` are calculated using `prices_external.hour`, **not** the hybrid `prices.hour` table.
</Warning>

The `amount_usd` column in the transfers table uses Coinpaprika-sourced pricing data exclusively, which provides:

* **Stable, externally-validated pricing** from centralized exchange aggregation
* **Protection against outliers** that can occur in DEX-derived pricing algorithms
* **Consistent valuation** across major tokens (\~2,000 tokens with Coinpaprika coverage)

This approach prevents pricing anomalies from DEX trading activity that could negatively impact aggregations and analysis on the transfers table. Tokens without Coinpaprika coverage will not have USD values populated.

For more details on Dune's pricing methodology and the differences between pricing sources, see the [Prices documentation](/data-catalog/curated/prices/overview).

## Table Schema

| Column             | Type            | Description                                                |
| ------------------ | --------------- | ---------------------------------------------------------- |
| `unique_key`       | `VARCHAR`       | Surrogate key to identify unique row                       |
| `blockchain`       | `VARCHAR`       | Blockchain of the transfer                                 |
| `block_month`      | `DATE`          | Block month (partition key)                                |
| `block_date`       | `DATE`          | Block date                                                 |
| `block_time`       | `TIMESTAMP`     | Block timestamp                                            |
| `block_number`     | `BIGINT`        | Block number                                               |
| `tx_hash`          | `VARBINARY`     | Transaction hash                                           |
| `evt_index`        | `BIGINT`        | Log event index of the transfer                            |
| `trace_address`    | `ARRAY(BIGINT)` | Trace address of the transfer                              |
| `token_standard`   | `VARCHAR`       | Token standard (ERC20, native)                             |
| `tx_from`          | `VARBINARY`     | Transaction sender                                         |
| `tx_to`            | `VARBINARY`     | Transaction receiver                                       |
| `tx_index`         | `BIGINT`        | Transaction index within the block                         |
| `from`             | `VARBINARY`     | Sender of the transfer                                     |
| `to`               | `VARBINARY`     | Receiver of the transfer                                   |
| `contract_address` | `VARBINARY`     | Token contract address                                     |
| `symbol`           | `VARCHAR`       | Token symbol                                               |
| `amount_raw`       | `UINT256`       | Raw transfer amount before decimal adjustment              |
| `amount`           | `DOUBLE`        | Transfer amount in display units                           |
| `price_usd`        | `DOUBLE`        | USD price used to calculate amount\_usd (from Coinpaprika) |
| `amount_usd`       | `DOUBLE`        | USD value of the transfer                                  |

<TableSample />

### Network Coverage

Transfer data is available for the following EVM-compatible networks:

<div>
  <DuneEmbed />
</div>

## Sample Queries

**Query recent token transfers for a specific address**

This query returns the most recent token transfers (both incoming and outgoing) for a specified address:

```sql theme={null}
SELECT
    block_time,
    symbol,
    CASE 
        WHEN "from" = 0x5DD596C901987A2b28C38A9C1DfBf86fFFc15d77 THEN 'Outgoing'
        WHEN "to" = 0x5DD596C901987A2b28C38A9C1DfBf86fFFc15d77 THEN 'Incoming'
    END AS direction,
    amount,
    amount_usd
FROM tokens.transfers
WHERE ("from" = 0x5DD596C901987A2b28C38A9C1DfBf86fFFc15d77 OR "to" = 0x5DD596C901987A2b28C38A9C1DfBf86fFFc15d77)
    AND block_time > now() - interval '30' day
ORDER BY block_time DESC
LIMIT 100
```

<div>
  <DuneEmbed />
</div>

**Calculate daily transfer volume for a specific token**

This query calculates the daily transfer volume for a specific ERC20 token.

Please be aware that token volumes are not necessarily indicative of anything. These metrics can be misleading if the token is not well-known or if there are a lot of small transfers. Token transfers can be mints, burns, transfers, flash loans and anything in between, trying to read into the data can lead to misleading results.

Note: The `amount_usd` values are calculated using Coinpaprika pricing data (`prices_external.hour`) for stable, exchange-validated pricing.

```sql theme={null}
SELECT
    block_date,
    COUNT(*) AS num_transfers,
    SUM(amount) AS total_amount,
    SUM(amount_usd) AS total_amount_usd
FROM tokens.transfers
WHERE contract_address = 0x1f9840a85d5af5bf1d1762f925bdaddc4201f984
    AND block_time > now() - interval '30' day
    and blockchain = 'ethereum'
GROUP BY 1
ORDER BY 1 DESC
```

<div>
  <DuneEmbed />
</div>

**Identify largest transfers in the last 24 hours**

This query finds the largest token transfers by USD value in the last 24 hours:

Note: USD values are sourced from Coinpaprika pricing data for reliable valuation.

```sql theme={null}
SELECT
    block_time,
    token_symbol,
    "from",
    "to",
    amount,
    amount_usd
FROM tokens.transfers
WHERE block_time > now() - interval '1' day
    AND amount_usd IS NOT NULL
ORDER BY amount_usd DESC
LIMIT 50
```

**Find the circulating supply of a token over time**

This query calculates the circulating supply of a token over time by summing the amount of tokens in circulation at each time interval.
Please be aware that this won't work for all tokens with non-standard transfer or minting/burning mechanisms. `tokens.transfers` includes fallback ERC4626 share mint and burn rows for supported vaults, but other custom token mechanics may still require token-specific logic.

```sql theme={null}
WITH tx AS (
    SELECT
        DATE_TRUNC('hour', evt_block_time) AS event_hour,
        value / 1e18 AS tokens_delta
    FROM erc20_ethereum.evt_transfer
    WHERE contract_address = 0x5bae9a5d67d1ca5b09b14c91935f635cfbf3b685
      AND "from" = 0x0000000000000000000000000000000000000000

    UNION ALL

    SELECT
        DATE_TRUNC('hour', evt_block_time) AS event_hour,
        -value / 1e18 AS tokens_delta
    FROM erc20_ethereum.evt_transfer
    WHERE contract_address = 0x5bae9a5d67d1ca5b09b14c91935f635cfbf3b685
      AND "to" = 0x0000000000000000000000000000000000000000
),
tx_hourly AS (
    SELECT
        event_hour,
        SUM(tokens_delta) AS net_tokens
    FROM tx
    GROUP BY event_hour
    ORDER BY event_hour DESC
)
SELECT
    event_hour,
    SUM(net_tokens) OVER (ORDER BY event_hour) AS circulating_supply
FROM tx_hourly
ORDER BY event_hour DESC;
```


# Multichain Token Transfers
Source: https://docs.dune.com/data-catalog/curated/token-transfers/multichain/multichain-token-transfers

Unified fungible token transfer activity across EVM, Solana, Aptos, Sui, Stellar, and XRPL.

The `tokens_multichain.transfers` table provides a chain-agnostic view of fungible token transfer activity across EVM-compatible chains, Solana, Aptos, Sui, Stellar, and XRPL.

It normalizes the most commonly used transfer fields into one schema, so you can analyze token movement across ecosystems without writing your own `UNION ALL` query over chain-specific tables.

This dataset includes:

* Transfer activity from EVM, Solana, Aptos, Sui, Stellar, and XRPL source models
* String-based addresses and transaction identifiers for cross-ecosystem compatibility
* Chain-native token identifiers through `token_address` and `token_id`
* Normalized amount fields and USD values where source pricing is available

<Info>
  Use this table for broad cross-chain transfer analysis. Use the chain-specific transfer tables when you need source-specific details that are not part of the normalized multichain schema.
</Info>

### Utility

The multichain transfers table provides a consistent view of fungible token movement across ecosystems, enabling you to:

* Compare transfer volume and activity across chains
* Build cross-chain wallet activity views
* Track token movement by symbol, token identifier, or blockchain
* Analyze transfers across EVM and non-EVM ecosystems with one query

### Methodology

The `tokens_multichain.transfers` table is built as a normalized union of Dune's chain-level token transfer models:

* EVM transfers from `tokens_evm.transfers`
* Solana transfers from `tokens_solana.transfers`
* Aptos transfers from `tokens_aptos.transfers`
* Sui transfers from `tokens_sui.transfers`
* Stellar transfers from `tokens_stellar.transfers`
* XRPL transfers from `tokens_xrpl.transfers`

Each source model keeps its own chain-specific reconstruction logic. The multichain table maps those outputs into shared columns for time, transaction identity, sender, receiver, token identity, amount, pricing, and transfer classification.

Some chain-specific fields are nullable because not every ecosystem has the same concepts. For example, EVM has transaction indexes and event indexes, Solana has instruction indexes, Aptos has transaction versions, Sui has checkpoints, Stellar has ledger sequences and operation IDs, and XRPL has ledger indexes.

### Pricing Methodology

The `amount_usd` column is carried through from the chain-specific source models when pricing is available. Availability varies by ecosystem and token. If a token does not have a usable USD price at the transfer time, `amount_usd` stays `NULL`.

The `price_usd` column is also source-dependent. Some source models provide an hourly token price, while others only expose the final USD value.

For more details on Dune's pricing methodology, see the [Prices documentation](/data-catalog/curated/prices/overview).

## Table Schema

| Column            | Type                       | Description                                                                                                                                          |
| ----------------- | -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
| `unique_key`      | `VARCHAR`                  | Surrogate key to identify a unique transfer row                                                                                                      |
| `blockchain`      | `VARCHAR`                  | Blockchain identifier for the transfer                                                                                                               |
| `block_time`      | `TIMESTAMP WITH TIME ZONE` | Block, slot, checkpoint, ledger, or transaction timestamp                                                                                            |
| `block_date`      | `DATE`                     | Date derived from `block_time`                                                                                                                       |
| `block_month`     | `DATE`                     | Month bucket derived from `block_time`                                                                                                               |
| `block_number`    | `BIGINT`                   | Chain-native block or ledger number, such as EVM block number, Solana slot, Sui checkpoint, Stellar ledger sequence, or XRPL ledger index            |
| `tx_id`           | `VARCHAR`                  | Chain-native transaction identifier                                                                                                                  |
| `tx_sequence`     | `BIGINT`                   | Nullable chain-native transaction sequence, such as Aptos transaction version or Stellar transaction ID                                              |
| `tx_index`        | `BIGINT`                   | Nullable transaction index within the block or ledger unit                                                                                           |
| `event_index`     | `BIGINT`                   | Nullable primary event, instruction, or operation index                                                                                              |
| `sub_event_index` | `BIGINT`                   | Nullable secondary event, instruction, or matched-counterpart index                                                                                  |
| `from_address`    | `VARCHAR`                  | Sender owner or account address                                                                                                                      |
| `to_address`      | `VARCHAR`                  | Receiver owner or account address                                                                                                                    |
| `tx_signer`       | `VARCHAR`                  | Transaction signer or sender when available                                                                                                          |
| `token_address`   | `VARCHAR`                  | Address-like token identifier, such as an EVM contract, Solana mint, Aptos package address, Sui package address, Stellar contract ID, or XRPL issuer |
| `token_id`        | `VARCHAR`                  | Full chain-native token identifier when richer than `token_address`, such as Aptos asset type, Sui coin type, Stellar asset ID, or XRPL asset ID     |
| `token_symbol`    | `VARCHAR`                  | Token symbol                                                                                                                                         |
| `token_standard`  | `VARCHAR`                  | Source token standard or program label                                                                                                               |
| `amount_raw`      | `UINT256`                  | Raw token amount before decimal adjustment                                                                                                           |
| `amount`          | `DOUBLE`                   | Transfer amount in display units                                                                                                                     |
| `price_usd`       | `DOUBLE`                   | USD price used to calculate `amount_usd`, when provided by the source model                                                                          |
| `amount_usd`      | `DOUBLE`                   | USD value of the transfer when pricing is available                                                                                                  |
| `transfer_type`   | `VARCHAR`                  | Nullable chain-native transfer classification or action                                                                                              |
| `_updated_at`     | `TIMESTAMP`                | Timestamp when this row was last written, when provided by the source model                                                                          |

<TableSample />

## Sample Queries

**Compare transfer activity across ecosystems**

This query aggregates recent priced transfer volume by blockchain and token symbol:

```sql theme={null}
SELECT
    block_date,
    blockchain,
    token_symbol,
    COUNT(*) AS num_transfers,
    SUM(amount_usd) AS transfer_volume_usd
FROM tokens_multichain.transfers
WHERE block_date >= current_date - interval '30' day
    AND amount_usd IS NOT NULL
GROUP BY 1, 2, 3
ORDER BY block_date DESC, transfer_volume_usd DESC
LIMIT 100
```

**Query recent transfers for one address on one chain**

Because addresses are stored as strings, include `blockchain` when querying a specific address so the value is interpreted in the right ecosystem:

```sql theme={null}
SELECT
    block_time,
    blockchain,
    tx_id,
    token_symbol,
    token_id,
    CASE
        WHEN from_address = '9SUrE3EPBoXVjNywEDHSJKJdxebs8H8sLgEWdueEvnKX' THEN 'Outgoing'
        WHEN to_address = '9SUrE3EPBoXVjNywEDHSJKJdxebs8H8sLgEWdueEvnKX' THEN 'Incoming'
    END AS direction,
    amount,
    amount_usd
FROM tokens_multichain.transfers
WHERE blockchain = 'solana'
    AND (
        from_address = '9SUrE3EPBoXVjNywEDHSJKJdxebs8H8sLgEWdueEvnKX'
        OR to_address = '9SUrE3EPBoXVjNywEDHSJKJdxebs8H8sLgEWdueEvnKX'
    )
    AND block_date >= current_date - interval '30' day
ORDER BY block_time DESC
LIMIT 100
```

**Analyze transfer categories by chain**

This query compares source transfer classifications where they are available:

```sql theme={null}
SELECT
    blockchain,
    COALESCE(transfer_type, 'not_applicable') AS transfer_type,
    COUNT(*) AS num_rows,
    SUM(amount_usd) AS total_amount_usd
FROM tokens_multichain.transfers
WHERE block_date >= current_date - interval '30' day
GROUP BY 1, 2
ORDER BY num_rows DESC
LIMIT 100
```


# Token Transfers
Source: https://docs.dune.com/data-catalog/curated/token-transfers/overview

Comprehensive token and asset tracking across multiple blockchain networks

Blockchain networks have become popular platforms for creating, managing, and trading digital assets. These assets are often represented as tokens, which can be transferred between addresses and owned by users. Dune provides comprehensive token transfer tracking capabilities across multiple blockchain networks through curated tables that simplify the process of monitoring and analyzing token transfers across EVM, Solana, Aptos, Stellar, Sui, and XRPL ecosystems.

<Info>
  **Maintained by:** Dune · **Refresh:** \~1 hour · **Chains:** All EVM chains, Solana, Aptos, Stellar, Sui, XRPL
</Info>

<Card title="Get This Data" icon="database" href="https://dune.com/enterprise?dataset=tokens.transfers">
  Access token transfer data via API, Datashare, or the Dune App.
</Card>

## Cross-Chain Token Transfer Coverage

Our token transfer data covers multiple blockchain ecosystems:

* **EVM Networks**: Ethereum, Arbitrum, Polygon, Base, Optimism, and 40+ other EVM chains
* **Solana**: Comprehensive coverage of SPL tokens and native SOL transfers
* **Aptos**: Curated fungible asset transfers across Coin and Fungible Asset standards
* **Stellar**: Unified token movement across classic Stellar operations and contract token events
* **Sui**: Curated fungible token transfers reconstructed from Coin object activity and supply events
* **XRPL**: Unified token movement for native XRP, issued currencies, and AMM-related activity

## Available Datasets

Use the chain-specific tables when you need source-level details, or the multichain view when you want one normalized schema across ecosystems.

<CardGroup>
  <Card title="EVM Token Transfers" icon="arrow-right" href="/data-catalog/curated/token-transfers/evm/token-transfers">
    Transfer events for ERC20 tokens and native currencies on EVM networks
  </Card>

  <Card title="Solana Token Transfers" icon="arrow-right" href="/data-catalog/curated/token-transfers/solana/solana-token-transfers">
    Transfer events for SPL tokens and native SOL on Solana
  </Card>

  <Card title="Aptos Token Transfers" icon="arrow-right" href="/data-catalog/curated/token-transfers/aptos/aptos-token-transfers">
    Curated fungible token transfers across Aptos Coin and Fungible Asset standards
  </Card>

  <Card title="Stellar Token Transfers" icon="arrow-right" href="/data-catalog/curated/token-transfers/stellar/stellar-token-transfers">
    Unified token movement across Stellar payments, issued assets, and contract token events
  </Card>

  <Card title="Sui Token Transfers" icon="arrow-right" href="/data-catalog/curated/token-transfers/sui/sui-token-transfers">
    Curated fungible token transfers across Sui Coin object activity and supply events
  </Card>

  <Card title="XRPL Token Transfers" icon="arrow-right" href="/data-catalog/curated/token-transfers/xrpl/xrpl-token-transfers">
    Unified token movement for native XRP, issued currencies, checks, escrows, payment channels, and AMM activity
  </Card>
</CardGroup>

### Unified View

<CardGroup>
  <Card title="Multichain Transfers" icon="arrow-right-arrow-left" href="/data-catalog/curated/token-transfers/multichain/multichain-token-transfers">
    Unified fungible token transfers across EVM, Solana, Aptos, Sui, Stellar, and XRPL
  </Card>
</CardGroup>

<Note>
  Looking for token balances or metadata? See the [Balances](/data-catalog/curated/balances/overview) and [Token Metadata](/data-catalog/curated/token-metadata/overview) sections.
</Note>

## Key Features

* **Multi-Chain Coverage**: Track token transfers across EVM, Solana, Aptos, Stellar, Sui, and XRPL ecosystems
* **Standardized Schema**: Consistent data structure for cross-chain analysis
* **Transfer Analytics**: Detailed transfer events with sender, receiver, and amounts
* **Real-time Updates**: Data is updated continuously as new blocks are processed

## Sample Cross-Chain Analysis

Compare token transfer activity across different blockchain networks:

```sql theme={null}
SELECT
    blockchain,
    DATE_TRUNC('day', block_time) AS date,
    COUNT(*) AS num_transfers,
    COUNT(DISTINCT from_address) AS unique_senders,
    SUM(amount_usd) AS transfer_volume_usd
FROM tokens_multichain.transfers
WHERE block_date >= CURRENT_DATE - INTERVAL '30' day
GROUP BY 1, 2
ORDER BY date DESC, num_transfers DESC
```

These datasets enable users to perform a wide range of analyses across multiple blockchain networks, providing valuable insights into the dynamics of digital assets across various blockchain ecosystems.

## When to Use These Tables

* Track token flows between wallets, contracts, and exchanges
* Build wallet activity feeds and transaction history views
* Monitor large transfers ("whale alerts") for market intelligence
* Analyze token distribution and holder concentration over time
* Power compliance workflows — identify counterparties and trace fund flows

## Query Performance

**Partition keys for `tokens.transfers`:** `blockchain`, `block_date`

Always include `blockchain` and `block_date` (or a `block_time` range) in your WHERE clause.

For cross-ecosystem queries against `tokens_multichain.transfers`, include `blockchain` and a date filter whenever possible so filters can be pushed down to the source models.

```sql theme={null}
-- ✅ Good: chain + date filter
SELECT * FROM tokens.transfers
WHERE blockchain = 'ethereum'
  AND block_date = CURRENT_DATE
  AND contract_address = 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 -- USDC

-- ❌ Slow: no partition filters
SELECT * FROM tokens.transfers
WHERE "from" = 0x...
```

## Methodology

Token transfer tables are maintained by Dune. Each ecosystem has its own source table and normalization logic:

* **EVM**: Decodes ERC-20 `Transfer` events and native token transfers into `tokens.transfers`.
* **Solana**: Handles SPL token and native SOL transfers in `tokens_solana.transfers`.
* **Aptos**: Reconstructs transfers from Coin and Fungible Asset deposit/withdraw activity in `tokens_aptos.transfers`.
* **Stellar**: Exposes a unified event stream for transfers, mints, burns, clawbacks, and fees across classic and contract-based activity in `tokens_stellar.transfers`.
* **Sui**: Reconstructs fungible token movement from Coin object activity and treasury supply events in `tokens_sui.transfers`.
* **XRPL**: Normalizes native XRP, issued currency, and AMM-related token movement in `tokens_xrpl.transfers`.

The `tokens_multichain.transfers` view combines EVM, Solana, Aptos, Sui, Stellar, and XRPL transfers into one cross-ecosystem schema for broad analysis.

## Example Queries

**Top tokens by transfer volume on Ethereum (today):**

```sql theme={null}
SELECT
  contract_address,
  symbol,
  SUM(amount_usd) AS total_volume_usd,
  COUNT(*) AS num_transfers
FROM tokens.transfers
WHERE blockchain = 'ethereum'
  AND block_date = CURRENT_DATE
GROUP BY 1, 2
ORDER BY 3 DESC
LIMIT 20
```

**Large USDC transfers (>\$1M) in the last 24 hours:**

```sql theme={null}
SELECT
  block_time,
  "from",
  "to",
  amount,
  amount_usd
FROM tokens.transfers
WHERE blockchain = 'ethereum'
  AND block_date >= CURRENT_DATE - INTERVAL '1' DAY
  AND contract_address = 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48
  AND amount_usd > 1000000
ORDER BY amount_usd DESC
```

<CardGroup>
  <Card title="Enterprise Data Solutions" icon="building" href="https://dune.com/enterprise">
    Need custom transfer datasets or dedicated support? Talk to our enterprise team.
  </Card>

  <Card title="Build Custom Models" icon="code" href="/api-reference/connectors/overview">
    Build private token flow analytics with the dbt Connector.
  </Card>
</CardGroup>


# Solana Token Transfers
Source: https://docs.dune.com/data-catalog/curated/token-transfers/solana/solana-token-transfers

Token transfer events on the Solana blockchain.

The `tokens_solana.transfers` table contains token transfer events for tokens on the Solana blockchain indexed by Dune. This dataset encompasses:

* SPL token transfers
* token2022 token transfers
* native SOL transfers (excluding staking-related transfers)

<Info>
  The transfers table aims to capture standard Solana token transfers. Some tokens may use non-standard transfer methods that might not be included.
</Info>

### Utility

The Solana transfers table provides a comprehensive view of token movement on Solana, enabling you to:

* Track token flows between addresses
* Analyze transaction volumes and patterns
* Identify significant token movements
* Monitor exchange and DeFi protocol activity on Solana

The table contains columns for block information, transfer details, token addresses, account addresses, and transaction metadata.

## Table Schema

| Column                    | Type        | Description                                         |
| ------------------------- | ----------- | --------------------------------------------------- |
| `block_time`              | `TIMESTAMP` | Block timestamp                                     |
| `action`                  | `VARCHAR`   | Transfer action type (transfer, mintTo, burn, etc.) |
| `amount`                  | `UINT256`   | Raw transfer amount                                 |
| `from_token_account`      | `VARCHAR`   | Source token account address                        |
| `to_token_account`        | `VARCHAR`   | Destination token account address                   |
| `token_mint_address`      | `VARCHAR`   | Token mint address                                  |
| `symbol`                  | `VARCHAR`   | Token symbol                                        |
| `amount_display`          | `DOUBLE`    | Transfer amount in display units                    |
| `amount_usd`              | `DOUBLE`    | USD value of the transfer                           |
| `from_owner`              | `VARCHAR`   | Owner of the source token account                   |
| `to_owner`                | `VARCHAR`   | Owner of the destination token account              |
| `token_version`           | `VARCHAR`   | Token program version (spl\_token, token2022)       |
| `tx_id`                   | `VARCHAR`   | Transaction ID                                      |
| `tx_signer`               | `VARCHAR`   | Transaction signer                                  |
| `outer_executing_account` | `VARCHAR`   | Outer executing program account                     |
| `block_date`              | `DATE`      | Block date                                          |
| `block_slot`              | `BIGINT`    | Block slot number                                   |
| `tx_index`                | `INTEGER`   | Transaction index within the block                  |
| `outer_instruction_index` | `INTEGER`   | Outer instruction index                             |
| `inner_instruction_index` | `INTEGER`   | Inner instruction index                             |
| `unique_instruction_key`  | `DECIMAL`   | Unique instruction identifier                       |

<TableSample />

## Sample Queries

**Query recent token transfers for a specific address**

This query returns the most recent token transfers (both incoming and outgoing) for a specified address:

```sql theme={null}
SELECT
    block_time,
    action,
    CASE 
        WHEN from_owner = '7F9KJm6rcW2PAgUkRmqXhzMmUpxWcQcLFjarE4bwniqZ' THEN 'Outgoing'
        WHEN to_owner = '7F9KJm6rcW2PAgUkRmqXhzMmUpxWcQcLFjarE4bwniqZ' THEN 'Incoming'
    END AS direction,
    amount,
    amount_usd,
    token_mint_address,
    token_version
FROM tokens_solana.transfers
WHERE (from_owner = '7F9KJm6rcW2PAgUkRmqXhzMmUpxWcQcLFjarE4bwniqZ' OR to_owner = '7F9KJm6rcW2PAgUkRmqXhzMmUpxWcQcLFjarE4bwniqZ')
    AND block_time > now() - interval '30' day
ORDER BY block_time DESC
LIMIT 100
```

<QueryContainer />


# Stellar Token Transfers
Source: https://docs.dune.com/data-catalog/curated/token-transfers/stellar/stellar-token-transfers

Unified token transfer activity for native, issued, and contract-based assets on Stellar.

The `tokens_stellar.transfers` table contains token movement data for Stellar assets indexed on Dune. It brings native XLM, issued assets, and contract token activity into one table using a unified event model.

This dataset includes:

* Standard transfers between accounts, contracts, and other Stellar entities
* Mint, burn, clawback, and fee events in the same token-movement stream
* Coverage across classic Stellar operations and contract token activity
* Asset identifiers for native, issued, and contract-linked assets

<Info>
  This table represents unified token movement on Stellar, not just payment operations. It also includes system-level activity such as fees, mints, burns, and clawbacks, so exclude those if you want to focus only on regular user-to-user transfers.
</Info>

### Utility

The Stellar transfers table provides a consistent view of token movement on Stellar, enabling you to:

* Track token flows between wallets, issuers, and contracts
* Analyze transfer activity by asset, operation type, and day
* Separate regular transfers from mint, burn, clawback, and fee activity
* Compare classic Stellar operations with contract token events

### Methodology

According to the official Stellar docs, token transfers are standardized through [CAP-67](https://stellar.org/protocol/cap-67) unified events and the [Token Transfer Processor (TTP)](https://developers.stellar.org/docs/data/indexers/build-your-own/processors/token-transfer-processor), which derives token movement from ledger data across both classic operations and contract-based activity.

The `tokens_stellar.transfers` table is built around that event model:

* It standardizes token movement into a shared set of event topics: `transfer`, `mint`, `burn`, `clawback`, and `fee`.
* It captures activity from classic Stellar operations such as payments, path payments, DEX offer execution, claimable balances, liquidity pool actions, account merges, and clawbacks.
* It also includes contract token events, where `is_soroban = true` and `event_type` is commonly `invoke_host_function`.
* `event_type` shows the originating operation or execution path, while `event_topic` shows the normalized token-movement category.
* `contract_id` is populated on every event as the standardized asset identifier used across native, issued, and contract tokens.

Because fee events are part of the same stream, not every row has both a sender and receiver. For example, fee rows usually have a `from` account but no `to` account.

The `from` and `to` columns can contain multiple Stellar address types. The prefix identifies the entity type, so you may see `G...` accounts, `C...` contracts, `B...` claimable balances, and `L...` liquidity pools.

## Table Schema

| Column             | Type                       | Description                                                                                                   |
| ------------------ | -------------------------- | ------------------------------------------------------------------------------------------------------------- |
| `unique_key`       | `VARCHAR`                  | Surrogate key to identify a unique transfer row                                                               |
| `blockchain`       | `VARCHAR`                  | Blockchain name; always `stellar`                                                                             |
| `block_month`      | `DATE`                     | Month of the ledger close time                                                                                |
| `block_date`       | `DATE`                     | Date of the ledger close time                                                                                 |
| `block_time`       | `TIMESTAMP`                | Ledger close timestamp                                                                                        |
| `ledger_sequence`  | `BIGINT`                   | Ledger sequence number                                                                                        |
| `transaction_hash` | `VARBINARY`                | Hex-encoded transaction hash                                                                                  |
| `transaction_id`   | `BIGINT`                   | Unique transaction identifier                                                                                 |
| `operation_id`     | `BIGINT`                   | Operation identifier; `NULL` for Soroban events                                                               |
| `token_standard`   | `VARCHAR`                  | Token standard label: `native`, `classic`, or `soroban`                                                       |
| `from`             | `VARCHAR`                  | Source address for the token movement; may be an account, contract, claimable balance, or liquidity pool      |
| `to`               | `VARCHAR`                  | Destination address for the token movement; may be an account, contract, claimable balance, or liquidity pool |
| `to_muxed`         | `VARCHAR`                  | Multiplexed destination account when present                                                                  |
| `to_muxed_id`      | `VARCHAR`                  | Multiplexed destination account ID when present                                                               |
| `contract_id`      | `VARCHAR`                  | Standardized contract identifier for the asset on every event                                                 |
| `asset`            | `VARCHAR`                  | Asset identifier; for issued assets this is typically `asset_code:asset_issuer`                               |
| `asset_type`       | `VARCHAR`                  | Stellar asset type such as `native`, `credit_alphanum4`, `credit_alphanum12`, or `soroban`                    |
| `asset_code`       | `VARCHAR`                  | Asset code for protocol-issued, non-contract assets when applicable                                           |
| `asset_issuer`     | `VARCHAR`                  | Issuer address for protocol-issued, non-contract assets when applicable                                       |
| `symbol`           | `VARCHAR`                  | Token symbol                                                                                                  |
| `decimals`         | `INTEGER`                  | Number of decimals used to scale `amount_raw`                                                                 |
| `amount_raw`       | `DOUBLE`                   | Raw token amount in base units                                                                                |
| `amount`           | `DOUBLE`                   | Normalized token amount                                                                                       |
| `price_usd`        | `DOUBLE`                   | USD price used to calculate `amount_usd`; populated for native XLM pricing                                    |
| `amount_usd`       | `DOUBLE`                   | USD value of the transfer; populated for native XLM pricing                                                   |
| `event_topic`      | `VARCHAR`                  | Normalized token event category: `transfer`, `mint`, `burn`, `clawback`, or `fee`                             |
| `event_type`       | `VARCHAR`                  | Underlying Stellar operation or execution type that produced the event                                        |
| `is_soroban`       | `BOOLEAN`                  | Whether the event came from contract token activity                                                           |
| `_updated_at`      | `TIMESTAMP WITH TIME ZONE` | Timestamp when the curated row was last written                                                               |

<TableSample />

## Sample Queries

**Query token movement for a specific Stellar address**

This query returns incoming and outgoing token events with populated normalized amounts for a wallet during a historical window:

```sql theme={null}
SELECT
    block_time,
    transaction_hash,
    asset,
    event_topic,
    event_type,
    CASE
        WHEN "from" = 'GAUA7XL5K54CC2DDGP77FJ2YBHRJLT36CPZDXWPM6MP7MANOGG77PNJU' THEN 'Outgoing'
        WHEN "to" = 'GAUA7XL5K54CC2DDGP77FJ2YBHRJLT36CPZDXWPM6MP7MANOGG77PNJU' THEN 'Incoming'
    END AS direction,
    amount
FROM tokens_stellar.transfers
WHERE (
        "from" = 'GAUA7XL5K54CC2DDGP77FJ2YBHRJLT36CPZDXWPM6MP7MANOGG77PNJU'
        OR "to" = 'GAUA7XL5K54CC2DDGP77FJ2YBHRJLT36CPZDXWPM6MP7MANOGG77PNJU'
    )
    AND event_topic <> 'fee'
    AND block_time >= TIMESTAMP '2025-11-24 00:00:00 UTC'
    AND block_time < TIMESTAMP '2025-12-01 00:00:00 UTC'
ORDER BY block_time DESC
LIMIT 100
```

**Calculate daily transfer volume for a specific Stellar asset**

This query aggregates daily transfer activity for issued USDC during a historical window:

```sql theme={null}
SELECT
    date_trunc('day', block_time) AS day,
    asset,
    COUNT(*) AS num_rows,
    SUM(amount) AS total_amount
FROM tokens_stellar.transfers
WHERE asset = 'USDC:GA5ZSEJYB37JRC5AVCIA5MOP4RHTM335X2KGX3IHOJAPP5RE34K4KZVN'
    AND event_topic = 'transfer'
    AND block_time >= TIMESTAMP '2025-11-01 00:00:00 UTC'
    AND block_time < TIMESTAMP '2025-12-01 00:00:00 UTC'
GROUP BY 1, 2
ORDER BY 1 DESC
```

**Split Stellar token activity by event category and source**

This query helps distinguish transfers from mints, burns, clawbacks, and fees, while also separating classic and contract-based activity during a historical window with populated normalized amounts:

```sql theme={null}
SELECT
    date_trunc('day', block_time) AS day,
    event_topic,
    COALESCE(CAST(is_soroban AS VARCHAR), 'false') AS soroban_flag,
    COUNT(*) AS num_rows,
    SUM(amount) AS total_amount
FROM tokens_stellar.transfers
WHERE block_time >= TIMESTAMP '2025-11-01 00:00:00 UTC'
    AND block_time < TIMESTAMP '2025-12-01 00:00:00 UTC'
    AND asset = 'native'
GROUP BY 1, 2, 3
ORDER BY 1 DESC, 2, 3
```


# Sui Token Transfers
Source: https://docs.dune.com/data-catalog/curated/token-transfers/sui/sui-token-transfers

Curated and enriched fungible token transfer activity on the Sui blockchain.

The `tokens_sui.transfers` table contains curated fungible token transfer activity for Sui `Coin<T>` assets indexed on Dune. Because Sui is object-based, the table reconstructs token movement from coin-object ownership and balance changes, then combines that with explicit mint and burn supply events.

This dataset includes:

* Cross-address transfer rows derived from `Coin<T>` object ownership and balance deltas
* Event-native mint and burn rows derived from Sui treasury events
* Metadata enrichment for symbol and decimals
* USD valuation when an hourly USD price is available for the token

<Info>
  The table aims to capture standard Sui `Coin<T>` transfer activity. Because Sui transfers are object-based, some rows represent balance adjustments caused by coin object ownership changes rather than a direct transfer between two addresses.
</Info>

### Utility

The Sui transfers table provides a consistent view of fungible token movement on Sui, enabling you to:

* Track wallet-to-wallet coin movement across Sui addresses
* Analyze transfer volume by coin, wallet, and day
* Separate regular transfers from mint and burn activity
* Investigate object-based balance changes and supply updates in one table

### Methodology

Sui token movement is modeled differently than EVM and Aptos transfers. The official Sui docs describe Sui as an object-based chain, and fungible assets using the Coin standard are represented as `Coin<T>` objects. The same docs also note that minting and burning require the token's `TreasuryCap`. Dune's Sui transfers model aligns to that design and reconstructs transfer rows from `Coin<T>` object history plus treasury supply events.

The `tokens_sui.transfers` table is built as follows:

* It starts from Sui `Coin<T>` object lifecycle and owner-net transfer models, keeping non-zero balance changes and ownership changes.
* Cross-address transfers are reconstructed from object ownership changes and balance deltas, including transfers with and without balance changes.
* Event-native treasury mint and burn rows are added from supply events, and overlapping legacy object rows are removed when those event-native supply rows exist.
* Symbol and decimals are enriched from Sui coin metadata in `sui_coin_info`.
* `amount_usd` is calculated from hourly Sui token pricing when a price is available for that hour.

### Pricing Methodology

The `price_usd` and `amount_usd` columns come from Dune's external hourly price feed for Sui tokens. If a token has a price for that hour, the transfer row gets a USD price and value. If not, both columns stay `NULL`.

This approach is meant to keep transfer valuations stable and avoid obvious outliers from thin or noisy onchain pricing. For tokens outside Dune's trusted token set, very large computed USD values are set to `NULL` instead of being shown.

For more details on Dune's pricing methodology, see the [Prices documentation](/data-catalog/curated/prices/overview).

## Table Schema

| Column                 | Type            | Description                                                   |
| ---------------------- | --------------- | ------------------------------------------------------------- |
| `unique_key`           | `VARCHAR`       | Surrogate key to identify a unique transfer row               |
| `blockchain`           | `VARCHAR`       | Blockchain identifier (`sui`)                                 |
| `block_month`          | `DATE`          | Month bucket derived from `block_time`                        |
| `block_date`           | `DATE`          | Block date                                                    |
| `block_time`           | `TIMESTAMP`     | Block timestamp                                               |
| `checkpoint`           | `DECIMAL(20,0)` | Sui checkpoint number                                         |
| `tx_digest`            | `VARCHAR`       | Sui transaction digest                                        |
| `token_standard`       | `VARCHAR`       | Token standard label for the transfer record                  |
| `from`                 | `VARBINARY`     | Transfer sender address                                       |
| `to`                   | `VARBINARY`     | Transfer receiver address                                     |
| `contract_address`     | `VARBINARY`     | Package address extracted from `coin_type`                    |
| `coin_type`            | `VARCHAR`       | Full Sui coin type                                            |
| `symbol`               | `VARCHAR`       | Token symbol from Sui coin metadata                           |
| `decimals`             | `INTEGER`       | Display decimals from Sui coin metadata                       |
| `amount_raw`           | `DECIMAL(38,0)` | Raw token amount before decimal adjustment                    |
| `amount`               | `DOUBLE`        | Transfer amount in display units                              |
| `price_usd`            | `DOUBLE`        | Hourly USD price used to calculate `amount_usd`               |
| `amount_usd`           | `DOUBLE`        | USD value of the transfer                                     |
| `balance_delta`        | `DECIMAL(38,0)` | Signed balance change associated with the transfer row        |
| `object_id`            | `VARBINARY`     | Sui coin object identifier when applicable                    |
| `version`              | `DECIMAL(20,0)` | Coin object version when applicable                           |
| `object_status`        | `VARCHAR`       | Object lifecycle status for the coin object row               |
| `owner_type`           | `VARCHAR`       | Sui owner type associated with the row                        |
| `coin_balance`         | `DECIMAL(38,0)` | Coin object balance at this version                           |
| `prev_balance`         | `DECIMAL(38,0)` | Previous observed balance for the same object                 |
| `prev_owner`           | `VARBINARY`     | Previous observed owner for the same object                   |
| `has_ownership_change` | `BOOLEAN`       | Whether ownership changed between consecutive object versions |
| `transfer_type`        | `VARCHAR`       | Transfer label describing the row's reconstruction path       |
| `is_supply_event`      | `BOOLEAN`       | True for event-native mint/burn rows                          |
| `supply_event_type`    | `VARCHAR`       | Mint/burn label for supply-event rows                         |
| `transfer_direction`   | `VARCHAR`       | Direction label derived from the balance movement             |
| `_updated_at`          | `TIMESTAMP`     | Timestamp when this row was last written                      |

<TableSample />

## Sample Queries

**Query recent priced token transfers for a specific Sui address**

This query returns the most recent incoming and outgoing token transfers for a wallet where USD pricing is available:

```sql theme={null}
SELECT
    block_time,
    tx_digest,
    symbol,
    transfer_type,
    CASE
        WHEN "from" = 0xd3ae6e1c897c97a5a50c696227dfea5719ddaaa5450cb70e35ff78339a173445 THEN 'Outgoing'
        WHEN "to" = 0xd3ae6e1c897c97a5a50c696227dfea5719ddaaa5450cb70e35ff78339a173445 THEN 'Incoming'
    END AS direction,
    amount,
    amount_usd
FROM tokens_sui.transfers
WHERE (
        "from" = 0xd3ae6e1c897c97a5a50c696227dfea5719ddaaa5450cb70e35ff78339a173445
        OR "to" = 0xd3ae6e1c897c97a5a50c696227dfea5719ddaaa5450cb70e35ff78339a173445
    )
    AND amount_usd IS NOT NULL
    AND block_time > now() - interval '30' day
ORDER BY block_time DESC
LIMIT 100
```

**Calculate daily transfer volume for a specific Sui coin**

This query aggregates daily transfer activity for one Sui coin type:

```sql theme={null}
SELECT
    block_date,
    symbol,
    COUNT(*) AS num_rows,
    SUM(amount) AS total_amount,
    SUM(amount_usd) AS total_amount_usd
FROM tokens_sui.transfers
WHERE coin_type = '0x2::sui::SUI'
    AND is_supply_event = false
    AND block_date >= current_date - interval '30' day
GROUP BY 1, 2
ORDER BY 1 DESC
```

**Query recent mint and burn events for a Sui coin**

This query returns recent supply-changing events for a Sui coin with active mint and burn activity:

```sql theme={null}
SELECT
    block_time,
    tx_digest,
    symbol,
    supply_event_type AS flow_type,
    amount,
    amount_usd
FROM tokens_sui.transfers
WHERE coin_type = '0xdba34672e30cb065b1f93e3ab55318768fd6fef66c15942c9f7cb846e2f900e7::usdc::usdc'
    AND is_supply_event = true
    AND block_time > now() - interval '30' day
ORDER BY block_time DESC
LIMIT 100
```


# XRPL Token Transfers
Source: https://docs.dune.com/data-catalog/curated/token-transfers/xrpl/xrpl-token-transfers

Unified token transfer activity for native XRP, issued currencies, and AMM-related token movement on XRP Ledger.

The `tokens_xrpl.transfers` table contains token movement data for XRP Ledger assets indexed on Dune. It brings native XRP transfers, issued currency payments, checks, escrows, payment channel claims, and AMM-related token movement into one curated table.

This dataset includes:

* Native XRP and issued currency transfer rows
* Payment, check, escrow, payment channel, AMM deposit, and AMM withdraw activity
* Asset identifiers using `xrpl_asset_id`, issuer, currency, and currency hex fields
* USD valuation when an hourly USD price is available for the asset

<Info>
  This table represents token movement on XRP Ledger, not just simple `Payment` transactions. It also includes AMM liquidity movements and other transaction types that move XRP or issued currencies, so filter by `transfer_type` or `transaction_type` when you need a narrower view.
</Info>

### Utility

The XRPL transfers table provides a consistent view of token movement on XRP Ledger, enabling you to:

* Track flows of XRP and issued currencies between XRPL accounts
* Analyze transfer activity by asset, issuer, transaction type, and day
* Separate regular payments from checks, escrows, payment channels, and AMM liquidity activity
* Monitor partial payments and transaction results alongside the normalized transfer amount

### Methodology

According to the official XRP Ledger docs, [fungible assets](https://xrpl.org/docs/concepts/tokens/fungible-tokens) include native XRP and issued currencies held through trust lines, while [`Payment`](https://xrpl.org/docs/references/protocol/transactions/types/payment) transactions can deliver XRP or issued currencies and may also use partial payment semantics. XRPL also has protocol-native checks, escrows, payment channels, and AMM deposit and withdraw transactions that can move assets.

The `tokens_xrpl.transfers` table is built around those XRPL transaction semantics:

* It keeps successful XRPL transactions that produce token movement, including `Payment`, `CheckCash`, `EscrowFinish`, `PaymentChannelClaim`, `AMMDeposit`, and `AMMWithdraw`.
* It normalizes native XRP and issued currencies into a shared transfer schema with `from`, `to`, `issuer`, `currency`, `symbol`, and `xrpl_asset_id`.
* It labels each row with both the underlying `transaction_type` and a normalized `transfer_type`, such as `payment`, `check_cash`, `escrow_finish`, `payment_channel_claim`, `amm_deposit`, `amm_withdraw`, `amm_lp_mint`, and `amm_lp_burn`.
* It carries `partial_payment_flag` for XRPL `Payment` rows where partial payment semantics apply.
* Native XRP uses 6 decimals; issued currencies may not have a decimal value populated because XRPL issued currencies use their own decimal representation.

### Pricing Methodology

The `price_usd` and `amount_usd` columns come from Dune's external hourly price feed for XRPL assets. If an asset has a price for that hour, the transfer row gets a USD price and value. If not, both columns stay `NULL`.

For more details on Dune's pricing methodology, see the [Prices documentation](/data-catalog/curated/prices/overview).

## Table Schema

| Column                 | Type                       | Description                                                                     |
| ---------------------- | -------------------------- | ------------------------------------------------------------------------------- |
| `unique_key`           | `VARCHAR`                  | Surrogate key to identify a unique transfer row                                 |
| `blockchain`           | `VARCHAR`                  | Blockchain name; always `xrpl`                                                  |
| `block_month`          | `DATE`                     | Month of the ledger close time                                                  |
| `block_date`           | `DATE`                     | Date of the ledger close time                                                   |
| `block_time`           | `TIMESTAMP WITH TIME ZONE` | Ledger close timestamp                                                          |
| `block_number`         | `BIGINT`                   | XRPL ledger index                                                               |
| `tx_hash`              | `VARCHAR`                  | Transaction hash                                                                |
| `token_standard`       | `VARCHAR`                  | Token standard label, such as `native` or `issued`                              |
| `tx_from`              | `VARCHAR`                  | Account that submitted the transaction                                          |
| `tx_to`                | `VARCHAR`                  | Destination account from the transaction when available                         |
| `tx_index`             | `BIGINT`                   | Transaction index within the ledger                                             |
| `from`                 | `VARCHAR`                  | Source account for the token movement                                           |
| `to`                   | `VARCHAR`                  | Destination account for the token movement                                      |
| `xrpl_asset_id`        | `VARCHAR`                  | Dune asset identifier for the XRPL asset                                        |
| `issuer`               | `VARCHAR`                  | Issuer account for issued currencies; native XRP uses the native XRP identifier |
| `currency`             | `VARCHAR`                  | XRPL currency code or native XRP symbol                                         |
| `currency_hex`         | `VARCHAR`                  | Hex-encoded currency code when applicable                                       |
| `symbol`               | `VARCHAR`                  | Display symbol for the asset                                                    |
| `decimals`             | `INTEGER`                  | Number of decimals used to scale `amount_raw` when available                    |
| `amount_raw`           | `DOUBLE`                   | Raw amount from the XRPL transfer representation                                |
| `amount`               | `DOUBLE`                   | Normalized transfer amount                                                      |
| `price_usd`            | `DOUBLE`                   | Hourly USD price used to calculate `amount_usd`                                 |
| `amount_usd`           | `DOUBLE`                   | USD value of the transfer                                                       |
| `transfer_type`        | `VARCHAR`                  | Normalized transfer category                                                    |
| `transaction_type`     | `VARCHAR`                  | Underlying XRPL transaction type                                                |
| `transaction_result`   | `VARCHAR`                  | XRPL transaction result code                                                    |
| `partial_payment_flag` | `BOOLEAN`                  | Whether the transaction used XRPL partial payment semantics                     |
| `_updated_at`          | `TIMESTAMP WITH TIME ZONE` | Timestamp when the curated row was last written                                 |

<TableSample />

## Sample Queries

**Query token movement for a specific XRPL account**

This query returns recent incoming and outgoing token transfers for an XRPL account:

```sql theme={null}
SELECT
    block_time,
    tx_hash,
    symbol,
    transfer_type,
    transaction_type,
    CASE
        WHEN "from" = 'r3CUuqXukpx393PvgP6Cn2z3kx5vPmesWf' THEN 'Outgoing'
        WHEN "to" = 'r3CUuqXukpx393PvgP6Cn2z3kx5vPmesWf' THEN 'Incoming'
    END AS direction,
    amount,
    amount_usd
FROM tokens_xrpl.transfers
WHERE (
        "from" = 'r3CUuqXukpx393PvgP6Cn2z3kx5vPmesWf'
        OR "to" = 'r3CUuqXukpx393PvgP6Cn2z3kx5vPmesWf'
    )
    AND block_date >= current_date - interval '30' day
ORDER BY block_time DESC
LIMIT 100
```

**Calculate daily transfer volume for native XRP**

This query aggregates recent native XRP transfer activity:

```sql theme={null}
SELECT
    block_date,
    symbol,
    COUNT(*) AS num_rows,
    SUM(amount) AS total_amount,
    SUM(amount_usd) AS total_amount_usd
FROM tokens_xrpl.transfers
WHERE xrpl_asset_id = 'xrp'
    AND block_date >= current_date - interval '30' day
GROUP BY 1, 2
ORDER BY 1 DESC
```

**Split XRPL activity by transfer type**

This query separates regular payments from checks, escrows, payment channels, and AMM activity:

```sql theme={null}
SELECT
    block_date,
    transfer_type,
    transaction_type,
    COUNT(*) AS num_rows,
    SUM(amount) AS total_amount,
    SUM(amount_usd) AS total_amount_usd
FROM tokens_xrpl.transfers
WHERE block_date >= current_date - interval '30' day
GROUP BY 1, 2, 3
ORDER BY 1 DESC, 4 DESC
```


# utils.days
Source: https://docs.dune.com/data-catalog/curated/utilities/days

Calendar date scaffold — one row per day for time-series joins and aggregation windows.

The `utils.days` table contains one row per day from January 3, 2009 (Bitcoin genesis) to the current date. Use it to fill gaps in daily time-series data.

## Table Schema

| Column      | Type        | Description                                                   |
| ----------- | ----------- | ------------------------------------------------------------- |
| `timestamp` | `TIMESTAMP` | Day timestamp (one row per day from Bitcoin genesis to today) |

## Table sample

<TableSample />


# Utilities
Source: https://docs.dune.com/data-catalog/curated/utilities/overview

Time-series scaffolding tables for blockchain analytics on Dune

Dune's utility tables provide time-series scaffolding — pre-built tables of timestamps at different granularities from Bitcoin genesis (January 3, 2009) to the current date. They are essential for creating continuous time axes in queries and dashboards.

<Info>
  **Maintained by:** Dune · **Refresh:** N/A · **Coverage:** Universal (no chain-specific data)
</Info>

<Card title="Get This Data" icon="database" href="https://dune.com/enterprise?dataset=utilities">
  Access utility tables via API, Datashare, or the Dune App.
</Card>

## Available Tables

| Table            | Granularity         |
| ---------------- | ------------------- |
| `utils.days`     | One row per day     |
| `utils.hours`    | One row per hour    |
| `utils.minutes`  | One row per minute  |
| `utils.weeks`    | One row per week    |
| `utils.months`   | One row per month   |
| `utils.quarters` | One row per quarter |
| `utils.years`    | One row per year    |

All tables have a single column: `timestamp` (type: `timestamp(3) with time zone`), spanning from January 3, 2009 (Bitcoin genesis) to the current date.

## When to Use These Tables

* Fill gaps in time-series data (ensure every day/hour has a row, even with zero activity)
* Generate date ranges for analysis windows
* Build continuous time axes for dashboard charts
* Create calendar-based aggregations

## Example Queries

**Fill gaps in daily DEX volume (ensures every day appears):**

```sql theme={null}
SELECT
  d.timestamp AS day,
  COALESCE(SUM(t.amount_usd), 0) AS daily_volume
FROM utils.days d
LEFT JOIN dex.trades t
  ON date_trunc('day', t.block_time) = d.timestamp
  AND t.blockchain = 'ethereum'
WHERE d.timestamp >= DATE '2025-01-01'
  AND d.timestamp < CURRENT_DATE
GROUP BY 1
ORDER BY 1
```

**Hourly gas fee analysis with no gaps:**

```sql theme={null}
SELECT
  h.timestamp AS hour,
  COALESCE(AVG(g.tx_fee_usd), 0) AS avg_fee_usd,
  COALESCE(COUNT(g.tx_hash), 0) AS num_transactions
FROM utils.hours h
LEFT JOIN gas.fees g
  ON date_trunc('hour', g.block_time) = h.timestamp
  AND g.blockchain = 'ethereum'
WHERE h.timestamp >= NOW() - INTERVAL '48' HOUR
GROUP BY 1
ORDER BY 1
```

<CardGroup>
  <Card title="Enterprise Data Solutions" icon="building" href="https://dune.com/enterprise">
    Need custom time-series utilities? Talk to our enterprise team.
  </Card>

  <Card title="Build Custom Models" icon="code" href="/api-reference/connectors/overview">
    Build private analytics pipelines with the dbt Connector.
  </Card>
</CardGroup>


# Vaults
Source: https://docs.dune.com/data-catalog/curated/vaults/overview

Vault protocol data across lending, liquid staking, and DeFi yield strategies

Vault protocols enable users to deposit assets into strategies that dynamically allocate capital across lending markets, staking, and yield opportunities. Dune provides access to decoded on-chain event data for vault-level activity including deposits, withdrawals, interest accrual, reallocation, and liquidations.

<Card title="Get This Data" icon="database" href="https://dune.com/enterprise?dataset=vaults">
  Access decoded vault tables via SQL in the Dune App, API, or Datashare.
</Card>

|                    |                                                                                                                                                           |
| ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Protocols**      | Morpho, Euler (v1 & v2), Aave v3, Fluid, Kamino (Solana), Lido (liquid staking)                                                                           |
| **Chains**         | Ethereum, Base, Arbitrum, Polygon, BNB, Solana, and others (coverage varies by protocol)                                                                  |
| **Data available** | Deposits & withdrawals · Interest accrual & yield signals · Liquidations & risk events · Vault reallocation / strategy activity · User-level interactions |
| **Data format**    | ABI-decoded event & call tables (protocol-specific schemas) · Accessible via SQL, API, or Datashare                                                       |
| **Best for**       | Vault flows & TVL estimation · Yield strategy analysis · Cross-protocol comparisons (with custom logic) · Risk / liquidation monitoring                   |

<Info>
  **No unified dataset yet.** Vault analysis currently requires protocol-specific logic using decoded event tables. A curated `vaults.*` dataset is on the roadmap. [Contact our enterprise team](https://dune.com/enterprise) to request priority access or share your use case.
</Info>

<Note>
  For curated lending data (supply, borrow, flash loans, liquidations) that covers Aave and other lending protocols in a normalized schema, see the [Lending](/data-catalog/curated/lending/overview) section.
</Note>

***

## Protocol Coverage

### Morpho

#### MetaMorpho Vaults (Vault-Level Activity)

Primary dataset for vault-level analysis. MetaMorpho vaults are curated lending strategies that allocate deposits across Morpho Blue markets.

**Namespace:** `metamorpho_vaults_multichain.*`
**Chains:** Ethereum, Base
**Chain-specific tables also available:** `metamorpho_vaults_ethereum.*`, `metamorpho_vaults_base.*`

| Table                                                                                                                                                | Description                                        |
| ---------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------- |
| [`metamorpho_vaults_multichain.metamorpho_evt_deposit`](https://dune.com/data/metamorpho_vaults_multichain.metamorpho_evt_deposit)                   | Deposit events (assets deposited, shares minted)   |
| [`metamorpho_vaults_multichain.metamorpho_evt_withdraw`](https://dune.com/data/metamorpho_vaults_multichain.metamorpho_evt_withdraw)                 | Withdrawal events (shares burned, assets returned) |
| [`metamorpho_vaults_multichain.metamorpho_evt_transfer`](https://dune.com/data/metamorpho_vaults_multichain.metamorpho_evt_transfer)                 | Vault share transfers between addresses            |
| [`metamorpho_vaults_multichain.metamorpho_evt_accrueinterest`](https://dune.com/data/metamorpho_vaults_multichain.metamorpho_evt_accrueinterest)     | Interest accrual events for yield tracking         |
| [`metamorpho_vaults_multichain.metamorpho_evt_reallocatesupply`](https://dune.com/data/metamorpho_vaults_multichain.metamorpho_evt_reallocatesupply) | Supply reallocation across underlying markets      |
| [`metamorpho_vaults_multichain.metamorpho_evt_setwithdrawqueue`](https://dune.com/data/metamorpho_vaults_multichain.metamorpho_evt_setwithdrawqueue) | Withdraw queue configuration updates               |
| [`metamorpho_vaults_multichain.metamorpho_evt_setcap`](https://dune.com/data/metamorpho_vaults_multichain.metamorpho_evt_setcap)                     | Market cap limit updates                           |

**Example — Daily Deposits by Vault:**

```sql theme={null}
SELECT
    block_date,
    contract_address AS vault_address,
    COUNT(*) AS num_deposits,
    COUNT(DISTINCT sender) AS unique_depositors
FROM metamorpho_vaults_ethereum.metamorpho_evt_deposit
WHERE block_date >= CURRENT_DATE - INTERVAL '30' DAY
GROUP BY 1, 2
ORDER BY 1 DESC
```

#### Morpho Core (Market-Level Activity)

Underlying lending market activity used by MetaMorpho vaults. Useful for understanding where vault capital is deployed.

**Namespace:** `morpho_multichain.*`
**Chains:** Arbitrum, Corn, Sonic, Unichain, Flare, Plume

| Table                                                                                                                      | Description                            |
| -------------------------------------------------------------------------------------------------------------------------- | -------------------------------------- |
| [`morpho_multichain.morpho_evt_supply`](https://dune.com/data/morpho_multichain.morpho_evt_supply)                         | Supply events to lending markets       |
| [`morpho_multichain.morpho_evt_borrow`](https://dune.com/data/morpho_multichain.morpho_evt_borrow)                         | Borrow events from lending markets     |
| [`morpho_multichain.morpho_evt_repay`](https://dune.com/data/morpho_multichain.morpho_evt_repay)                           | Loan repayment events                  |
| [`morpho_multichain.morpho_evt_withdraw`](https://dune.com/data/morpho_multichain.morpho_evt_withdraw)                     | Withdrawal events from lending markets |
| [`morpho_multichain.morpho_evt_supplycollateral`](https://dune.com/data/morpho_multichain.morpho_evt_supplycollateral)     | Collateral supply events               |
| [`morpho_multichain.morpho_evt_withdrawcollateral`](https://dune.com/data/morpho_multichain.morpho_evt_withdrawcollateral) | Collateral withdrawal events           |
| [`morpho_multichain.morpho_evt_liquidate`](https://dune.com/data/morpho_multichain.morpho_evt_liquidate)                   | Liquidation events                     |
| [`morpho_multichain.morpho_evt_createmarket`](https://dune.com/data/morpho_multichain.morpho_evt_createmarket)             | New market creation events             |
| [`morpho_multichain.morpho_evt_accrueinterest`](https://dune.com/data/morpho_multichain.morpho_evt_accrueinterest)         | Interest accrual at the market level   |

***

### Euler

#### Euler v2 (EVaults)

Primary dataset for Euler's vault-style lending markets across multiple chains.

**Namespace:** `euler_v2_<chain>.*` (e.g., `euler_v2_ethereum.*`, `euler_v2_base.*`)
**Chains:** Ethereum, Arbitrum, Base, Berachain, Unichain, Bob, TAC

**Event Tables:**

| Table                                                                                                   | Description          |
| ------------------------------------------------------------------------------------------------------- | -------------------- |
| [`euler_v2_<chain>.evault_evt_deposit`](https://dune.com/data/euler_v2_ethereum.evault_evt_deposit)     | Vault deposit events |
| [`euler_v2_<chain>.evault_evt_liquidate`](https://dune.com/data/euler_v2_ethereum.evault_evt_liquidate) | Liquidation events   |

**Call Tables:**

| Table                                                                                                     | Description                |
| --------------------------------------------------------------------------------------------------------- | -------------------------- |
| [`euler_v2_<chain>.evault_call_deposit`](https://dune.com/data/euler_v2_ethereum.evault_call_deposit)     | Deposit function calls     |
| [`euler_v2_<chain>.evault_call_withdraw`](https://dune.com/data/euler_v2_ethereum.evault_call_withdraw)   | Withdrawal function calls  |
| [`euler_v2_<chain>.evault_call_liquidate`](https://dune.com/data/euler_v2_ethereum.evault_call_liquidate) | Liquidation function calls |

**Example — Euler v2 Deposits Across Chains (30d):**

```sql theme={null}
SELECT
    'ethereum' AS chain,
    date_trunc('day', evt_block_time) AS day,
    COUNT(*) AS num_deposits
FROM euler_v2_ethereum.evault_evt_deposit
WHERE evt_block_time >= NOW() - INTERVAL '30' DAY
GROUP BY 1, 2

UNION ALL

SELECT
    'base' AS chain,
    date_trunc('day', evt_block_time) AS day,
    COUNT(*) AS num_deposits
FROM euler_v2_base.evault_evt_deposit
WHERE evt_block_time >= NOW() - INTERVAL '30' DAY
GROUP BY 1, 2

UNION ALL

SELECT
    'arbitrum' AS chain,
    date_trunc('day', evt_block_time) AS day,
    COUNT(*) AS num_deposits
FROM euler_v2_arbitrum.evault_evt_deposit
WHERE evt_block_time >= NOW() - INTERVAL '30' DAY
GROUP BY 1, 2

ORDER BY day DESC, chain
```

#### Euler v1 (Legacy — Ethereum Only)

**Namespace:** `euler_ethereum.*`

| Table                                                                                                        | Description                  |
| ------------------------------------------------------------------------------------------------------------ | ---------------------------- |
| [`euler_ethereum.euler_evt_deposit`](https://dune.com/data/euler_ethereum.euler_evt_deposit)                 | Deposit events               |
| [`euler_ethereum.euler_evt_withdraw`](https://dune.com/data/euler_ethereum.euler_evt_withdraw)               | Withdrawal events            |
| [`euler_ethereum.euler_evt_borrow`](https://dune.com/data/euler_ethereum.euler_evt_borrow)                   | Borrow events                |
| [`euler_ethereum.euler_evt_repay`](https://dune.com/data/euler_ethereum.euler_evt_repay)                     | Repayment events             |
| [`euler_ethereum.euler_evt_liquidation`](https://dune.com/data/euler_ethereum.euler_evt_liquidation)         | Liquidation events           |
| [`euler_ethereum.euler_evt_marketactivated`](https://dune.com/data/euler_ethereum.euler_evt_marketactivated) | New market activation events |
| [`euler_ethereum.euler_evt_assetstatus`](https://dune.com/data/euler_ethereum.euler_evt_assetstatus)         | Asset status updates         |

#### Euler Plasma (Vault Framework)

Advanced vault infrastructure with \~20+ tables covering controller status, account checks, operator management, and batch operations.

**Namespace:** `euler_plasma.*`

**Key Event Tables:**

| Table                                                                                                          | Description                        |
| -------------------------------------------------------------------------------------------------------------- | ---------------------------------- |
| [`euler_plasma.vault_evt_controllerstatus`](https://dune.com/data/euler_plasma.vault_evt_controllerstatus)     | Controller status changes          |
| [`euler_plasma.vault_evt_accountstatuscheck`](https://dune.com/data/euler_plasma.vault_evt_accountstatuscheck) | Account status verification events |
| [`euler_plasma.vault_evt_vaultstatuscheck`](https://dune.com/data/euler_plasma.vault_evt_vaultstatuscheck)     | Vault status verification events   |
| [`euler_plasma.vault_evt_operatorstatus`](https://dune.com/data/euler_plasma.vault_evt_operatorstatus)         | Operator permission changes        |
| [`euler_plasma.vault_evt_ownerregistered`](https://dune.com/data/euler_plasma.vault_evt_ownerregistered)       | Owner registration events          |

**Key Call Tables:**

| Table                                                                                                                              | Description           |
| ---------------------------------------------------------------------------------------------------------------------------------- | --------------------- |
| [`euler_plasma.vault_call_enablecollateral` / `disablecollateral`](https://dune.com/data/euler_plasma.vault_call_enablecollateral) | Collateral management |
| [`euler_plasma.vault_call_enablecontroller` / `disablecontroller`](https://dune.com/data/euler_plasma.vault_call_enablecontroller) | Controller management |
| [`euler_plasma.vault_call_setoperator` / `setaccountoperator`](https://dune.com/data/euler_plasma.vault_call_setoperator)          | Operator permissions  |
| [`euler_plasma.vault_call_batch` / `batchrevert`](https://dune.com/data/euler_plasma.vault_call_batch)                             | Batch operations      |
| [`euler_plasma.vault_call_controlcollateral`](https://dune.com/data/euler_plasma.vault_call_controlcollateral)                     | Collateral control    |

***

### Aave v3

Aave v3 is a lending protocol where each reserve acts as a pool accepting deposits and issuing borrows. While not a "vault" protocol in the MetaMorpho sense, Aave pools function similarly for deposit/withdraw tracking and are commonly analyzed alongside vault protocols.

**Namespace:** `aave_v3_multichain.*`
**Chains:** Ethereum, Base, Arbitrum, Avalanche, BNB, Celo, Fantom, Gnosis, Mantle, MegaETH, Optimism, Polygon, Sonic, zkSync
**L2-specific tables:** `aave_v3_multichain.l2pool_*` for Arbitrum, Base, Ink, Linea, Mantle, Scroll

| Table                                                                                                                    | Description                           |
| ------------------------------------------------------------------------------------------------------------------------ | ------------------------------------- |
| [`aave_v3_multichain.pool_evt_supply`](https://dune.com/data/aave_v3_multichain.pool_evt_supply)                         | Deposit/supply events                 |
| [`aave_v3_multichain.pool_evt_withdraw`](https://dune.com/data/aave_v3_multichain.pool_evt_withdraw)                     | Withdrawal events                     |
| [`aave_v3_multichain.pool_evt_borrow`](https://dune.com/data/aave_v3_multichain.pool_evt_borrow)                         | Borrow events                         |
| [`aave_v3_multichain.pool_evt_repay`](https://dune.com/data/aave_v3_multichain.pool_evt_repay)                           | Repayment events                      |
| [`aave_v3_multichain.pool_evt_liquidationcall`](https://dune.com/data/aave_v3_multichain.pool_evt_liquidationcall)       | Liquidation events                    |
| [`aave_v3_multichain.pool_evt_flashloan`](https://dune.com/data/aave_v3_multichain.pool_evt_flashloan)                   | Flash loan events                     |
| [`aave_v3_multichain.pool_evt_reservedataupdated`](https://dune.com/data/aave_v3_multichain.pool_evt_reservedataupdated) | Reserve data updates (rates, indices) |

**Example — Supply Events by Chain (30d):**

```sql theme={null}
SELECT
    chain,
    COUNT(*) AS num_supplies,
    COUNT(DISTINCT "user") AS unique_suppliers
FROM aave_v3_multichain.pool_evt_supply
WHERE evt_block_time >= NOW() - INTERVAL '30' DAY
GROUP BY 1
ORDER BY num_supplies DESC
```

<Note>
  For normalized lending data across Aave and other protocols, see the [Lending](/data-catalog/curated/lending/overview) curated tables which provide a unified schema.
</Note>

***

### Fluid

Fluid uses a tiered vault architecture (T1–T4) for borrowing with different collateral and debt configurations.

**Namespace:** `fluid_multichain.*`
**Chains:** Arbitrum, Base, BNB, Ethereum, Plasma, Polygon

#### Vault Operations

| Table                                                                                                                | Description                                          |
| -------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------- |
| [`fluid_multichain.fluidvaultt1_evt_logoperate`](https://dune.com/data/fluid_multichain.fluidvaultt1_evt_logoperate) | T1 vault operations (single collateral, single debt) |
| [`fluid_multichain.fluidvaultt2_evt_logoperate`](https://dune.com/data/fluid_multichain.fluidvaultt2_evt_logoperate) | T2 vault operations (single collateral, multi debt)  |
| [`fluid_multichain.fluidvaultt3_evt_logoperate`](https://dune.com/data/fluid_multichain.fluidvaultt3_evt_logoperate) | T3 vault operations (multi collateral, single debt)  |
| [`fluid_multichain.fluidvaultt4_evt_logoperate`](https://dune.com/data/fluid_multichain.fluidvaultt4_evt_logoperate) | T4 vault operations (multi collateral, multi debt)   |

#### Liquidations

| Table                                                                                                                    | Description     |
| ------------------------------------------------------------------------------------------------------------------------ | --------------- |
| [`fluid_multichain.fluidvaultt1_evt_logliquidate`](https://dune.com/data/fluid_multichain.fluidvaultt1_evt_logliquidate) | T1 liquidations |
| [`fluid_multichain.fluidvaultt2_evt_logliquidate`](https://dune.com/data/fluid_multichain.fluidvaultt2_evt_logliquidate) | T2 liquidations |
| [`fluid_multichain.fluidvaultt3_evt_logliquidate`](https://dune.com/data/fluid_multichain.fluidvaultt3_evt_logliquidate) | T3 liquidations |
| [`fluid_multichain.fluidvaultt4_evt_logliquidate`](https://dune.com/data/fluid_multichain.fluidvaultt4_evt_logliquidate) | T4 liquidations |

#### Other Events

| Table                                                                                                                                        | Description             |
| -------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------- |
| [`fluid_multichain.fluidvaultt1_evt_logabsorb`](https://dune.com/data/fluid_multichain.fluidvaultt1_evt_logabsorb)                           | T1 bad debt absorptions |
| [`fluid_multichain.fluidvaultt4_evt_logupdateexchangeprice`](https://dune.com/data/fluid_multichain.fluidvaultt4_evt_logupdateexchangeprice) | Exchange price updates  |
| [`fluid_multichain.fluidvaultfactory_evt_vaultdeployed`](https://dune.com/data/fluid_multichain.fluidvaultfactory_evt_vaultdeployed)         | Vault deployment events |

**Example — Vault Operations by Type (30d):**

```sql theme={null}
SELECT
    'T1' AS vault_type,
    date_trunc('day', evt_block_time) AS day,
    COUNT(*) AS num_operations
FROM fluid_multichain.fluidvaultt1_evt_logoperate
WHERE evt_block_time >= NOW() - INTERVAL '30' DAY
GROUP BY 1, 2

UNION ALL

SELECT
    'T2' AS vault_type,
    date_trunc('day', evt_block_time) AS day,
    COUNT(*) AS num_operations
FROM fluid_multichain.fluidvaultt2_evt_logoperate
WHERE evt_block_time >= NOW() - INTERVAL '30' DAY
GROUP BY 1, 2

UNION ALL

SELECT
    'T3' AS vault_type,
    date_trunc('day', evt_block_time) AS day,
    COUNT(*) AS num_operations
FROM fluid_multichain.fluidvaultt3_evt_logoperate
WHERE evt_block_time >= NOW() - INTERVAL '30' DAY
GROUP BY 1, 2

UNION ALL

SELECT
    'T4' AS vault_type,
    date_trunc('day', evt_block_time) AS day,
    COUNT(*) AS num_operations
FROM fluid_multichain.fluidvaultt4_evt_logoperate
WHERE evt_block_time >= NOW() - INTERVAL '30' DAY
GROUP BY 1, 2

ORDER BY day DESC, vault_type
```

***

### Kamino (Solana)

Kamino vaults on Solana allocate deposits into lending reserves with automated strategy management.

**Namespace:** `kamino_vault_solana.*`
**Chain:** Solana

#### Event Tables

| Table                                                                                                                                                      | Description                                       |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------- |
| [`kamino_vault_solana.kamino_vault_evt_depositresultevent`](https://dune.com/data/kamino_vault_solana.kamino_vault_evt_depositresultevent)                 | Deposit results (shares minted, tokens deposited) |
| [`kamino_vault_solana.kamino_vault_evt_withdrawresultevent`](https://dune.com/data/kamino_vault_solana.kamino_vault_evt_withdrawresultevent)               | Withdraw results (shares burned, tokens returned) |
| [`kamino_vault_solana.kamino_vault_evt_deposituseratabalanceevent`](https://dune.com/data/kamino_vault_solana.kamino_vault_evt_deposituseratabalanceevent) | User ATA balance after deposit                    |
| [`kamino_vault_solana.kamino_vault_evt_sharestowithdrawevent`](https://dune.com/data/kamino_vault_solana.kamino_vault_evt_sharestowithdrawevent)           | Shares available for withdrawal                   |

#### Call Tables

| Table                                                                                                                                                  | Description                       |
| ------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------- |
| [`kamino_vault_solana.kamino_vault_call_deposit`](https://dune.com/data/kamino_vault_solana.kamino_vault_call_deposit)                                 | Deposit into vault                |
| [`kamino_vault_solana.kamino_vault_call_withdraw`](https://dune.com/data/kamino_vault_solana.kamino_vault_call_withdraw)                               | Withdraw from vault               |
| [`kamino_vault_solana.kamino_vault_call_withdrawfromavailable`](https://dune.com/data/kamino_vault_solana.kamino_vault_call_withdrawfromavailable)     | Withdraw from available liquidity |
| [`kamino_vault_solana.kamino_vault_call_buy`](https://dune.com/data/kamino_vault_solana.kamino_vault_call_buy)                                         | Buy vault shares                  |
| [`kamino_vault_solana.kamino_vault_call_sell`](https://dune.com/data/kamino_vault_solana.kamino_vault_call_sell)                                       | Sell vault shares                 |
| [`kamino_vault_solana.kamino_vault_call_invest`](https://dune.com/data/kamino_vault_solana.kamino_vault_call_invest)                                   | Invest vault funds into reserve   |
| [`kamino_vault_solana.kamino_vault_call_initvault`](https://dune.com/data/kamino_vault_solana.kamino_vault_call_initvault)                             | Initialize new vault              |
| [`kamino_vault_solana.kamino_vault_call_updatereserveallocation`](https://dune.com/data/kamino_vault_solana.kamino_vault_call_updatereserveallocation) | Update reserve allocation weights |
| [`kamino_vault_solana.kamino_vault_call_removeallocation`](https://dune.com/data/kamino_vault_solana.kamino_vault_call_removeallocation)               | Remove a reserve allocation       |
| [`kamino_vault_solana.kamino_vault_call_withdrawpendingfees`](https://dune.com/data/kamino_vault_solana.kamino_vault_call_withdrawpendingfees)         | Withdraw pending fees             |

**Example — Kamino Vault Deposits on Solana (30d):**

```sql theme={null}
SELECT
    date_trunc('day', call_block_time) AS day,
    COUNT(*) AS num_deposits,
    COUNT(DISTINCT tx_signer) AS unique_depositors
FROM kamino_vault_solana.kamino_vault_call_deposit
WHERE call_block_time >= NOW() - INTERVAL '30' DAY
    AND call_success = true
GROUP BY 1
ORDER BY 1 DESC
```

***

### Lido (Liquid Staking)

Lido provides liquid staking for ETH via stETH. While primarily a staking protocol, Lido's architecture includes vault-related components (VaultFactory, VaultHub, StakingVault) under the `lido_ethereum` namespace.

**Namespace:** `lido_ethereum.*`
**Chain:** Ethereum

#### stETH Core (Staking Activity)

| Table                                                                                                          | Description                         |
| -------------------------------------------------------------------------------------------------------------- | ----------------------------------- |
| [`lido_ethereum.steth_evt_submitted`](https://dune.com/data/lido_ethereum.steth_evt_submitted)                 | ETH staking deposits (stETH minted) |
| [`lido_ethereum.steth_evt_transfer`](https://dune.com/data/lido_ethereum.steth_evt_transfer)                   | stETH token transfers               |
| [`lido_ethereum.steth_evt_transfershares`](https://dune.com/data/lido_ethereum.steth_evt_transfershares)       | Share-based transfers               |
| [`lido_ethereum.steth_evt_ethdistributed`](https://dune.com/data/lido_ethereum.steth_evt_ethdistributed)       | ETH rewards distribution            |
| [`lido_ethereum.steth_evt_tokenrebased`](https://dune.com/data/lido_ethereum.steth_evt_tokenrebased)           | Rebase events (balance updates)     |
| [`lido_ethereum.steth_evt_elrewardsreceived`](https://dune.com/data/lido_ethereum.steth_evt_elrewardsreceived) | Execution layer rewards             |

#### Withdrawal Queue

| Table                                                                                                                                                | Description                  |
| ---------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------- |
| [`lido_ethereum.withdrawalqueueerc721_evt_withdrawalrequested`](https://dune.com/data/lido_ethereum.withdrawalqueueerc721_evt_withdrawalrequested)   | Withdrawal request events    |
| [`lido_ethereum.withdrawalqueueerc721_evt_withdrawalclaimed`](https://dune.com/data/lido_ethereum.withdrawalqueueerc721_evt_withdrawalclaimed)       | Claimed withdrawal events    |
| [`lido_ethereum.withdrawalqueueerc721_evt_withdrawalsfinalized`](https://dune.com/data/lido_ethereum.withdrawalqueueerc721_evt_withdrawalsfinalized) | Finalized withdrawal batches |

#### Vault Infrastructure

| Table                                                                                                                    | Description                      |
| ------------------------------------------------------------------------------------------------------------------------ | -------------------------------- |
| [`lido_ethereum.vaultfactory_evt_vaultcreated`](https://dune.com/data/lido_ethereum.vaultfactory_evt_vaultcreated)       | New vault creation events        |
| [`lido_ethereum.vaulthub_evt_vaultconnected`](https://dune.com/data/lido_ethereum.vaulthub_evt_vaultconnected)           | Vault connected to hub           |
| [`lido_ethereum.vaulthub_evt_vaultrebalanced`](https://dune.com/data/lido_ethereum.vaulthub_evt_vaultrebalanced)         | Vault rebalancing events         |
| [`lido_ethereum.vaulthub_evt_vaultreportapplied`](https://dune.com/data/lido_ethereum.vaulthub_evt_vaultreportapplied)   | Vault performance reports        |
| [`lido_ethereum.vaulthub_evt_mintedsharesonvault`](https://dune.com/data/lido_ethereum.vaulthub_evt_mintedsharesonvault) | Shares minted on vault           |
| [`lido_ethereum.vaulthub_evt_burnedsharesonvault`](https://dune.com/data/lido_ethereum.vaulthub_evt_burnedsharesonvault) | Shares burned on vault           |
| [`lido_ethereum.vaulthub_evt_vaultfeesupdated`](https://dune.com/data/lido_ethereum.vaulthub_evt_vaultfeesupdated)       | Fee configuration updates        |
| [`lido_ethereum.stakingvault_evt_etherfunded`](https://dune.com/data/lido_ethereum.stakingvault_evt_etherfunded)         | ETH funded to staking vault      |
| [`lido_ethereum.stakingvault_evt_etherwithdrawn`](https://dune.com/data/lido_ethereum.stakingvault_evt_etherwithdrawn)   | ETH withdrawn from staking vault |
| [`lido_ethereum.stakingvault_evt_etherstaged`](https://dune.com/data/lido_ethereum.stakingvault_evt_etherstaged)         | ETH staged for operations        |

**Example — Lido stETH Deposits vs Withdrawal Requests (30d):**

```sql theme={null}
WITH deposits AS (
    SELECT
        date_trunc('day', evt_block_time) AS day,
        SUM(CAST(amount AS DOUBLE)) / 1e18 AS eth_deposited
    FROM lido_ethereum.steth_evt_submitted
    WHERE evt_block_time >= NOW() - INTERVAL '30' DAY
    GROUP BY 1
),
withdrawals AS (
    SELECT
        date_trunc('day', evt_block_time) AS day,
        SUM(CAST(amountOfStETH AS DOUBLE)) / 1e18 AS steth_withdrawal_requested
    FROM lido_ethereum.withdrawalqueueerc721_evt_withdrawalrequested
    WHERE evt_block_time >= NOW() - INTERVAL '30' DAY
    GROUP BY 1
)

SELECT
    COALESCE(d.day, w.day) AS day,
    COALESCE(d.eth_deposited, 0) AS eth_deposited,
    COALESCE(w.steth_withdrawal_requested, 0) AS steth_withdrawal_requested,
    COALESCE(d.eth_deposited, 0) - COALESCE(w.steth_withdrawal_requested, 0) AS net_flow
FROM deposits d
FULL OUTER JOIN withdrawals w ON d.day = w.day
ORDER BY day DESC
```

***

## Common Analysis Patterns

### Deposits & Withdrawals

Track capital inflows and outflows per vault or protocol. Most protocols emit separate deposit and withdraw events with amount fields.

### TVL Estimation

Aggregate deposits minus withdrawals over time. For USD denomination, join with `prices.day`, `prices.hour`, or `prices.minute` depending on the granularity needed. Accurate point-in-time TVL will improve once the [Balances](/data-catalog/curated/balances/overview) tables are fully available.

### Volume Tracking

Sum deposit and withdrawal amounts over time intervals to measure vault activity and capital velocity.

### Unique Depositors

Count distinct wallet addresses interacting with vault deposit events to track user adoption.

### Reallocation Analysis

For protocols like Morpho (MetaMorpho), track how vaults shift capital across underlying markets using reallocation events.

### Liquidations

Monitor liquidation events across protocols to assess vault health and risk.

***

## Cross-Protocol Starter Query

**Daily Deposit Events Across Protocols (30d):**

```sql theme={null}
WITH morpho AS (
    SELECT date_trunc('day', evt_block_time) AS day, 'Morpho (MetaMorpho)' AS protocol, COUNT(*) AS deposit_events
    FROM metamorpho_vaults_multichain.metamorpho_evt_deposit
    WHERE evt_block_time >= NOW() - INTERVAL '30' DAY
    GROUP BY 1
),
aave AS (
    SELECT date_trunc('day', evt_block_time) AS day, 'Aave v3' AS protocol, COUNT(*) AS deposit_events
    FROM aave_v3_multichain.pool_evt_supply
    WHERE evt_block_time >= NOW() - INTERVAL '30' DAY
    GROUP BY 1
),
lido AS (
    SELECT date_trunc('day', evt_block_time) AS day, 'Lido' AS protocol, COUNT(*) AS deposit_events
    FROM lido_ethereum.steth_evt_submitted
    WHERE evt_block_time >= NOW() - INTERVAL '30' DAY
    GROUP BY 1
),
fluid AS (
    SELECT date_trunc('day', evt_block_time) AS day, 'Fluid' AS protocol, COUNT(*) AS deposit_events
    FROM fluid_multichain.fluidvaultt1_evt_logoperate
    WHERE evt_block_time >= NOW() - INTERVAL '30' DAY
    GROUP BY 1
),
euler AS (
    SELECT date_trunc('day', evt_block_time) AS day, 'Euler v2' AS protocol, COUNT(*) AS deposit_events
    FROM euler_v2_ethereum.evault_evt_deposit
    WHERE evt_block_time >= NOW() - INTERVAL '30' DAY
    GROUP BY 1
)

SELECT * FROM morpho
UNION ALL SELECT * FROM aave
UNION ALL SELECT * FROM lido
UNION ALL SELECT * FROM fluid
UNION ALL SELECT * FROM euler
ORDER BY day DESC, protocol
```

***

## Notes & Limitations

* **No unified dataset**: Analysis requires protocol-specific logic. Each protocol has its own event schema and naming conventions.
* **Coverage varies**: Not all protocols are decoded on all chains. Check the data explorer for the latest availability.
* **TVL is approximate**: Deposit-minus-withdrawal tracking provides a proxy. For precise TVL, combine with balance snapshots and pricing data from `prices.day` or `prices.hour`.
* **APY data not available**: On-chain yield/APY calculation requires combining interest accrual events with token pricing and time-weighted math. This is complex and protocol-specific.
* **Holder counts deferred**: Accurate holder tracking requires the [Balances](/data-catalog/curated/balances/overview) tables, which are in open beta.
* **Some protocols overlap with Lending**: Aave v3 data is also covered in the [Lending](/data-catalog/curated/lending/overview) curated tables in a normalized schema. Use the curated lending tables for cross-protocol comparisons, and decoded tables here for vault-specific or protocol-specific analysis.
* **Token decimals vary per vault**: MetaMorpho vault `assets` values are denominated in the underlying token's smallest unit (e.g., 6 decimals for USDC, 18 for WETH). Always join with `tokens.erc20` for decimal normalization before computing USD values via `prices.day`.
* **Event counts ≠ volume**: Cross-protocol event count comparisons are directional only. Some protocols (e.g., Fluid) emit a single event per operation that covers supply + borrow + repay, while others have separate events.
* **Automated activity**: Some chains (e.g., Gnosis on Aave v3) show high event counts driven by automated/bot activity rather than organic user deposits.

***

## Related Tables

<CardGroup>
  <Card title="Lending" icon="hand-holding-dollar" href="/data-catalog/curated/lending/overview">
    Curated supply, borrow, flash loan, and liquidation data across lending protocols
  </Card>

  <Card title="Balances" icon="scale-balanced" href="/data-catalog/curated/balances/overview">
    Token balance snapshots for holder analysis
  </Card>

  <Card title="Prices" icon="dollar-sign" href="/data-catalog/curated/prices/overview">
    Token pricing for USD denomination
  </Card>

  <Card title="Token Transfers" icon="coins" href="/data-catalog/curated/token-transfers/overview">
    Raw transfer events for flow analysis
  </Card>

  <Card title="DEX Trades" icon="shuffle" href="/data-catalog/curated/dex-trades/overview">
    DEX activity for vault token trading
  </Card>
</CardGroup>

***

## Enterprise Data Solutions

Need a unified vaults dataset, custom vault analytics, or dedicated support? [Talk to our enterprise team](https://dune.com/enterprise).


# Data Freshness
Source: https://docs.dune.com/data-catalog/data-freshness

Understand the frequency of updates for various data types on Dune.

At Dune, data is continually refreshed through a multi-stage process to ensure accuracy and reliability. The three main stages of data updates are: **Raw Data**, **Decoded Data**, and **Curated Data**. The update frequency for each type of data varies based on several factors.

## Raw Data

Raw data consists of tables such as `ethereum.blocks` or `ethereum.transactions` that are directly ingested from the blockchain. The frequency of raw data updates is primarily influenced by the blockchain's frequency of producing blocks and its likelihood of a reorg.

### Blockchain Dependence

* **Chains like Optimism, Arbitrum, and Avalanche**: These blockchains exhibit lower chances of undergoing reorgs. As a result, data ingestion occurs more swiftly since the stability of these chains allows for quicker validation of block data.
* **Chains like Polygon and Ethereum**: Given their higher propensity for reorgs, there is a deliberate delay in data ingestion. This delay ensures that only stable and reorg-resistant blocks are considered, preventing the ingestion of potentially unstable or reversible transactions.

We do our best to ensure that the data is as fresh as possible while maintaining the integrity of the data. You can find the data freshness of the raw data in the table below.

<DuneEmbed />

## Decoded Data

Decoded data refers to tables such as `uniswap_v3_ethereum.Factory_evt_PoolCreated` or `tokens_ethereum.erc20` that are derived from the raw data. This stage of data processing involves transforming raw blockchain data into more accessible and interpretable formats.

The decoding of data is performed in real-time and is contingent on the volume of data being processed. The typical timeline for decoding is as follows:

* **Time Frame**: Decoding generally occurs within 15 to 60 seconds following the ingestion of raw data.
* **Dependency on Data Volume**: The specific duration within this range depends on the current data throughput and the complexity of the decoding operations required.

You can find the data freshness of the decoded data in the table below.

<DuneEmbed />

## Curated Data

Curated data tables on Dune are tables like `dex.trades` or `nft.trades` that are derived from raw and decoded data. They take away the complexity of working with raw or even decoded data and are ready to be used for analysis.
The data pipelines are open-source and documented in this [GitHub repository](https://github.com/duneanalytics/spellbook).

Curated tables are usually scheduled to run once every hour. The runtime of the data models can vary depending on the volume of transactions on any given day, therefore curated datasets are sometimes slower than the usual 1-hour target to update. Solana datasets such as `dex_solana.trades` and `tokens_solana.transfers` are an exception — they run on a 6-hour schedule, so data freshness for these tables is typically 6–7 hours.

<DuneEmbed />

## Community Data

Several notable 3rd party data providers are uploading their data into Dune. These data providers have their own update schedules and are not controlled by Dune. The data freshness of these providers can be found in the table below.

<DuneEmbed />


# Data Trust & Reliability
Source: https://docs.dune.com/data-catalog/data-quality

How Dune ensures complete, accurate, and reliable blockchain data through continuous automated verification across 100+ blockchains.

## Verified at Every Stage of the Pipeline

Dune is committed to delivering high-fidelity blockchain data that teams can trust for critical analytics, applications, and business decisions. Our data quality framework ensures accuracy, completeness, and consistency across 100+ blockchains through continuous automated verification and monitoring.

Data quality isn't a one-off test. It's a set of automated, continuous checks running at every stage of our pipeline, from raw block ingestion through transformation and delivery.

<Info>
  **Monitoring:** [Status Page](https://status.dune.com/) · [Data Freshness](/data-catalog/data-freshness)
</Info>

## Trusted at Scale

Dune has been indexing and serving blockchain data longer than any other onchain data platform. Our infrastructure processes millions of queries per day across 100+ blockchains, powering analytics for leading exchanges, DeFi protocols, investment firms, and blockchain foundations worldwide.

This isn't just scale for its own sake. It's operational proof. Every chain-specific edge case, every reorg pattern, every data quality challenge that exists in onchain data, we've encountered and built systems to handle. The quality framework described on this page has been refined through years of production operation at a scale no other onchain data provider matches.

> *"Huge credit to the Dune team for their speed, precision, and commitment to making onchain data accessible and actionable."*
> **Luke Judges**, Director at Ripple

***

## How Our Pipeline Works

Dune's data pipeline processes blockchain data through three stages, each with its own quality controls:

**1. Ingestion**: We ingest raw block, transaction, log, and trace data directly from blockchain nodes. Automated checks at this stage catch missing blocks, duplicates, and malformed data.

**2. Automated Quality Processing**: Continuous, 24/7 reconciliation and validation runs across all data tiers. This includes gap detection, reorg handling, deduplication passes, ABI validation for decoded data, and cross-reference checks between data layers.

**3. Validated Output**: The result is production-ready datasets that have been validated through the processes above. Raw data preserves full chain history with integrity guarantees. Decoded data accurately parses contract interactions. Curated datasets like `dex.trades` and `tokens.transfers` apply standardized schemas and business logic to make blockchain data easily accessible for all your use cases.

***

## Our Data Quality Framework

### Gap Detection

We ensure complete chain histories with no missing blocks or transactions. Our automated systems continuously scan for gaps in data sequences and flag any missing records for immediate remediation.

### Duplicate Detection

Our data pipeline includes validation checks to prevent duplicate records from appearing in our datasets. This is critical for accurate counting, aggregation, and analysis.

### Block Integrity

Every block must contain all its expected components in the correct structure and sequence. We verify that blocks maintain continuity across chains and that all transactions, event logs, and trace data within each block are complete and properly ordered.

### Re-org Handling

Blockchain reorganizations can invalidate recently indexed data. Our raw data infrastructure includes reorg detection and handling mechanisms to maintain data accuracy:

* **Finality awareness**: For chains with higher reorg propensity, we wait for sufficient block confirmations before indexing. This ensures that only finalized, stable blocks are included, preventing the ingestion of potentially reversible transactions.
* **Reorg detection**: We run checks to identify blocks where chain reorganizations have occurred, flagging affected data for correction.
* **Data correction**: When reorgs are detected, affected blocks are re-harvested and replaced with the canonical chain state.

<Warning>
  **Important caveats:**

  **Reorg detection coverage varies by chain.** While our reorg handling is robust for high-value chains with known reorg patterns, detection and correction timelines can vary across our full chain catalog.

  **Curated data propagation is not immediate.** If a curated dataset (e.g., `dex.trades`) processes data from a block that is later reorged, the curated data updates on its next transformation cycle, not immediately. For the vast majority of use cases this has no practical impact, as reorgs typically affect only the most recent blocks and curated data refreshes frequently.
</Warning>

### Token Metadata Updates

Token metadata (names, symbols, decimals, contract addresses) changes frequently as new tokens are deployed and standards evolve. Dune continuously updates token metadata across all supported chains to ensure you always have access to the latest information.

### Null Detection & Validation

We identify and address missing values in critical data fields. Our validation rules flag unexpected nulls in essential columns, ensuring data completeness and preventing errors in downstream analysis.

## Monitoring & Transparency

Real-time visibility into data health:

<CardGroup>
  <Card title="Data Freshness" icon="clock" href="/data-catalog/data-freshness">
    Check current ingestion latency for all supported chains and curated datasets.
  </Card>

  <Card title="Status Page" icon="signal" href="https://status.dune.com/">
    Subscribe to alerts for any incidents affecting data availability or quality.
  </Card>
</CardGroup>

If you discover a data quality issue, [let our team know](mailto:support@dune.com). We investigate every report and prioritize fixes based on impact.

> *"Dune has by far the largest and most comprehensive dataset on the market."*
> **Dan Smith**, Senior Research at Blockworks

***

## Next Steps

<CardGroup>
  <Card title="Enterprise Data Quality Guarantees" icon="building" href="https://dune.com/enterprise">
    For custom SLAs, dedicated support, and priority issue resolution, talk to our enterprise team.
  </Card>

  <Card title="Build Validated Pipelines on Dune" icon="code-branch" href="/api-reference/connectors/dbt/overview">
    Run your own dbt projects on Dune's data warehouse. Full incremental model support, automated testing, and CI/CD.
  </Card>
</CardGroup>


# Transaction Fees
Source: https://docs.dune.com/data-catalog/dune-index/gas-fees

Understanding transaction fees and their relationship to transaction costs in blockchain networks

<Warning>
  **The Dune Index has been sunset.** The underlying methodology and queries remain accessible. See the [introduction page](/data-catalog/dune-index/introduction) for details on how to continue using this data.
</Warning>

## Overview

Transaction fees represent the dollar costs of executing operations on blockchain networks. By measuring transaction fees, we can understand the demand for resources on the network and the incentives that drive user behavior.
Gas fee calculations are more complex than they may seem at first glance. This is because different networks have different fee structures, and some even have multiple components to their fees. We are aggregating the data from multiple sources to provide a comprehensive view of the fees paid for each network.

You can explore the daily gas fee data via `metrics.gas_fees_daily`

<div>
  <DuneEmbed />
</div>

<TableSample />

### EVM Networks

For EVM networks, we have developed a unified model to calculate transaction fees consistently across different types of chains. The data is accessible through the `gas.fees` table, which standardizes the fee components into `l1_fee`, `base_fee`, and `priority_fee`. This model elegantly unifies the fee structures of rollups, L1s, and L2s, providing a coherent view of gas costs across the EVM ecosystem. However, it's important to note that the specific fee components and their calculations may vary depending on the unique characteristics and design choices of each network. You can find the fee components for each network below.

<Tabs>
  <Tab title="Arbitrum">
    Arbitrum uses a custom L1/L2 fee model that ignores priority fees (tips) in calculations and uses effective\_gas\_price instead of standard gas\_price. This helps account for the actual costs of posting data to the L1 chain.

    ```sql theme={null}
    -- Two component fee structure
    l1_fee = gas_used_for_l1 * effective_gas_price
    base_fee = (gas_used - gas_used_for_l1) * effective_gas_price
    ```
  </Tab>

  <Tab title="Avalanche C-Chain">
    Avalanche C-Chain uses a standard fee structure with a base fee and an optional priority fee. This allows users to tip validators for faster transaction inclusion.

    ```sql theme={null}
    -- Two component fee structure (if priority fee exists)
    base_fee = base_fee_per_gas * gas_used
    priority_fee = priority_fee_per_gas * gas_used
    -- Single component fee structure (if no priority fee)
    base_fee = gas_price * gas_used
    ```
  </Tab>

  <Tab title="Base">
    Base employs a custom L1/L2 fee model with additional L1 data fields. This helps track the costs associated with posting data to the L1 chain for security.

    ```sql theme={null}
    -- Three component fee structure
    l1_fee = l1_fee
    base_fee = base_fee_per_gas * gas_used
    priority_fee = priority_fee_per_gas * gas_used
    -- Two component fee structure (if no priority fee)
    l1_fee = l1_fee
    base_fee = gas_price * gas_used
    ```
  </Tab>

  <Tab title="Blast">
    Blast uses a custom L1/L2 fee model with additional L1 data fields. This allows tracking the L1 data posting costs separately from the L2 execution fees.

    ```sql theme={null}
    -- Three component fee structure
    l1_fee = l1_fee
    base_fee = base_fee_per_gas * gas_used
    priority_fee = priority_fee_per_gas * gas_used
    -- Two component fee structure (if no priority fee)
    l1_fee = l1_fee
    base_fee = gas_price * gas_used
    ```
  </Tab>

  <Tab title="BNB Chain">
    BNB Chain uses a standard fee structure with a base fee and an optional priority fee. This allows users to incentivize faster transaction processing through tips.

    ```sql theme={null}
    -- Two component fee structure (if priority fee exists)
    base_fee = base_fee_per_gas * gas_used
    priority_fee = priority_fee_per_gas * gas_used
    -- Single component fee structure (if no priority fee)
    base_fee = gas_price * gas_used
    ```
  </Tab>

  <Tab title="Celo">
    Celo is excluded due to incorrect raw data. If included, it would use a
    standard fee structure with a base fee and an optional priority fee.
  </Tab>

  <Tab title="Ethereum">
    Ethereum uses a custom fee model with additional blob fee data. This helps
    account for the costs associated with storing large data blobs on the network.
    Fee components:

    ```sql theme={null}
    -- Four component fee structure
    blob_fee = blob_base_fee * blob_gas_used
    base_fee = base_fee_per_gas * gas_used
    priority_fee = priority_fee_per_gas * gas_used
    -- Three component fee structure (if no priority fee)
    blob_fee = blob_base_fee * blob_gas_used
    base_fee = gas_price * gas_used
    ```
  </Tab>

  <Tab title="Fantom">
    Fantom uses a standard fee structure with a base fee and an optional priority fee. This allows users to tip validators for faster transaction inclusion.

    ```sql theme={null}
    -- Two component fee structure (if priority fee exists)
    base_fee = base_fee_per_gas * gas_used
    priority_fee = priority_fee_per_gas * gas_used
    -- Single component fee structure (if no priority fee)
    base_fee = gas_price * gas_used
    ```
  </Tab>

  <Tab title="Gnosis">
    Gnosis uses a standard fee structure with a base fee and an optional priority fee. This allows users to incentivize faster transaction processing through tips.

    ```sql theme={null}
    -- Two component fee structure (if priority fee exists)
    base_fee = base_fee_per_gas * gas_used
    priority_fee = priority_fee_per_gas * gas_used
    -- Single component fee structure (if no priority fee)
    base_fee = gas_price * gas_used
    ```
  </Tab>

  <Tab title="Linea">
    Linea uses a standard fee structure with a base fee and an optional priority fee. This allows users to tip validators for faster transaction inclusion.

    ```sql theme={null}
    -- Two component fee structure (if priority fee exists)
    base_fee = base_fee_per_gas * gas_used
    priority_fee = priority_fee_per_gas * gas_used
    -- Single component fee structure (if no priority fee)
    base_fee = gas_price * gas_used
    ```
  </Tab>

  <Tab title="Mantle">
    Mantle employs a custom L1/L2 fee model with additional L1 data fields. This helps track the costs associated with posting data to the L1 chain for security.

    ```sql theme={null}
    -- Three component fee structure
    l1_fee = l1_fee
    base_fee = base_fee_per_gas * gas_used
    priority_fee = priority_fee_per_gas * gas_used
    -- Two component fee structure (if no priority fee)
    l1_fee = l1_fee
    base_fee = gas_price * gas_used
    ```
  </Tab>

  <Tab title="Optimism">
    Optimism uses a custom L1/L2 fee model with additional L1 data fields. This allows tracking the L1 data posting costs separately from the L2 execution fees.

    ```sql theme={null}
    -- Three component fee structure
    l1_fee = l1_fee
    base_fee = base_fee_per_gas * gas_used
    priority_fee = priority_fee_per_gas * gas_used
    -- Two component fee structure (if no priority fee)
    l1_fee = l1_fee
    base_fee = gas_price * gas_used
    ```
  </Tab>

  <Tab title="Polygon">
    Polygon uses a standard fee structure with a base fee and an optional priority fee. This allows users to incentivize faster transaction processing through tips.

    ```sql theme={null}
    -- Two component fee structure (if priority fee exists)
    base_fee = base_fee_per_gas * gas_used
    priority_fee = priority_fee_per_gas * gas_used
    -- Single component fee structure (if no priority fee)
    base_fee = gas_price * gas_used
    ```
  </Tab>

  <Tab title="Scroll">
    Scroll uses a custom L1/L2 fee model with additional L1 data fields. This helps track the costs associated with posting data to the L1 chain for security.

    ```sql theme={null}
    -- Three component fee structure
    l1_fee = l1_fee
    base_fee = base_fee_per_gas * gas_used
    priority_fee = priority_fee_per_gas * gas_used
    -- Two component fee structure (if no priority fee)
    l1_fee = l1_fee
    base_fee = gas_price * gas_used
    ```
  </Tab>

  <Tab title="Sei">
    Sei uses a standard fee structure with a base fee and an optional priority fee. This allows users to tip validators for faster transaction inclusion.

    ```sql theme={null}
    -- Two component fee structure (if priority fee exists)
    base_fee = base_fee_per_gas * gas_used
    priority_fee = priority_fee_per_gas * gas_used
    -- Single component fee structure (if no priority fee)
    base_fee = gas_price * gas_used
    ```
  </Tab>

  <Tab title="Tron">
    Tron uses a simplified fee structure using only gas price and gas used. This
    provides a straightforward way to calculate transaction fees. Tron also
    subsidizes the fees for transactions, so the fee paid is not necessarily the
    actual cost of the transaction. We are correcting for this in the
    `metrics.gas_fees_daily` table, but not in gas.fees yet.

    ```sql theme={null}
    tx_fee_raw = gas_used * gas_price
    ```
  </Tab>

  <Tab title="zkEVM">
    zkEVM uses a standard fee structure with a base fee and an optional priority fee. This allows users to incentivize faster transaction processing through tips.

    ```sql theme={null}
    -- Two component fee structure (if priority fee exists)
    base_fee = base_fee_per_gas * gas_used
    priority_fee = priority_fee_per_gas * gas_used
    -- Single component fee structure (if no priority fee)
    base_fee = gas_price * gas_used
    ```
  </Tab>

  <Tab title="zkSync">
    zkSync uses a simplified fee structure using only gas price and gas used. This provides a straightforward way to calculate transaction fees on the zkSync network.

    ```sql theme={null}
    base_fee = gas_price * gas_used
    ```
  </Tab>

  <Tab title="Zora">
    Zora uses a custom L1/L2 fee model with additional L1 data fields. This helps track the costs associated with posting data to the L1 chain for security.

    ```sql theme={null}
    -- Three component fee structure
    l1_fee = l1_fee
    base_fee = base_fee_per_gas * gas_used
    priority_fee = priority_fee_per_gas * gas_used
    -- Two component fee structure (if no priority fee)
    l1_fee = l1_fee
    base_fee = gas_price * gas_used
    ```
  </Tab>
</Tabs>

<CardGroup>
  <Card title="Fee Metrics Code" icon="code" href="https://github.com/duneanalytics/spellbook/tree/main/dbt_subprojects/daily_spellbook/models/_metrics/fees">
    View the source code for the fees metrics implementation.
  </Card>
</CardGroup>

### Non-EVM Networks

For non-EVM networks we haven't yet found a consistent way to model the fee structure, so we are not yet able to provide a unified model for non-EVM networks. However, all the data is included in the `metrics.gas_fees_daily` table.

#### Solana

Solana has two "types" of transactions: *transactions* and *votes*. We track the fees for each type separately in `gas_solana.tx_fees` and `gas_solana.vote_fees`.

<Tabs>
  <Tab title="Solana Transactions">
    Solana uses a custom fee structure with a base fee and an optional prioritization fee for transactions. The base fee is calculated based on the number of signatures required for the transaction, while the prioritization fee depends on the compute unit price and compute budget limit.

    ```sql theme={null}
    -- Two component fee structure
    base_fee = # of signatures * 0.000005
    priority_fee = compute_unit_price * compute_budget_limit
    ```

    This data is standardized in `gas_solana.tx_fees`.
  </Tab>

  <Tab title="Solana Votes">
    In Solana, votes that help the network reach consensus are also considered transactions. The fees are always 0.000005 SOL per vote, which is the base fee for a transaction with one signature.

    ```sql theme={null}
    -- single component fee structure
    fee = 0.000005
    ```

    Vote fees are not included in `gas_solana.tx_fees` and are instead included in `gas_solana.vote_fees`.
  </Tab>
</Tabs>

We consider both `gas_solana.tx_fees` and `gas_solana.vote_fees` when calculating the total transaction fees for Solana in `metrics.gas_fees_daily`.

#### Bitcoin

Bitcoin uses a simple fee structure where each transaction has a fee paid to the miner. Miners pick the transactions with the highest fees to include in the next block.

```sql theme={null}
-- Single component fee structure
fee = fee
```


# Dune Index
Source: https://docs.dune.com/data-catalog/dune-index/introduction

The Dune Index is a comprehensive indicator of blockchain adoption across the industry.

<Warning>
  **The Dune Index has been sunset.**

  While we are no longer actively maintaining this product, the underlying methodology and queries remain fully accessible. You can still:

  * **Query the underlying data** using the metrics tables referenced in this documentation (e.g., `metrics.gas_fees_daily`)
  * **Use our methodology** by referencing the [open-source code](https://github.com/duneanalytics/spellbook/tree/main/dbt_subprojects/daily_spellbook/models/_metrics/dune_index)
  * **Build your own analysis** based on the component metrics described below
</Warning>

## What is the Dune Index?

The Dune Index serves as a comprehensive measurement framework for blockchain adoption, designed to capture meaningful usage while filtering out speculative activity. By combining multiple standardized metrics, it provides an objective view of how blockchain technology is being utilized across different networks and use cases.

## Why the Dune Index?

Traditional blockchain metrics often fall short of measuring genuine adoption. Market capitalization and token prices primarily reflect speculative sentiment, while metrics like Total Value Locked (TVL) can be manipulated by large holders. The Dune Index addresses these limitations by focusing on actual network usage and economic activity.

The index was specifically designed to track meaningful adoption that indicates real-world utility. This approach helps stakeholders distinguish between speculative bubbles and sustainable growth in blockchain usage.

## Components

The Dune Index aggregates three fundamental metrics, each normalized to a baseline value of 10 to enable meaningful comparison:

<CardGroup>
  <Card title="Transaction Fees" icon="money-bill" href="/data-catalog/dune-index/gas-fees">
    Measures real demand for blockspace
  </Card>

  <Card title="Net USD Transferred" icon="money-bill-transfer" href="/data-catalog/dune-index/net-transfers">
    Tracks genuine value movement
  </Card>

  <Card title="Transactions" icon="arrow-right-arrow-left" href="/data-catalog/dune-index/transactions">
    Indicates breadth of usage
  </Card>
</CardGroup>

### Component Selection Rationale

These metrics were carefully chosen to provide a comprehensive view of blockchain usage. Transaction fees demonstrate users' willingness to pay for block space, serving as a market-driven indicator of demand. Net transfers capture actual economic activity while filtering out artificial volume. Transaction count provides context about the breadth of network usage.

Together, these metrics create a robust framework that resists artificial inflation and captures different aspects of blockchain utility.

<CardGroup>
  <Card title="Dune Index Metrics Code" icon="code" href="https://github.com/duneanalytics/spellbook/tree/main/dbt_subprojects/daily_spellbook/models/_metrics/dune_index">
    View the source code for the Dune Index metrics implementation.
  </Card>
</CardGroup>

## Implementation Guide

The Dune Index can be utilized in several ways:

* Track industry trends by monitoring long-term adoption patterns and growth trajectories across the blockchain space.
* Enable detailed blockchain breakdowns to compare adoption metrics between different networks.
* Through component analysis, users can evaluate the relative impact of each metric on overall adoption.
* The index methodology can also be extended for specialized research and custom analysis needs.

## Excluded Metrics

The index intentionally excludes several common blockchain metrics due to their limitations:

### Price and Market Capitalization

Market-based metrics were excluded as they primarily reflect speculative activity rather than actual usage. Price movements often diverge significantly from underlying adoption patterns and can be heavily influenced by market sentiment rather than utility.

### Total Value Locked (TVL)

While TVL provides insight into DeFi activity, it has significant limitations as an adoption metric. The metric can be manipulated by large holders, doesn't account for capital efficiency, and automatically increases with asset prices regardless of actual usage.

### Active Addresses

Address-based metrics prove problematic due to the ease of address creation and the common practice of users maintaining multiple addresses. These metrics fail to distinguish between meaningful activity and artificial inflation through address generation.


# Net USD Transferred
Source: https://docs.dune.com/data-catalog/dune-index/net-transfers

Understanding net USD transferred as a component of the Dune Index

<Warning>
  **The Dune Index has been sunset.** The underlying methodology and queries remain accessible. See the [introduction page](/data-catalog/dune-index/introduction) for details on how to continue using this data.
</Warning>

## Overview

Net USD transferred provides a measure of genuine economic activity across blockchain networks by tracking the actual movement of value between distinct entities. This metric implements sophisticated filtering mechanisms to distinguish meaningful transfers from artificial activity, offering insight into real economic impact.

## Technical Significance

Net transfers serve as a crucial indicator of blockchain utility by measuring actual value movement while filtering out noise. Unlike gross transfer volumes, which can be inflated through wash trading or circular transactions, net transfers focus on the ultimate economic impact of blockchain activity.

The metric is particularly valuable because it requires significant economic resources to manipulate, making it a more reliable indicator of genuine activity compared to metrics like transaction count or total volume.

## Calculation Methodology

The computation of net transfers follows a rigorous process:

1. Address-Level Aggregation
   * Track all value movements between addresses
   * Calculate daily net position changes per address (inflows minus outflows)

2. Filtering Criteria
   * Minimum threshold of \$1 to exclude dust transactions
   * Removal of internal transactions from known contracts and protocols
   * Exclusion of identified wash trading patterns
   * Filtering of exploit-related transfers and known scam addresses

3. Standardization
   * Conversion to USD equivalent values using time-weighted average prices
   * Normalization against baseline metrics for cross-chain comparison

<CardGroup>
  <Card title="Transfers Metrics Code" icon="code" href="https://github.com/duneanalytics/spellbook/tree/main/dbt_subprojects/daily_spellbook/models/_metrics/transfers">
    See the transfers metrics code for the technical implementation details.
  </Card>
</CardGroup>

## Analytical Framework

When interpreting net transfer data, consider several key aspects:

1. Volume Patterns
   * Analyze sustained periods of high net transfer volume
   * Identify unusual spikes that may indicate large-scale events or anomalies

2. Comparative Analysis
   * Compare net transfers against gross transfer volume to detect wash trading
   * Evaluate relationships with transaction counts and fee levels
   * Monitor distribution patterns across different blockchain networks

3. Network Effects
   * Consider how network upgrades or protocol changes impact transfer patterns
   * Analyze the impact of new DeFi protocols or applications on transfer volumes

This metric provides valuable insight into blockchain adoption when analyzed alongside other components of the Dune Index, offering a more complete picture of meaningful network usage.


# Transactions
Source: https://docs.dune.com/data-catalog/dune-index/transactions

Understanding transactions as a foundational component of the Dune Index

<Warning>
  **The Dune Index has been sunset.** The underlying methodology and queries remain accessible. See the [introduction page](/data-catalog/dune-index/introduction) for details on how to continue using this data.
</Warning>

## Overview

The transaction component of the Dune Index measures blockchain activity by counting transactions that transfer at least 1 USD in value. This filtered approach helps focus on meaningful economic activity while maintaining a simple, verifiable methodology.

## Methodology

The transaction metric employs a straightforward filtering approach:

1. Base Criteria
   * Count only transactions with transfers of \$1 or more
   * Convert all token transfers to USD value at time of transaction
   * Include both native token and token contract transfers

2. Rationale
   * \$1 threshold excludes dust transactions and spam
   * Low threshold maintains inclusivity of meaningful activity
   * Simple criteria enables consistent cross-chain comparison

3. Implementation
   * Track successful transfers only
   * Calculate USD value at transaction time
   * Aggregate across all supported token types

<CardGroup>
  <Card title="Transactions Metrics Code" icon="code" href="https://github.com/duneanalytics/spellbook/tree/main/dbt_subprojects/daily_spellbook/models/_metrics/transactions">
    View the source code for the transactions metrics implementation.
  </Card>
</CardGroup>

## Technical Considerations

Several factors influence transaction counting:

1. Value Calculation
   * Use time-weighted token prices
   * Account for token decimals and precision
   * Handle cases of missing price data

2. Cross-Chain Standardization
   * Apply consistent \$1 threshold across networks
   * Account for different token value representations
   * Handle multi-token transactions appropriately

## Limitations

Understanding the metric's limitations is crucial:

1. Threshold Effects
   * May exclude some meaningful sub-\$1 activity
   * Still includes some non-meaningful activity above \$1
   * Value threshold is nominal, not inflation-adjusted

2. Technical Constraints
   * Requires reliable price data for all tokens
   * Must handle complex transaction types consistently
   * Network upgrades may affect transaction classification

## Usage Guidelines

When analyzing transaction data:

1. Trend Analysis
   * Focus on directional changes over time
   * Compare across similar time periods
   * Consider seasonal and cyclical patterns

2. Context
   * Use alongside other Dune Index components
   * Consider network-specific factors
   * Account for major protocol changes

The transaction count provides a foundational measure of blockchain adoption while the \$1 threshold helps filter out noise, making it a valuable component of the Dune Index despite its inherent limitations.


# Block Events
Source: https://docs.dune.com/data-catalog/echelon/block_events

Echelon blockchain block events data

# Table Description

This table contains data about block-level events and attributes in the Echelon blockchain, including event types, sources, and associated metadata. The schema is modeled after Cosmos block events.

## Column Descriptions

| Column name          | Data Type                   | Description                                          |
| -------------------- | --------------------------- | ---------------------------------------------------- |
| **block\_date**      | date                        | The date of the block.                               |
| **block\_height**    | bigint                      | The height of the block where the event occurred.    |
| **block\_timestamp** | timestamp(3) with time zone | Timestamp when the block was validated.              |
| **chain\_id**        | varchar                     | The ID of the chain where the block belongs.         |
| **event\_index**     | bigint                      | A unique index for events within the block.          |
| **event\_type**      | varchar                     | The type of event that was triggered.                |
| **event\_source**    | varchar                     | The source of the event.                             |
| **attribute\_key**   | varchar                     | The key of the event attribute.                      |
| **attribute\_value** | varchar                     | The value of the event attribute.                    |
| **attribute\_index** | bigint                      | A unique index for attributes within the event.      |
| **updated\_at**      | timestamp(3) with time zone | Timestamp of when the record was last updated.       |
| **ingested\_at**     | timestamp(3) with time zone | Timestamp of when the record was ingested into Dune. |

## Table Sample

<TableSample />


# Blocks
Source: https://docs.dune.com/data-catalog/echelon/blocks

Echelon blockchain blocks data

# Table Description

This table contains data about blocks in the Echelon blockchain, including block headers, consensus data, and transaction information.

## Column Descriptions

| Column name           | Data Type                   | Description                                                  |
| --------------------- | --------------------------- | ------------------------------------------------------------ |
| **block\_date**       | date                        | The date of the block.                                       |
| **block\_height**     | bigint                      | The height of the block, a unique identifier for each block. |
| **block\_timestamp**  | timestamp(3) with time zone | Timestamp when the block was validated.                      |
| **chain\_id**         | varchar                     | The ID of the chain where the block belongs.                 |
| **proposer\_address** | varchar                     | The address of the validator proposing the block.            |
| **validators\_hash**  | varchar                     | The hash of the validators set for the block.                |
| **updated\_at**       | timestamp(3) with time zone | Timestamp of when the record was last updated.               |
| **ingested\_at**      | timestamp(3) with time zone | Timestamp of when the record was ingested into Dune.         |

## Table Sample

<TableSample />


# Message Events
Source: https://docs.dune.com/data-catalog/echelon/message_events

Echelon blockchain message events data

# Table Description

This table contains data about message-related events in the Echelon blockchain, including message types, attributes, and associated metadata. Because block events run on initia, this table is empty by design at this point.

## Table Schema

| Column name          | Description                                           | Type                        |
| -------------------- | ----------------------------------------------------- | --------------------------- |
| **block\_date**      | The date of the block.                                | date                        |
| **block\_height**    | The height of the block where the event occurred.     | bigint                      |
| **block\_timestamp** | Timestamp when the block was validated.               | timestamp(3) with time zone |
| **chain\_id**        | The ID of the chain where the block belongs.          | varchar                     |
| **tx\_id**           | The hash of the transaction where the event occurred. | varchar                     |
| **tx\_index**        | The index of the transaction in the block.            | bigint                      |
| **message\_index**   | The index of the message in the transaction.          | bigint                      |
| **event\_index**     | A unique index for events within the message.         | bigint                      |
| **event\_type**      | The type of event that was triggered.                 | varchar                     |
| **attribute\_key**   | The key of the event attribute.                       | varchar                     |
| **attribute\_value** | The value of the event attribute.                     | varchar                     |
| **attribute\_index** | A unique index for attributes within the event.       | bigint                      |
| **updated\_at**      | Timestamp of when the record was last updated.        | timestamp(3) with time zone |
| **ingested\_at**     | Timestamp of when the record was ingested into Dune.  | timestamp(3) with time zone |

## Table Sample

<TableSample />


# Echelon Data
Source: https://docs.dune.com/data-catalog/echelon/overview

Echelon blockchain data on Dune

## What is Echelon?

Echelon is a public Cosmos and EVM compatible blockchain protocol running as L2 on Initia. The Echelon consensus and layer protocols deliver unparalleled speed, scalability, and security.

Echelon equally serves as an application-agnostic chain fully interoperable with the Ethereum mainnet, all EVM compatible environments, and other BFT chains via IBC. Expectedly, it eases cross-chain transferrals of value for both developers and end-users.

## Key Features

* **Dual Compatibility**: Cosmos and EVM compatible blockchain protocol
* **High Performance**: Unparalleled speed, scalability, and security through advanced consensus and layer protocols
* **Cross-Chain Interoperability**: Fully interoperable with Ethereum mainnet, all EVM compatible environments, and other BFT chains via IBC
* **Application-Agnostic**: Flexible platform for various decentralized applications
* **DeFi Focus**: Bridges DeFi and mass adoption

## Echelon Data on Dune

Echelon blockchain data is organized into several key tables that capture different aspects of on-chain activity:

<CardGroup>
  <Card title="Blocks" icon="cube" href="/data-catalog/echelon/blocks">
    <p>Contains each validated block in the chain</p>
  </Card>

  <Card title="Block Events" icon="bolt" href="/data-catalog/echelon/block_events">
    <p>Contains all block-level events and attributes in the chain, partitioned by event\_index</p>
  </Card>

  <Card title="Message Events" icon="message" href="/data-catalog/echelon/message_events">
    <p>Contains all events and their corresponding attributes partitioned by message\_index</p>
  </Card>

  <Card title="Transactions" icon="arrow-right-arrow-left" href="/data-catalog/echelon/transactions">
    <p>Contains relevant data associated with each transaction</p>
  </Card>

  <Card title="Transaction Messages" icon="envelope" href="/data-catalog/echelon/tx_messages">
    <p>Contains all messages submitted to the blockchain</p>
  </Card>
</CardGroup>


# Transactions
Source: https://docs.dune.com/data-catalog/echelon/transactions

Echelon blockchain transactions data

# Table Description

This table contains data about transactions in the Echelon blockchain, including transaction details, gas usage, and execution status.

## Column Descriptions

| Column name            | Data Type                   | Description                                             |
| ---------------------- | --------------------------- | ------------------------------------------------------- |
| **block\_height**      | bigint                      | The height of the block where the transaction occurred. |
| **chain\_id**          | varchar                     | The ID of the chain where the transaction occurred.     |
| **tx\_id**             | varchar                     | The unique ID of the transaction.                       |
| **tx\_info**           | varchar                     | Information related to the transaction.                 |
| **tx\_log\_message**   | varchar                     | The log message associated with the transaction.        |
| **memo**               | varchar                     | A memo associated with the transaction.                 |
| **fee**                | varchar                     | The fee associated with the transaction.                |
| **tx\_code**           | bigint                      | The result code of the transaction.                     |
| **tx\_index**          | bigint                      | The index of the transaction within the block.          |
| **gas\_used**          | bigint                      | The amount of gas used by the transaction.              |
| **gas\_wanted**        | bigint                      | The amount of gas requested by the transaction.         |
| **schema\_version**    | bigint                      | The schema version for the transaction data.            |
| **fee\_coins**         | varchar                     | The coins used to pay the transaction fee.              |
| **fee\_granter**       | varchar                     | The address granting the fee for the transaction.       |
| **fee\_payer**         | varchar                     | The address paying the fee for the transaction.         |
| **gas\_limit**         | bigint                      | The gas limit set for the transaction.                  |
| **single\_sign\_mode** | bigint                      | The signing mode for single-signature transactions.     |
| **multi\_sign\_json**  | varchar                     | JSON structure for multi-signature transactions.        |
| **timeout\_height**    | varchar                     | The timeout height set for the transaction.             |
| **updated\_at**        | timestamp(3) with time zone | Timestamp of when the record was last updated.          |
| **ingested\_at**       | timestamp(3) with time zone | Timestamp of when the record was ingested into Dune.    |

## Table Sample

<TableSample />


# Transaction Messages
Source: https://docs.dune.com/data-catalog/echelon/tx_messages

Echelon blockchain transaction messages data

# Table Description

This table contains data about messages contained within transactions in the Echelon blockchain, including message types, content, and associated metadata.

<Tip>
  On execution, transactions from Cosmos emit data in two formats:

  * Messages (`echelon.tx_messages`): These provide a high-level, readable summary of actions, such as "send money" or "execute contract." They are easier to understand and track transaction types.
  * Events (`echelon.message_events`): These capture detailed, low-level changes at the chain level, including underlying blockchain modifications that may not always be directly related to state changes.
  * Use Messages for a general overview and Events when you need detailed insights. The two tables are complementary.
</Tip>

## Column Descriptions

| Column name          | Data Type                   | Description                                          |
| -------------------- | --------------------------- | ---------------------------------------------------- |
| **block\_date**      | date                        | The date of the block.                               |
| **block\_height**    | bigint                      | The height of the block where the message occurred.  |
| **block\_timestamp** | timestamp(3) with time zone | Timestamp when the block was validated.              |
| **chain\_id**        | varchar                     | The ID of the chain where the message belongs.       |
| **tx\_id**           | varchar                     | The hash of the transaction containing the message.  |
| **tx\_index**        | bigint                      | The index of the transaction in the block.           |
| **message\_index**   | bigint                      | The index of the message in the transaction.         |
| **message\_type**    | varchar                     | The type of message.                                 |
| **message**          | varchar                     | The value/content of the message.                    |
| **schema\_version**  | bigint                      | The version of the schema in provider database.      |
| **updated\_at**      | timestamp(3) with time zone | Timestamp of when the record was last updated.       |
| **ingested\_at**     | timestamp(3) with time zone | Timestamp of when the record was ingested into Dune. |

## Table Sample

<TableSample />


# dex.trades on abstract
Source: https://docs.dune.com/data-catalog/evm/abstract/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on abstract.

<DexTradesSnippet />


# NFT.trades on abstract
Source: https://docs.dune.com/data-catalog/evm/abstract/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on abstract.

<NFTTradesSnippet />


# Abstract Call Tables
Source: https://docs.dune.com/data-catalog/evm/abstract/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Abstract network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# abstract.contracts
Source: https://docs.dune.com/data-catalog/evm/abstract/decoded/contracts

Verified contract registry on Abstract — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs - Abstract
Source: https://docs.dune.com/data-catalog/evm/abstract/decoded/event-logs

Smart contracts on Abstract emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# abstract.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/abstract/decoded/logs-decoded

ABI-decoded event logs on Abstract — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Abstract Chain Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/abstract/decoded/overview

Simplifying Abstract Chain smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# abstract.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/abstract/decoded/traces-decoded

ABI-decoded function calls on Abstract — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Abstract Chain Overview
Source: https://docs.dune.com/data-catalog/evm/abstract/overview

Abstract blockchain data on Dune

## What is Abstract?

Abstract is a Layer 2 (L2) network built on top of Ethereum, designed to securely support consumer-facing blockchain applications at scale. Utilizing zero-knowledge (ZK) rollup technology, Abstract achieves low fees and fast transaction speeds by processing transactions off-chain, then batching and verifying them on Ethereum using ZK proofs.

With EVM compatibility, Abstract allows developers to port existing Ethereum applications with minimal adjustments, providing an Ethereum-like environment but with optimized scalability and reduced costs.

## Key Features of Abstract

Abstract's infrastructure is built with a focus on scalability, security, and developer accessibility, offering several powerful features:

### **Layer 2 ZK Rollup Architecture**

Abstract batches transactions off-chain and posts them to Ethereum for security, inheriting Ethereum’s security properties while enabling faster, more cost-effective transactions. This ZK rollup structure ensures that all state transitions are verified without executing transactions on Ethereum.

### **EVM Compatibility with Optimized VM**

Abstract maintains compatibility with the Ethereum ecosystem, allowing developers to use familiar tools. However, Abstract's ZKsync VM utilizes optimized bytecode and opcodes to facilitate efficient ZK proof generation, offering unique ways for developers to build scalable applications.

### **Lower Gas Fees and Higher Throughput**

Gas fees on Abstract are significantly lower than on Ethereum, thanks to batch processing and ZK proofing. This reduction in transaction costs, coupled with high throughput, makes Abstract ideal for high-demand applications.

## Transaction Lifecycle

Each transaction on Abstract undergoes a lifecycle that includes four key stages:

1. **Processing on Abstract**: Transactions are executed on Abstract, and soft confirmation is provided to the user.
2. **Batch Submission to Ethereum**: Transactions are batched and committed to Ethereum in optimized submissions.
3. **Proof Validation**: A ZK proof validating the batch is generated off-chain and verified by Ethereum.
4. **State Finalization**: Once verified, the state is finalized, ensuring transaction accuracy on Ethereum.

## EVM Differences

While compatible with Ethereum’s development environment, Abstract’s ZKsync VM introduces specific changes for optimized performance:

* **Opcode Adjustments**: Certain opcodes are modified or supplemented by system contracts.
* **Gas Fee Management**: Fees and refunds are handled differently via Abstract’s bootloader.
* **Nonces and Libraries**: Nonces are stored within smart contract accounts, and library handling is adapted for efficiency.

## Why Abstract?

Abstract combines Ethereum’s security with the scalability of ZK rollups, making it ideal for applications requiring high throughput and low transaction costs. This enables developers to build consumer-ready dApps without sacrificing speed, cost-efficiency, or security.

<CardGroup>
  <Card title="Abstract documentation" icon="link" href="https://docs.abs.xyz/overview">
    Access full documentation for Abstract, including architecture, EVM differences, and best practices.
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Smart contract event logs with insights into Abstract’s ZK rollup dynamics.
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on processed blocks, highlighting Abstract’s throughput.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Data on transactions, illustrating Abstract's cost-effective operation.
  </Card>

  <Card title="Decoded" icon="file" href="./decoded/overview">
    Decoded transaction data for in-depth analysis of contract executions.
  </Card>
</CardGroup>


# abstract.blocks
Source: https://docs.dune.com/data-catalog/evm/abstract/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Abstract.

<BlockSnippet />


# abstract.creation_traces
Source: https://docs.dune.com/data-catalog/evm/abstract/raw/creation-traces

Contract deployment records on Abstract — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# abstract.logs
Source: https://docs.dune.com/data-catalog/evm/abstract/raw/logs

Smart contract event logs on Abstract — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# abstract.traces
Source: https://docs.dune.com/data-catalog/evm/abstract/raw/traces

Internal transaction traces on Abstract — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# abstract.transactions
Source: https://docs.dune.com/data-catalog/evm/abstract/raw/transactions

Every transaction on Abstract — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex_aggregator.trades on apechain
Source: https://docs.dune.com/data-catalog/evm/apechain/curated-data/dex/dex-aggregator-trades

DEX aggregator swaps on ApeChain — trades routed through aggregators like 1inch, Paraswap, and CoW Swap with pricing and routing details.

<DexAggregatorTradesSnippet />


# dex.trades on apechain
Source: https://docs.dune.com/data-catalog/evm/apechain/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on apechain.

<DexTradesSnippet />


# NFT.trades on apechain
Source: https://docs.dune.com/data-catalog/evm/apechain/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on apechain.

<NFTTradesSnippet />


# ApeChain Call Tables
Source: https://docs.dune.com/data-catalog/evm/apechain/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the ApeChain network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# apechain.contracts
Source: https://docs.dune.com/data-catalog/evm/apechain/decoded/contracts

Verified contract registry on ApeChain — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs - Apechain
Source: https://docs.dune.com/data-catalog/evm/apechain/decoded/event-logs

Smart contracts on Apechain emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# apechain.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/apechain/decoded/logs-decoded

ABI-decoded event logs on ApeChain — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# ApeChain Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/apechain/decoded/overview

Simplifying ApeChain smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# apechain.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/apechain/decoded/traces-decoded

ABI-decoded function calls on ApeChain — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# ApeChain Overview
Source: https://docs.dune.com/data-catalog/evm/apechain/overview

ApeChain data on Dune

## What is ApeChain?

ApeChain is a dedicated infrastructure layer designed to power the ApeCoin ecosystem. Built on Arbitrum Orbit, it provides developers and users with the best possible experience on the blockchain by focusing on ecosystem discovery, unique web3 rails, and top of funnel exposure.

## Key Features

* **Native Gas Token**: Uses \$APE as its native gas token
* **Arbitrum Orbit**: Built as an Arbitrum Orbit chain for scalability and efficiency
* **Enhanced Utility**: Significantly enhances \$APE's utility
* **Ecosystem Focus**: Powers the ApeCoin ecosystem with dedicated infrastructure

## Why ApeChain?

ApeChain positions itself as a premier platform for the ApeCoin ecosystem by:

* Fostering a robust and dynamic economy driven by \$APE
* Providing dedicated infrastructure for ecosystem growth
* Enhancing the utility and value proposition of \$APE

## Technical Architecture

Built on Arbitrum Orbit, ApeChain inherits Arbitrum's robust technical foundation while adding ApeCoin-specific optimizations:

### Development Features

* **Arbitrum Technology**: Leverages Arbitrum's proven Layer 2 scaling solution
* **APE Integration**: Native support for APE token operations
* **Ecosystem Tools**: Comprehensive development and analytics tools

### Network Economics

* **Gas Token**: \$APE
* **Economic Model**: Designed to enhance \$APE utility and ecosystem value

<CardGroup>
  <Card title="ApeChain Documentation" icon="link" href="https://docs.apechain.com">
    Official documentation for developers building on ApeChain
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Insights into smart contract interactions through event logs
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on blocks processed on ApeChain, reflecting network activity and capacity
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Detailed data on transactions, showcasing efficiency and operational execution
  </Card>

  <Card title="decoded" icon="file" href="./decoded/overview">
    Decoded transaction information for enhanced analysis and understanding of smart contract executions
  </Card>
</CardGroup>


# apechain.blocks
Source: https://docs.dune.com/data-catalog/evm/apechain/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for ApeChain.

<BlockSnippet />


# apechain.creation_traces
Source: https://docs.dune.com/data-catalog/evm/apechain/raw/creation-traces

Contract deployment records on ApeChain — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# apechain.logs
Source: https://docs.dune.com/data-catalog/evm/apechain/raw/logs

Smart contract event logs on ApeChain — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# apechain.traces
Source: https://docs.dune.com/data-catalog/evm/apechain/raw/traces

Internal transaction traces on ApeChain — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# apechain.transactions
Source: https://docs.dune.com/data-catalog/evm/apechain/raw/transactions

Every transaction on ApeChain — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex_aggregator.trades on Arbitrum Nova
Source: https://docs.dune.com/data-catalog/evm/arbitrum-nova/curated-data/dex/dex-aggregator-trades

DEX aggregator swaps on Arbitrum Nova — trades routed through aggregators like 1inch, Paraswap, and CoW Swap with pricing and routing details.

<DexAggregatorTradesSnippet />


# dex.trades on nova
Source: https://docs.dune.com/data-catalog/evm/arbitrum-nova/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on nova.

<DexTradesSnippet />


# NFT.trades on Nova
Source: https://docs.dune.com/data-catalog/evm/arbitrum-nova/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on Nova.

<NFTTradesSnippet />


# Arbitrum Nova Call Tables
Source: https://docs.dune.com/data-catalog/evm/arbitrum-nova/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Arbitrum Nova network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# nova.contracts
Source: https://docs.dune.com/data-catalog/evm/arbitrum-nova/decoded/contracts

Verified contract registry on Arbitrum Nova — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs - Arbitrum Nova
Source: https://docs.dune.com/data-catalog/evm/arbitrum-nova/decoded/event-logs

Smart contracts on Arbitrum Nova emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# nova.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/arbitrum-nova/decoded/logs-decoded

ABI-decoded event logs on Arbitrum Nova — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Arbitrum Nova Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/arbitrum-nova/decoded/overview

Simplifying Arbitrum Nova smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# nova.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/arbitrum-nova/decoded/traces-decoded

ABI-decoded function calls on Arbitrum Nova — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Arbitrum Nova Overview
Source: https://docs.dune.com/data-catalog/evm/arbitrum-nova/overview

Arbitrum Nova data on Dune

## What is Arbitrum Nova?

Arbitrum Nova is a Layer 2 scaling solution on Ethereum that leverages the AnyTrust technology to provide efficient, low-cost transactions while maintaining high security and compatibility with the Ethereum ecosystem. As part of the Arbitrum family, Nova complements Arbitrum One by offering a different balance of security and transaction cost options for users and developers.

## Why Arbitrum Nova?

Arbitrum Nova is designed to handle high transaction volumes at a lower cost, making it ideal for applications such as gaming, social networks, and other scenarios where frequent, low-cost transactions are essential. It uses the AnyTrust protocol, which optimizes security and efficiency, ensuring that transactions are both economical and secure.

## Arbitrum Nova Architecture

Arbitrum Nova's architecture is built to maximize scalability and minimize transaction costs through its unique AnyTrust solution:

### AnyTrust Technology

At the core of Arbitrum Nova is the AnyTrust protocol, which provides a flexible approach to transaction validation. This protocol batches transactions and uses a committee of trusted validators to ensure the integrity and security of the data.

### Rollup Mechanism

Similar to Arbitrum One, Nova batches multiple transactions into a single rollup block. This rollup mechanism significantly increases throughput and reduces transaction costs by spreading the computational load across multiple transactions.

### Compatibility with Ethereum

Arbitrum Nova maintains full compatibility with the Ethereum Virtual Machine (EVM), allowing developers to deploy their existing Solidity smart contracts on Nova without modifications. This seamless integration with Ethereum ensures that Nova can support a wide range of decentralized applications (dApps) with ease.

## Arbitrum Ecosystem

Arbitrum offers two main chains on Ethereum: Arbitrum One, an Optimistic Rollup chain, and Arbitrum Nova, an AnyTrust chain. This dual-chain strategy allows users and developers to choose the solution that best fits their needs in terms of security and transaction costs.

### Utility Token

Ether (ETH) is the primary utility token on Arbitrum Nova, used for paying transaction fees. This alignment with Ethereum's native currency simplifies the user experience and enhances interoperability within the Ethereum ecosystem.

<CardGroup>
  <Card title="Arbitrum Nova Website" icon="link" href="https://arbitrum.io/anytrust">
    The official page for Arbitrum Nova (an AnyTrust chain), offering comprehensive details on the platform, its architecture, and resources for developers
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Insights into smart contract interactions through event logs
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on blocks processed on Arbitrum Nova, reflecting network activity and capacity
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Detailed data on transactions, showcasing efficiency and operational execution
  </Card>

  <Card title="decoded" icon="file" href="./decoded/overview">
    Decoded transaction information for enhanced analysis and understanding of smart contract executions
  </Card>
</CardGroup>


# nova.blocks
Source: https://docs.dune.com/data-catalog/evm/arbitrum-nova/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Arbitrum Nova.

<BlockSnippet />


# nova.creation_traces
Source: https://docs.dune.com/data-catalog/evm/arbitrum-nova/raw/creation-traces

Contract deployment records on Arbitrum Nova — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# nova.logs
Source: https://docs.dune.com/data-catalog/evm/arbitrum-nova/raw/logs

Smart contract event logs on Arbitrum Nova — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# nova.traces
Source: https://docs.dune.com/data-catalog/evm/arbitrum-nova/raw/traces

Internal transaction traces on Arbitrum Nova — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# nova.transactions
Source: https://docs.dune.com/data-catalog/evm/arbitrum-nova/raw/transactions

Every transaction on Arbitrum Nova — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex_aggregator.trades on Arbitrum
Source: https://docs.dune.com/data-catalog/evm/arbitrum/curated-data/dex/dex-aggregator-trades

DEX aggregator swaps on Arbitrum — trades routed through aggregators like 1inch, Paraswap, and CoW Swap with pricing and routing details.

<DexAggregatorTradesSnippet />


# dex.trades on arbitrum
Source: https://docs.dune.com/data-catalog/evm/arbitrum/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on arbitrum.

<DexTradesSnippet />


# NFT.trades on Arbitrum
Source: https://docs.dune.com/data-catalog/evm/arbitrum/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on Arbitrum.

<NFTTradesSnippet />


# Arbitrum One Call Tables
Source: https://docs.dune.com/data-catalog/evm/arbitrum/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Arbitrum One network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# arbitrum.contracts
Source: https://docs.dune.com/data-catalog/evm/arbitrum/decoded/contracts

Verified contract registry on Arbitrum — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs - Arbitrum
Source: https://docs.dune.com/data-catalog/evm/arbitrum/decoded/event-logs

Smart contracts on Arbitrum emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# arbitrum.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/arbitrum/decoded/logs-decoded

ABI-decoded event logs on Arbitrum — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Arbitrum One Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/arbitrum/decoded/overview

Simplifying Arbitrum One smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# arbitrum.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/arbitrum/decoded/traces-decoded

ABI-decoded function calls on Arbitrum — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Arbitrum One Overview
Source: https://docs.dune.com/data-catalog/evm/arbitrum/overview

Arbitrum One data on Dune

Arbitrum One is a Layer 2 scaling solution built on Ethereum that utilizes optimistic rollups to enhance scalability and reduce costs while maintaining compatibility with the Ethereum Virtual Machine (EVM). This allows developers to deploy their existing Solidity smart contracts on Arbitrum without any modifications.

At the heart of Arbitrum One's technology is its unique rollup solution, which batches multiple transactions into a single rollup block. This technique dramatically increases throughput and decreases the transaction costs, all while leveraging the underlying security of the Ethereum mainnet.

The primary utility token of Arbitrum One is Ether, which is used for paying transaction fees. Unlike traditional Layer 1 solutions, Arbitrum One offers a seamless extension of Ethereum, enhancing its scalability and efficiency without compromising on security or decentralization.

Dune provides extensive datasets for Arbitrum One, covering various aspects such as event logs, transactions, blocks, and token movements. These datasets provide valuable insights into network performance, user behavior, and smart contract functionality.

<CardGroup>
  <Card title="Arbitrum One docs" icon="link" href="https://arbitrum.io/docs">
    The official documentation for Arbitrum One, offering comprehensive details on the platform, its architecture, and resources for developers
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Insights into smart contract interactions through event logs
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on blocks processed on Arbitrum One, reflecting network activity and capacity
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Detailed data on transactions, showcasing efficiency and operational execution
  </Card>

  <Card title="Decoded" icon="file" href="./decoded/overview">
    Decoded transaction information for enhanced analysis and understanding of smart contract executions
  </Card>
</CardGroup>


# arbitrum.blocks
Source: https://docs.dune.com/data-catalog/evm/arbitrum/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Arbitrum.

<BlockSnippet />


# arbitrum.creation_traces
Source: https://docs.dune.com/data-catalog/evm/arbitrum/raw/creation-traces

Contract deployment records on Arbitrum — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# arbitrum.logs
Source: https://docs.dune.com/data-catalog/evm/arbitrum/raw/logs

Smart contract event logs on Arbitrum — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# arbitrum.traces
Source: https://docs.dune.com/data-catalog/evm/arbitrum/raw/traces

Internal transaction traces on Arbitrum — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# arbitrum.transactions
Source: https://docs.dune.com/data-catalog/evm/arbitrum/raw/transactions

Every transaction on Arbitrum — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex_aggregator.trades on avalanche
Source: https://docs.dune.com/data-catalog/evm/avalanche/curated-data/dex/dex-aggregator-trades

DEX aggregator swaps on Avalanche — trades routed through aggregators like 1inch, Paraswap, and CoW Swap with pricing and routing details.

<DexAggregatorTradesSnippet />


# dex.trades on avalanche
Source: https://docs.dune.com/data-catalog/evm/avalanche/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on avalanche.

<DexTradesSnippet />


# NFT Trades on Avalanche
Source: https://docs.dune.com/data-catalog/evm/avalanche/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on Avalanche.

<NFTTradesSnippet />


# Avalanche C-Chain Call Tables
Source: https://docs.dune.com/data-catalog/evm/avalanche/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Avalanche C-Chain network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# avalanche_c.contracts
Source: https://docs.dune.com/data-catalog/evm/avalanche/decoded/contracts

Verified contract registry on Avalanche C-Chain — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs - Avalanche
Source: https://docs.dune.com/data-catalog/evm/avalanche/decoded/event-logs

Smart contracts on Avalanche emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# avalanche_c.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/avalanche/decoded/logs-decoded

ABI-decoded event logs on Avalanche C-Chain — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Avalanche C-Chain Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/avalanche/decoded/overview

Simplifying Avalanche C-Chain smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# avalanche_c.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/avalanche/decoded/traces-decoded

ABI-decoded function calls on Avalanche C-Chain — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Avalanche C-Chain Overview
Source: https://docs.dune.com/data-catalog/evm/avalanche/overview

Avalanche C-Chain data on Dune

Avalanche C-Chain is a Layer 1 blockchain that functions as part of the Avalanche network, offering high throughput and compatibility with the Ethereum Virtual Machine (EVM). This compatibility enables developers to migrate Ethereum dApps to Avalanche with minimal changes, utilizing the same Solidity programming language.

The core innovation of Avalanche C-Chain is its consensus mechanism, which combines classical consensus and Nakamoto consensus techniques to deliver rapid transaction finality and robust security. This design allows the C-Chain to process transactions faster and at lower costs compared to traditional blockchain networks.

\$AVAX is used as the primary utility token on the Avalanche C-Chain for transaction fees. However, the unique aspects of Avalanche's architecture provide enhanced scalability, making it a popular choice for developers seeking efficient and cost-effective blockchain solutions.

Dune provides extensive datasets for Avalanche C-Chain, offering detailed insights into transactions, smart contract interactions, and overall network health.

<CardGroup>
  <Card title="Avalanche C-Chain docs" icon="link" href="https://docs.avax.network">
    The official documentation for Avalanche C-Chain, with detailed guides on its technology, architecture, and developer resources
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Access detailed event logs from smart contracts to analyze contract activity and interactions
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Explore data on blocks processed by the C-Chain, illustrating network throughput and activity
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Transaction details that highlight the efficiency and speed of the Avalanche C-Chain
  </Card>

  <Card title="Decoded" icon="file" href="./decoded/overview">
    Decoded transaction data for easier analysis and deeper understanding of contract executions
  </Card>
</CardGroup>


# avalanche_c.blocks
Source: https://docs.dune.com/data-catalog/evm/avalanche/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Avalanche C-Chain.

<BlockSnippet />


# avalanche_c.creation_traces
Source: https://docs.dune.com/data-catalog/evm/avalanche/raw/creation-traces

Contract deployment records on Avalanche C-Chain — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# avalanche_c.logs
Source: https://docs.dune.com/data-catalog/evm/avalanche/raw/logs

Smart contract event logs on Avalanche C-Chain — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# avalanche_c.traces
Source: https://docs.dune.com/data-catalog/evm/avalanche/raw/traces

Internal transaction traces on Avalanche C-Chain — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# avalanche_c.transactions
Source: https://docs.dune.com/data-catalog/evm/avalanche/raw/transactions

Every transaction on Avalanche C-Chain — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex_aggregator.trades on b3
Source: https://docs.dune.com/data-catalog/evm/b3/curated-data/dex/dex-aggregator-trades

DEX aggregator swaps on B3 — trades routed through aggregators like 1inch, Paraswap, and CoW Swap with pricing and routing details.

<DexAggregatorTradesSnippet />


# dex.trades on b3
Source: https://docs.dune.com/data-catalog/evm/b3/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on b3.

<DexTradesSnippet />


# NFT.trades on b3
Source: https://docs.dune.com/data-catalog/evm/b3/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on b3.

<NFTTradesSnippet />


# B3 Call Tables
Source: https://docs.dune.com/data-catalog/evm/b3/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the B3 network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# b3.contracts
Source: https://docs.dune.com/data-catalog/evm/b3/decoded/contracts

Verified contract registry on B3 — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs - B3
Source: https://docs.dune.com/data-catalog/evm/b3/decoded/event-logs

Smart contracts on B3 emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# b3.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/b3/decoded/logs-decoded

ABI-decoded event logs on B3 — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# B3 Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/b3/decoded/overview

Simplifying B3 smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# b3.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/b3/decoded/traces-decoded

ABI-decoded function calls on B3 — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# B3 Overview
Source: https://docs.dune.com/data-catalog/evm/b3/overview

B3 data on Dune

B3 is a fun-first gaming ecosystem designed to bring the next generation of gamers and game creators onchain. Created by a team of Base/Coinbase alumni and OG Ethereum contributors, B3 provides a seamless gaming experience without the need for wallets, bridging, or switching networks. Players can dive into games instantly—just visit [Basement.fun](https://basement.fun) to experience it yourself.

**Fast, Cheap, and Scalable:**
B3 is a Layer 3 (L3) solution that settles on Base, delivering lightning-fast transactions with sub-cent fees. It is purpose-built for gamers, offering dedicated blockspace that scales to meet the demands of high-throughput games. Whether you're building or playing, B3 ensures a smooth, low-cost experience.

**Onchain is the New Online:**
B3 envisions a future where onchain gaming becomes the new standard for online interactions, empowering game creators and rewarding creativity. B3 allows anyone to play games from anywhere, all while leveraging the security and scalability of Base.

**Scalable Architecture:**
B3's rollup engine offers horizontal scaling through application-layer sharding. By orchestrating dedicated sidecars for games and other computationally heavy operations, B3 can handle web2-scale games while maintaining near gasless transactions.

**Built on Base:**
As a secure, low-cost Layer 2 incubated by Coinbase, Base provides the ideal foundation for B3. Leveraging Base as its settlement layer, B3 is positioned to further scale the Base ecosystem and contribute to its technical and product strategy.

<CardGroup>
  <Card title="B3 documentation" icon="link" href="https://docs.b3.fun/">
    Explore comprehensive documentation of B3, detailing its architecture, protocol, and resources for developers.
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Detailed event logs from smart contracts, providing insights into interactions within the B3 network.
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on blocks, illustrating the operational capacity and activity levels on B3.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Extensive transaction data, showcasing the efficiency and execution of operations on B3.
  </Card>

  <Card title="Decoded" icon="file" href="./decoded/overview">
    Enhanced transaction data decoded for better analysis and understanding of contract executions.
  </Card>
</CardGroup>


# b3.blocks
Source: https://docs.dune.com/data-catalog/evm/b3/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for B3.

<BlockSnippet />


# b3.creation_traces
Source: https://docs.dune.com/data-catalog/evm/b3/raw/creation-traces

Contract deployment records on B3 — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# b3.logs
Source: https://docs.dune.com/data-catalog/evm/b3/raw/logs

Smart contract event logs on B3 — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# b3.traces
Source: https://docs.dune.com/data-catalog/evm/b3/raw/traces

Internal transaction traces on B3 — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# b3.transactions
Source: https://docs.dune.com/data-catalog/evm/b3/raw/transactions

Every transaction on B3 — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex_aggregator.trades on base
Source: https://docs.dune.com/data-catalog/evm/base/curated-data/dex/dex-aggregator-trades

DEX aggregator swaps on Base — trades routed through aggregators like 1inch, Paraswap, and CoW Swap with pricing and routing details.

<DexAggregatorTradesSnippet />


# dex.trades on base
Source: https://docs.dune.com/data-catalog/evm/base/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on base.

<DexTradesSnippet />


# NFT.trades on Base
Source: https://docs.dune.com/data-catalog/evm/base/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on Base.

<NFTTradesSnippet />


# Base Call Tables
Source: https://docs.dune.com/data-catalog/evm/base/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Base network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# base.contracts
Source: https://docs.dune.com/data-catalog/evm/base/decoded/contracts

Verified contract registry on Base — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs - Base
Source: https://docs.dune.com/data-catalog/evm/base/decoded/event-logs

Smart contracts on Base emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# base.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/base/decoded/logs-decoded

ABI-decoded event logs on Base — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Base Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/base/decoded/overview

Simplifying Base smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# base.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/base/decoded/traces-decoded

A description of the base.traces_decoded table on Dune

<TracesDecodedSnippet />


# Base Overview
Source: https://docs.dune.com/data-catalog/evm/base/overview

Base data on Dune

Base is a secure, low-cost, builder-friendly Ethereum Layer 2 solution incubated by Coinbase. It is designed to onboard the next billion users to the blockchain, emphasizing ease of use and accessibility for a global audience. The platform aims for progressive decentralization over the years, underlining its commitment to an open, global cryptoeconomy.

As an Ethereum L2, Base offers the security, stability, and scalability necessary to support your onchain applications. Developers can deploy any EVM-compatible codebase and smoothly transition users and assets from Ethereum L1, Coinbase, and other compatible chains.

**Big Features, Small Fees:**
Base provides an Ethereum Virtual Machine (EVM) environment at significantly lower costs. It introduces early access to new Ethereum features such as Account Abstraction (ERC4337), developer-friendly APIs for gasless transactions, and advanced smart contract wallets.

**Open Source Commitment:**
Built on the MIT-licensed OP Stack in collaboration with Optimism, Base contributes as the second Core Development team to ensure the OP Stack remains a public good accessible to all.

**Scaled by Coinbase:**
Base leverages Coinbase's robust infrastructure to offer decentralized apps enhanced product integration, straightforward fiat onramps, and access to a vast network of millions of verified users within the Coinbase ecosystem.

<CardGroup>
  <Card title="Base documentation" icon="link" href="https://base.org/docs">
    Explore comprehensive documentation on Base, detailing its architecture, protocol, and resources for developers.
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Detailed event logs from smart contracts, providing insights into interactions within the Base network.
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on blocks, illustrating the operational capacity and activity levels on Base.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Extensive transaction data, showcasing the efficiency and execution of operations on Base.
  </Card>

  <Card title="Decoded" icon="file" href="./decoded/overview">
    Enhanced transaction data decoded for better analysis and understanding of contract executions.
  </Card>
</CardGroup>


# base.blocks
Source: https://docs.dune.com/data-catalog/evm/base/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Base.

<BlockSnippet />


# base.creation_traces
Source: https://docs.dune.com/data-catalog/evm/base/raw/creation-traces

Contract deployment records on Base — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# base.logs
Source: https://docs.dune.com/data-catalog/evm/base/raw/logs

Smart contract event logs on Base — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# base.traces
Source: https://docs.dune.com/data-catalog/evm/base/raw/traces

Internal transaction traces on Base — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# base.transactions
Source: https://docs.dune.com/data-catalog/evm/base/raw/transactions

Every transaction on Base — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# beacon.attestations
Source: https://docs.dune.com/data-catalog/evm/beacon/attestations

Beacon chain attestations — validator votes on source, target, and head checkpoints.

## Table Description

The `beacon.attestations` table stores attestation data that is exchanged between validators and users on the Beacon network. This table is partitioned by block\_date.

## Column Descriptions

| **Column**              | **Type**  | **Description**                                                                      |
| ----------------------- | --------- | ------------------------------------------------------------------------------------ |
| **block\_epoch**        | long      | Epoch number when the block containing the attestation was proposed.                 |
| **block\_slot**         | long      | Slot number within the epoch when the block containing the attestation was proposed. |
| **block\_time**         | timestamp | Timestamp when the block containing the attestation was included in the chain.       |
| **block\_date**         | date      | Date corresponding to the block\_time.                                               |
| **signature**           | binary    | BLS signature verifying the attestation's authenticity.                              |
| **aggregation\_bits**   | binary    | Bitlist indicating participating validators in the committee.                        |
| **beacon\_block\_root** | binary    | Root hash of the Beacon Chain block that the attestation votes for.                  |
| **index**               | long      | Committee index at the assigned slot for the attestation.                            |
| **slot**                | long      | Slot number to which the attestation pertains.                                       |
| **source\_epoch**       | long      | Epoch of the last justified checkpoint referred to as the source in the FFG vote.    |
| **source\_root**        | binary    | Root hash of the Beacon Chain block at the source checkpoint epoch.                  |
| **target\_epoch**       | long      | Epoch that the attestation targets in its FFG vote.                                  |
| **target\_root**        | binary    | Root hash of the Beacon Chain block at the target checkpoint epoch.                  |

## Table Sample

<TableSample />


# beacon.attester_slashings
Source: https://docs.dune.com/data-catalog/evm/beacon/attester-slashings

Beacon chain attester slashings — contradictory attestation violations.

## Table Description

The `beacon.attester_slashings` table stores attester slashing data that is exchanged between validators and users on the Beacon network. This table is partitioned by `block_date`.

## Column Descriptions

| **Column**                              | **Type**  | **Description**                                                                               |
| --------------------------------------- | --------- | --------------------------------------------------------------------------------------------- |
| **block\_epoch**                        | long      | Epoch number when the block containing the attester slashing was proposed.                    |
| **block\_slot**                         | long      | Slot number within the epoch when the block containing the attester slashing was proposed.    |
| **block\_time**                         | timestamp | Timestamp when the block containing the attester slashing was included in the chain.          |
| **block\_date**                         | date      | Date corresponding to the block\_time.                                                        |
| **attestation\_1\_attesting\_indices**  | array     | List of validator indices involved in the first conflicting attestation.                      |
| **attestation\_1\_beacon\_block\_root** | binary    | Root hash of the Beacon Chain block that the first attestation votes for.                     |
| **attestation\_1\_index**               | long      | Committee index for the first attestation.                                                    |
| **attestation\_1\_slot**                | long      | Slot number to which the first attestation pertains.                                          |
| **attestation\_1\_source\_epoch**       | long      | Epoch of the last justified checkpoint referred to as the source in the first attestation.    |
| **attestation\_1\_source\_root**        | binary    | Root hash of the Beacon Chain block at the source checkpoint epoch in the first attestation.  |
| **attestation\_1\_target\_epoch**       | long      | Epoch that the first attestation targets in its FFG vote.                                     |
| **attestation\_1\_target\_root**        | binary    | Root hash of the Beacon Chain block at the target checkpoint epoch in the first attestation.  |
| **attestation\_1\_signature**           | binary    | BLS signature associated with the first attestation.                                          |
| **attestation\_2\_attesting\_indices**  | array     | List of validator indices involved in the second conflicting attestation.                     |
| **attestation\_2\_beacon\_block\_root** | binary    | Root hash of the Beacon Chain block that the second attestation votes for.                    |
| **attestation\_2\_index**               | long      | Committee index for the second attestation.                                                   |
| **attestation\_2\_slot**                | long      | Slot number to which the second attestation pertains.                                         |
| **attestation\_2\_source\_epoch**       | long      | Epoch of the last justified checkpoint referred to as the source in the second attestation.   |
| **attestation\_2\_source\_root**        | binary    | Root hash of the Beacon Chain block at the source checkpoint epoch in the second attestation. |
| **attestation\_2\_target\_epoch**       | long      | Epoch that the second attestation targets in its FFG vote.                                    |
| **attestation\_2\_target\_root**        | binary    | Root hash of the Beacon Chain block at the target checkpoint epoch in the second attestation. |
| **attestation\_2\_signature**           | binary    | BLS signature associated with the second attestation.                                         |

## Table Sample

<TableSample />


# beacon.blobs
Source: https://docs.dune.com/data-catalog/evm/beacon/blobs

Beacon chain blob data — EIP-4844 blob sidecar data for rollup data availability.

## Table Description

The `beacon.blobs` table stores blob sidecar data that is exchanged between validators and users on the Beacon network. This table is partitioned by block\_date.

## Column Descriptions

| **Column**                            | **Type**  | **Description**                                                                                 |
| ------------------------------------- | --------- | ----------------------------------------------------------------------------------------------- |
| **block\_epoch**                      | long      | Epoch number when the block containing the blob sidecar was proposed.                           |
| **block\_slot**                       | long      | Slot number within the epoch when the block containing the blob sidecar was proposed.           |
| **block\_time**                       | timestamp | Timestamp when the block containing the blob sidecar was included in the chain.                 |
| **block\_date**                       | date      | Date corresponding to the block\_time.                                                          |
| **index**                             | long      | Index of the blob sidecar within the block.                                                     |
| **proposer\_index**                   | long      | Validator index of the block proposer.                                                          |
| **kzg\_commitment**                   | binary    | KZG commitment for the blob, ensuring data availability and integrity.                          |
| **kzg\_commitment\_inclusion\_proof** | binary    | Proof that the KZG commitment is included in the block, verifying its validity.                 |
| **kzg\_proof**                        | binary    | KZG proof associated with the blob, used for data verification.                                 |
| **body\_root**                        | binary    | Root hash of the block body, representing its contents.                                         |
| **parent\_root**                      | binary    | Root hash of the parent block, linking to the previous block in the chain.                      |
| **state\_root**                       | binary    | Root hash of the state after processing the block, reflecting the system's state.               |
| **signature**                         | binary    | BLS signature of the block proposer, ensuring authenticity.                                     |
| **blob**                              | binary    | The actual blob data associated with the sidecar, containing arbitrary data stored temporarily. |

## Table Sample

<TableSample />


# beacon.blocks
Source: https://docs.dune.com/data-catalog/evm/beacon/blocks

Ethereum beacon chain blocks — slot, proposer, attestation count, and execution payload.

## Table Description

The `beacon.blocks` table stores information about blocks in the Ethereum 2.0 Beacon Chain, including the block proposer, block metadata, and associated blob sidecars.

## Column Descriptions

| **Column**                                  | **Type**  | **Description**                                                                     |
| ------------------------------------------- | --------- | ----------------------------------------------------------------------------------- |
| **epoch**                                   | long      | Epoch number when the block was proposed.                                           |
| **slot**                                    | long      | Slot number within the epoch when the block was proposed.                           |
| **time**                                    | timestamp | Timestamp when the block was included in the chain.                                 |
| **date**                                    | date      | Date corresponding to the time.                                                     |
| **parent\_root**                            | binary    | Root hash of the parent block, linking to the previous block in the chain.          |
| **proposer\_index**                         | long      | Validator index of the block proposer.                                              |
| **state\_root**                             | binary    | Root hash of the state after processing the block, reflecting the system's state.   |
| **execution\_optimistic**                   | boolean   | Indicates if the block is considered optimistic in terms of execution.              |
| **finalized**                               | boolean   | Indicates if the block has been finalized.                                          |
| **version**                                 | string    | Version of the block structure or protocol.                                         |
| **signature**                               | binary    | BLS signature of the block proposer, ensuring authenticity.                         |
| **graffiti**                                | binary    | Arbitrary data included by the proposer, often used for identification or messages. |
| **randao\_reveal**                          | binary    | Revealed RANDAO value used for randomness in validator selection.                   |
| **eth1\_block\_hash**                       | binary    | Hash of the latest Ethereum 1.0 block observed by the proposer.                     |
| **eth1\_deposit\_count**                    | long      | Number of deposits from Ethereum 1.0 included up to this block.                     |
| **eth1\_deposit\_root**                     | binary    | Root hash of the deposit tree containing Ethereum 1.0 deposits.                     |
| **execution\_payload\_timestamp**           | long      | Timestamp of the execution payload within the block.                                |
| **execution\_payload\_base\_fee\_per\_gas** | long      | Base fee per gas for transactions in the execution payload.                         |
| **execution\_payload\_block\_hash**         | binary    | Hash of the execution payload block.                                                |
| **execution\_payload\_block\_number**       | long      | Block number of the execution payload.                                              |
| **execution\_payload\_extra\_data**         | binary    | Extra data field in the execution payload, containing arbitrary data.               |
| **execution\_payload\_fee\_recipient**      | binary    | Address of the fee recipient for transaction fees in the execution payload.         |
| **execution\_payload\_gas\_limit**          | long      | Gas limit for the execution payload block.                                          |
| **execution\_payload\_gas\_used**           | long      | Amount of gas used in the execution payload block.                                  |
| **execution\_payload\_logs\_bloom**         | binary    | Bloom filter for logs in the execution payload, used for quick log searches.        |
| **execution\_payload\_parent\_hash**        | binary    | Hash of the parent execution payload block.                                         |
| **execution\_payload\_prev\_randao**        | binary    | Previous RANDAO value in the execution payload, used for randomness.                |
| **execution\_payload\_receipts\_root**      | binary    | Root hash of the receipts trie for transactions in the execution payload.           |
| **execution\_payload\_state\_root**         | binary    | Root hash of the state trie after applying the execution payload.                   |
| **execution\_payload\_transactions**        | array     | List of transactions included in the execution payload.                             |
| **sync\_committee\_bits**                   | binary    | Bitfield indicating which sync committee members have signed off on the block.      |
| **sync\_committee\_signature**              | binary    | Aggregate signature from the sync committee members for the block.                  |

## Table Sample

<TableSample />


# beacon.bls_to_execution_changes
Source: https://docs.dune.com/data-catalog/evm/beacon/bls-to-execution-changes

Beacon chain BLS-to-execution credential changes — withdrawal address updates.

## Table Description

The `beacon.bls_to_execution_changes` table stores information about changes in the Beacon Chain from BLS to execution, including block metadata and execution payload details.

## Column Descriptions

| **Column**                 | **Type**  | **Description**                                                                                  |
| -------------------------- | --------- | ------------------------------------------------------------------------------------------------ |
| **block\_epoch**           | long      | Epoch number when the block containing the BLS to execution change was proposed.                 |
| **block\_slot**            | long      | Slot number within the epoch when the block containing the BLS to execution change was proposed. |
| **block\_time**            | timestamp | Timestamp when the block containing the BLS to execution change was included in the chain.       |
| **block\_date**            | date      | Date corresponding to the block\_time.                                                           |
| **from\_bls\_pubkey**      | binary    | BLS public key associated with the validator's original withdrawal credentials.                  |
| **to\_execution\_address** | binary    | Execution layer (Eth1) address to which the withdrawal credentials are being updated.            |
| **validator\_index**       | long      | Index of the validator requesting the change.                                                    |
| **signature**              | binary    | BLS signature authorizing the change from BLS to execution withdrawal credentials.               |

## Table Sample

<TableSample />


# beacon.deposits
Source: https://docs.dune.com/data-catalog/evm/beacon/deposits

Beacon chain deposits — ETH staking deposits with validator pubkeys and withdrawal credentials.

## Table Description

The `beacon.deposits` table stores deposit data for validators joining the Beacon network. This table is partitioned by block\_date.

## Column Descriptions

| **Column**                  | **Type**  | **Description**                                                                               |
| --------------------------- | --------- | --------------------------------------------------------------------------------------------- |
| **block\_epoch**            | long      | Epoch number when the block containing the deposit was proposed.                              |
| **block\_slot**             | long      | Slot number within the epoch when the block containing the deposit was proposed.              |
| **block\_time**             | timestamp | Timestamp when the block containing the deposit was included in the chain.                    |
| **block\_date**             | date      | Date corresponding to the block\_time.                                                        |
| **amount**                  | long      | Amount of ETH deposited, specified in Gwei.                                                   |
| **pubkey**                  | binary    | BLS public key of the validator making the deposit.                                           |
| **signature**               | binary    | BLS signature verifying the deposit data.                                                     |
| **withdrawal\_credentials** | binary    | Credentials specifying the withdrawal address or conditions.                                  |
| **proof**                   | binary    | Merkle proof demonstrating the inclusion of the deposit in the Ethereum 1.0 deposit contract. |

## Table Sample

<TableSample />


# beacon.epoch_summaries
Source: https://docs.dune.com/data-catalog/evm/beacon/epoch-summaries

Beacon chain epoch summaries — participation rates, rewards, and finality data per epoch.

## Table Description

The `beacon.epoch_summaries` table is indexed from Lido. Stores summary data for each epoch on the Beacon Chain, including the number of validators, attestations, and other key metrics. This table is partitioned by block\_date.

## Column Descriptions

| **Column**                              | **Type**  | **Description**                                                                |
| --------------------------------------- | --------- | ------------------------------------------------------------------------------ |
| **block\_date**                         | date      | Date corresponding to the epoch.                                               |
| **epoch**                               | bigint    | Epoch number representing a specific period in the Beacon Chain.               |
| **activation\_queue\_length**           | bigint    | Number of validators awaiting activation.                                      |
| **activating\_validators**              | bigint    | Number of validators activated during the epoch.                               |
| **active\_validators**                  | bigint    | Total number of active validators during the epoch.                            |
| **active\_real\_balance**               | bigint    | Total effective balance of active validators, measured in Gwei.                |
| **active\_balance**                     | bigint    | Total balance of active validators, measured in Gwei.                          |
| **attesting\_validators**               | bigint    | Number of validators who submitted attestations during the epoch.              |
| **attesting\_balance**                  | bigint    | Total balance of attesting validators, measured in Gwei.                       |
| **target\_correct\_validators**         | bigint    | Number of validators whose attestations correctly identified the target block. |
| **target\_correct\_balance**            | bigint    | Total balance of target-correct validators, measured in Gwei.                  |
| **head\_correct\_validators**           | bigint    | Number of validators whose attestations correctly identified the head block.   |
| **head\_correct\_balance**              | bigint    | Total balance of head-correct validators, measured in Gwei.                    |
| **attestations\_for\_epoch**            | bigint    | Number of attestations included in the epoch.                                  |
| **attestations\_in\_epoch**             | bigint    | Number of attestations referencing the epoch.                                  |
| **duplicate\_attestations\_for\_epoch** | bigint    | Number of duplicate attestations included in the epoch.                        |
| **proposer\_slashings**                 | bigint    | Number of proposer slashing events during the epoch.                           |
| **attester\_slashings**                 | bigint    | Number of attester slashing events during the epoch.                           |
| **deposits**                            | bigint    | Number of deposits processed during the epoch.                                 |
| **exiting\_validators**                 | bigint    | Number of validators exiting during the epoch.                                 |
| **canonical\_blocks**                   | bigint    | Number of canonical blocks in the epoch.                                       |
| **withdrawals**                         | bigint    | Number of withdrawals processed during the epoch.                              |
| **updated\_at**                         | timestamp | Last time the record was updated.                                              |
| **ingested\_at**                        | timestamp | Time when the record was ingested.                                             |

## Table Sample

<TableSample />


# beacon.operators
Source: https://docs.dune.com/data-catalog/evm/beacon/operators

Beacon chain operators — validator groupings by known staking entity or operator.

## Table Description

The `beacon.operators` table is indexed from Lido. Stores information about staking operators on the Beacon Chain, including their public keys and associated staking modules or services.

## Column Descriptions

| **Column**         | **Type**  | **Description**                                                          |
| ------------------ | --------- | ------------------------------------------------------------------------ |
| **index**          | bigint    | Unique identifier for the operator.                                      |
| **operator\_name** | varchar   | Name of the staking operator.                                            |
| **module\_id**     | bigint    | Identifier linking the operator to a specific staking module or service. |
| **public\_key**    | varbinary | Operator's public key used for cryptographic operations.                 |
| **updated\_at**    | timestamp | Last time the record was updated.                                        |
| **ingested\_at**   | timestamp | Time when the record was ingested.                                       |

## Table Sample

<TableSample />


# Beacon Overview
Source: https://docs.dune.com/data-catalog/evm/beacon/overview

Beacon Chain data on Dune

The Ethereum **Beacon Chain** is the backbone of Ethereum's transition to a Proof-of-Stake (PoS) consensus mechanism. Launched on December 1, 2020, it introduced PoS to the Ethereum ecosystem, enhancing security, scalability, and energy efficiency.

**Key Features:**

* **Proof-of-Stake Consensus:** The Beacon Chain manages a registry of validators who propose and attest to new blocks, replacing the energy-intensive Proof-of-Work system.

* **Validator Coordination:** It coordinates validators, ensuring the network's security and proper functioning by assigning responsibilities and managing rewards and penalties.

* **Foundation for Sharding:** The Beacon Chain lays the groundwork for future scalability improvements, such as sharding, which will enable the network to process more transactions concurrently.

**Data Catalog**

Explore the following datasets to gain insights into the Beacon Chain's operations:

<CardGroup>
  <Card title="Attestations" href="./attestations">
    Records of validator attestations, which are votes for a specific block, contributing to consensus and chain finality.
  </Card>

  <Card title="Attester Slashings" href="./attester-slashings">
    Details of penalties imposed on validators who have violated protocol rules by signing conflicting attestations.
  </Card>

  <Card title="Blob Sidecars" href="./blobs">
    Data related to blob sidecars, which are auxiliary data structures associated with blocks.
  </Card>

  <Card title="Blocks" href="./blocks">
    Information on Beacon Chain blocks, including proposer details, parent roots, and state roots.
  </Card>

  <Card title="BLS to Execution Changes" href="./bls-to-execution-changes">
    Records of changes from BLS public keys to execution addresses, facilitating validator withdrawals.
  </Card>

  <Card title="Deposits" href="./deposits">
    Details of ETH deposits made by validators to join the Beacon Chain and participate in staking.
  </Card>

  <Card title="Epoch Summaries" href="./epoch-summaries">
    Summarized data for each epoch, providing insights into validator performance and network health.
  </Card>

  <Card title="Operators" href="./operators">
    Information about staking operators managing validator nodes on the Beacon Chain.
  </Card>

  <Card title="Proposer Slashings" href="./proposer-slashings">
    Details of penalties imposed on validators who have proposed conflicting blocks.
  </Card>

  <Card title="Validator Day Summaries" href="./validator-day-summaries">
    Daily summaries of validator activities, balances, and performance metrics.
  </Card>

  <Card title="Voluntary Exits" href="./voluntary-exits">
    Records of validators voluntarily exiting the active set, ceasing their participation in consensus duties.
  </Card>

  <Card title="Withdrawals" href="./withdrawals">
    Information on ETH withdrawals by validators from the Beacon Chain to the execution layer.
  </Card>
</CardGroup>

These datasets provide a comprehensive view of the Beacon Chain's functionality, validator activities, and the overall health of Ethereum's PoS consensus layer.


# beacon.proposer_slashings
Source: https://docs.dune.com/data-catalog/evm/beacon/proposer-slashings

Beacon chain proposer slashings — double-proposal violations and penalized validators.

## Table Description

The `beacon.proposer_slashings` table stores information about proposer slashings on the Beacon Chain. A proposer slashing occurs when a validator proposes two conflicting blocks at the same slot. This table contains information about the conflicting blocks and the proposer responsible for the slashing.

| **Column**                             | **Type**  | **Description**                                                                            |
| -------------------------------------- | --------- | ------------------------------------------------------------------------------------------ |
| **block\_epoch**                       | long      | Epoch number when the block containing the proposer slashing was proposed.                 |
| **block\_slot**                        | long      | Slot number within the epoch when the block containing the proposer slashing was proposed. |
| **block\_time**                        | timestamp | Timestamp when the block containing the proposer slashing was included in the chain.       |
| **block\_date**                        | date      | Date corresponding to the block\_time.                                                     |
| **signed\_header\_1\_body\_root**      | binary    | Root hash of the body of the first conflicting block header.                               |
| **signed\_header\_1\_parent\_root**    | binary    | Root hash of the parent block referenced by the first conflicting block header.            |
| **signed\_header\_1\_proposer\_index** | long      | Validator index of the proposer for the first conflicting block.                           |
| **signed\_header\_1\_slot**            | long      | Slot number for which the first conflicting block was proposed.                            |
| **signed\_header\_1\_state\_root**     | binary    | Root hash of the state after processing the first conflicting block.                       |
| **signed\_header\_1\_signature**       | binary    | BLS signature of the proposer for the first conflicting block.                             |
| **signed\_header\_2\_body\_root**      | binary    | Root hash of the body of the second conflicting block header.                              |
| **signed\_header\_2\_parent\_root**    | binary    | Root hash of the parent block referenced by the second conflicting block header.           |
| **signed\_header\_2\_proposer\_index** | long      | Validator index of the proposer for the second conflicting block.                          |
| **signed\_header\_2\_slot**            | long      | Slot number for which the second conflicting block was proposed.                           |
| **signed\_header\_2\_state\_root**     | binary    | Root hash of the state after processing the second conflicting block.                      |
| **signed\_header\_2\_signature**       | binary    | BLS signature of the proposer for the second conflicting block.                            |

## Table Sample

<TableSample />


# beacon.raw
Source: https://docs.dune.com/data-catalog/evm/beacon/raw

Raw beacon chain data — unprocessed consensus layer records.

## Table Description

The `beacon.raw` table stores raw data about blocks proposed on the Beacon network. This table is partitioned by block\_date.

## Column Descriptions

| **Column**      | **Type**  | **Description**                                                |
| --------------- | --------- | -------------------------------------------------------------- |
| **epoch**       | long      | Epoch number during which the block was proposed.              |
| **block\_slot** | long      | Slot number within the epoch when the block was proposed.      |
| **block\_time** | timestamp | Timestamp indicating when the block was included in the chain. |
| **block\_date** | date      | Date corresponding to the block\_time.                         |

## Table Sample

<TableSample />


# beacon.validator_day_summaries
Source: https://docs.dune.com/data-catalog/evm/beacon/validator-day-summaries

Daily beacon chain validator summaries — rewards, penalties, and attestation performance.

## Table Description

The `beacon.validator_day_summaries` table is indexed from Lido. Stores daily summaries of validator activity on the Beacon Chain, including balance changes, rewards, attestations, and sync committee messages.

## Column Descriptions

| **Column**                              | **Type**  | **Description**                                                                                                |
| --------------------------------------- | --------- | -------------------------------------------------------------------------------------------------------------- |
| **block\_date**                         | date      | Date corresponding to the summary period.                                                                      |
| **validator\_index**                    | bigint    | Unique identifier for the validator.                                                                           |
| **start\_timestamp**                    | timestamp | Timestamp marking the beginning of the summary period.                                                         |
| **start\_balance**                      | bigint    | Validator's balance at the start of the period, measured in Gwei.                                              |
| **start\_effective\_balance**           | bigint    | Validator's effective balance at the start of the period, used for reward calculations, measured in Gwei.      |
| **capital\_change**                     | bigint    | Net change in the validator's balance due to deposits or withdrawals during the period, measured in Gwei.      |
| **reward\_change**                      | bigint    | Net rewards earned by the validator during the period, measured in Gwei.                                       |
| **effective\_balance\_change**          | bigint    | Change in the validator's effective balance during the period, measured in Gwei.                               |
| **proposals**                           | bigint    | Number of block proposals assigned to the validator during the period.                                         |
| **proposals\_included**                 | bigint    | Number of the validator's proposed blocks that were included in the chain during the period.                   |
| **attestations**                        | bigint    | Number of attestations made by the validator during the period.                                                |
| **attestations\_included**              | bigint    | Number of the validator's attestations that were included in the chain during the period.                      |
| **attestations\_source\_timely**        | bigint    | Number of the validator's attestations that were timely for the source checkpoint during the period.           |
| **attestations\_target\_correct**       | bigint    | Number of the validator's attestations that correctly identified the target checkpoint during the period.      |
| **attestations\_target\_timely**        | bigint    | Number of the validator's attestations that were timely for the target checkpoint during the period.           |
| **attestations\_head\_correct**         | bigint    | Number of the validator's attestations that correctly identified the head block during the period.             |
| **attestations\_head\_timely**          | bigint    | Number of the validator's attestations that were timely for the head block during the period.                  |
| **attestations\_inclusion\_delay**      | double    | Average delay (in slots) between the validator's attestation and its inclusion in the chain during the period. |
| **sync\_committee\_messages**           | bigint    | Number of sync committee messages signed by the validator during the period.                                   |
| **sync\_committee\_messages\_included** | bigint    | Number of the validator's sync committee messages that were included in the chain during the period.           |
| **withdrawals**                         | bigint    | Number of withdrawals made by the validator during the period.                                                 |
| **updated\_at**                         | timestamp | Last time the record was updated.                                                                              |
| **ingested\_at**                        | timestamp | Time when the record was ingested                                                                              |

## Table Sample

<TableSample />


# beacon.validators
Source: https://docs.dune.com/data-catalog/evm/beacon/validators

Beacon chain validator registry — pubkey, status, balance, and activation/exit epochs.

## Table Description

The `beacon.validators` table stores data about validators on the Beacon network. This table is partitioned by block\_date.

## Column Descriptions

| **Column**                         | **Type**  | **Description**                                                                                          |
| ---------------------------------- | --------- | -------------------------------------------------------------------------------------------------------- |
| **index**                          | bigint    | Unique identifier assigned to the validator upon registration.                                           |
| **slashed**                        | boolean   | Indicates whether the validator has been slashed for misbehavior (`true` if slashed, `false` otherwise). |
| **public\_key**                    | varbinary | Validator's BLS public key used for signing messages.                                                    |
| **activation\_eligibility\_epoch** | bigint    | Epoch when the validator became eligible for activation after meeting the minimum balance requirement.   |
| **activation\_epoch**              | bigint    | Epoch when the validator was activated and began participating in the consensus process.                 |
| **exit\_epoch**                    | bigint    | Epoch when the validator exited the active validator set.                                                |
| **withdrawable\_epoch**            | bigint    | Epoch when the validator's funds become withdrawable after exiting.                                      |
| **effective\_balance**             | bigint    | Validator's balance used for reward calculations, capped at a maximum value, measured in Gwei.           |
| **withdrawal\_credentials**        | varbinary | Credentials used to specify the destination for withdrawn funds.                                         |
| **updated\_at**                    | timestamp | Last time the record was updated                                                                         |
| **ingested\_at**                   | timestamp | Time when the record was ingested                                                                        |

## Table Sample

<TableSample />


# beacon.voluntary_exits
Source: https://docs.dune.com/data-catalog/evm/beacon/voluntary-exits

Beacon chain voluntary exits — validators initiating the exit process.

## Table Description

The `beacon.voluntary_exits` table stores data about voluntary exits initiated by validators on the Beacon network. This table is partitioned by block\_date.

## Column Descriptions

| **Column**           | **Type**  | **Description**                                                                         |
| -------------------- | --------- | --------------------------------------------------------------------------------------- |
| **block\_epoch**     | long      | Epoch number when the block containing the voluntary exit was proposed.                 |
| **block\_slot**      | long      | Slot number within the epoch when the block containing the voluntary exit was proposed. |
| **block\_time**      | timestamp | Timestamp when the block containing the voluntary exit was included in the chain.       |
| **block\_date**      | date      | Date corresponding to the block\_time.                                                  |
| **validator\_index** | long      | Unique identifier of the validator initiating the voluntary exit.                       |
| **signature**        | binary    | BLS signature authorizing the voluntary exit, ensuring its authenticity.                |

## Table Sample

<TableSample />


# beacon.withdrawals
Source: https://docs.dune.com/data-catalog/evm/beacon/withdrawals

Beacon chain withdrawals — validator ETH withdrawals with amounts and recipient addresses.

## Table Description

The `beacon.withdrawals` table stores data about withdrawals initiated by validators on the Beacon network. This table is partitioned by block\_date.

## Column Descriptions

| **Column**           | **Type**  | **Description**                                                                     |
| -------------------- | --------- | ----------------------------------------------------------------------------------- |
| **block\_epoch**     | long      | Epoch number when the block containing the withdrawal was proposed.                 |
| **block\_slot**      | long      | Slot number within the epoch when the block containing the withdrawal was proposed. |
| **block\_time**      | timestamp | Timestamp when the block containing the withdrawal was included in the chain.       |
| **block\_date**      | date      | Date corresponding to the block\_time.                                              |
| **address**          | binary    | Execution layer (ETH1) address receiving the withdrawn ETH.                         |
| **amount**           | long      | Amount of ETH withdrawn, specified in Gwei.                                         |
| **index**            | long      | Unique identifier for the withdrawal operation.                                     |
| **validator\_index** | long      | Index of the validator initiating the withdrawal.                                   |

## Table Sample

<TableSample />


# dex_aggregator.trades on berachain
Source: https://docs.dune.com/data-catalog/evm/berachain/curated-data/dex/dex-aggregator-trades

DEX aggregator swaps on Berachain — trades routed through aggregators like 1inch, Paraswap, and CoW Swap with pricing and routing details.

<DexAggregatorTradesSnippet />


# dex.trades on berachain
Source: https://docs.dune.com/data-catalog/evm/berachain/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on berachain.

<DexTradesSnippet />


# NFT.trades on berachain
Source: https://docs.dune.com/data-catalog/evm/berachain/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on berachain.

<NFTTradesSnippet />


# Berachain Call Tables
Source: https://docs.dune.com/data-catalog/evm/berachain/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Berachain network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# berachain.contracts
Source: https://docs.dune.com/data-catalog/evm/berachain/decoded/contracts

Verified contract registry on Berachain — contract name, namespace, ABI, and deployment metadata.

## Table Description

The `berachain.contracts` table contains information about the contracts Dune has decoded on the Berachain blockchain.

## Column Descriptions

| Column             | Type             | Description                                           |
| ------------------ | ---------------- | ----------------------------------------------------- |
| `abi_id`           | `varchar`        | Unique identifier for the ABI                         |
| `abi`              | `array(varchar)` | Contract ABI (Application Binary Interface)           |
| `address`          | `varbinary`      | Contract address                                      |
| `from`             | `varbinary`      | Address that deployed the contract                    |
| `code`             | `varbinary`      | Deployed bytecode of the contract                     |
| `name`             | `varchar`        | Name of the contract                                  |
| `namespace`        | `varchar`        | Project namespace (e.g., uniswap\_v3)                 |
| `dynamic`          | `boolean`        | Whether the contract was dynamically detected         |
| `base`             | `boolean`        | Whether this is the base contract submission          |
| `factory`          | `boolean`        | Whether this contract is a factory contract           |
| `detection_source` | `varchar`        | How the contract was detected (manual, factory, etc.) |
| `created_at`       | `timestamp`      | When this record was created in Dune                  |

## Table Sample

<TableSample />


# Event Logs - Berachain
Source: https://docs.dune.com/data-catalog/evm/berachain/decoded/event-logs

Smart contracts on Berachain emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# berachain.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/berachain/decoded/logs-decoded

ABI-decoded event logs on Berachain — human-readable event names and parsed parameters from verified contracts.

## Table Description

The `logs_decoded` table contains decoded logs from Berachain transactions. The table matches `topic0` to the event signature and the corresponding event name. The table does not contain the full event data and is not suitable for analysis of smart contract level data. For that, use the specific event tables as described in [Event Logs](/data-catalog/evm/berachain/decoded/event-logs).

The `berachain.logs_decoded` table is great for gaining a high-level understanding of the types of events that are being emitted by a smart contract or smart contracts of a certain protocol.

## Column Descriptions

| Column             | Type        | Description                                    |
| ------------------ | ----------- | ---------------------------------------------- |
| `block_date`       | `date`      | Date of the block (UTC)                        |
| `block_time`       | `timestamp` | Timestamp of the block containing this log     |
| `block_number`     | `bigint`    | Block number containing this log               |
| `namespace`        | `varchar`   | Project namespace (e.g., uniswap\_v3)          |
| `contract_name`    | `varchar`   | Name of the contract that emitted the event    |
| `contract_address` | `varbinary` | Address of the contract that emitted the event |
| `tx_hash`          | `varbinary` | Hash of the transaction containing this log    |
| `tx_from`          | `varbinary` | Address that initiated the transaction         |
| `tx_to`            | `varbinary` | Address the transaction was sent to            |
| `tx_index`         | `integer`   | Position of the transaction within the block   |
| `index`            | `integer`   | Position of the log within the block           |
| `signature`        | `varbinary` | Event signature hash (topic0)                  |
| `event_name`       | `varchar`   | Decoded name of the event                      |
| `created_at`       | `timestamp` | When this record was created in Dune           |

## Table Sample

<TableSample />


# Berachain Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/berachain/decoded/overview

Simplifying Berachain smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# berachain.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/berachain/decoded/traces-decoded

ABI-decoded function calls on Berachain — parsed function names, inputs, and outputs from verified contracts.

## Table Description

The `traces_decoded` table contains decoded traces from Berachain transactions. The table matches `MethodID`, which consists of the first 4 bytes of any eth call to the trace signature and the corresponding Method name. The table does not contain the full trace data and is not suitable for analysis of smart contract level data. For that, use the specific event tables as described in [Call-tables](/data-catalog/evm/berachain/decoded/call-tables).

The `berachain.traces_decoded` table is great for gaining a high level understanding of the types of events that are being emitted by a smart contract or smart contracts of a certain protocol.

## Column Descriptions

| Column          | Type            | Description                                    |
| --------------- | --------------- | ---------------------------------------------- |
| `block_date`    | `date`          | Date of the block (UTC)                        |
| `block_time`    | `timestamp`     | Timestamp of the block containing this trace   |
| `block_number`  | `bigint`        | Block number containing this trace             |
| `namespace`     | `varchar`       | Project namespace (e.g., uniswap\_v3)          |
| `contract_name` | `varchar`       | Name of the contract that was called           |
| `to`            | `varbinary`     | Address of the contract that was called        |
| `trace_address` | `array(bigint)` | Path of this trace within the call tree        |
| `tx_hash`       | `varbinary`     | Hash of the parent transaction                 |
| `tx_from`       | `varbinary`     | Address that initiated the transaction         |
| `tx_to`         | `varbinary`     | Address the transaction was sent to            |
| `tx_index`      | `integer`       | Position of the transaction within the block   |
| `success`       | `boolean`       | Whether this trace executed successfully       |
| `signature`     | `varbinary`     | Function signature (first 4 bytes of calldata) |
| `function_name` | `varchar`       | Decoded name of the function called            |
| `created_at`    | `timestamp`     | When this record was created in Dune           |

## Table Sample

<TableSample />


# Berachain Overview
Source: https://docs.dune.com/data-catalog/evm/berachain/overview

Berachain data on Dune

Berachain is a high-performance EVM-Identical Layer 1 blockchain utilizing Proof-of-Liquidity (PoL), and built on top of the modular EVM-focused consensus client framework BeaconKit. It combines the security and decentralization of traditional blockchains with innovative tokenomics and liquidity mechanisms.

**EVM Identical Architecture:**
Berachain's execution layer is identical to the Ethereum Virtual Machine (EVM) runtime environment seen on Ethereum Mainnet. This means it uses existing unmodified execution clients like Geth, Reth, Erigon, Nethermind, and more to handle executing smart contracts, and supports all the tooling that comes native with the EVM.

**Proof-of-Liquidity (PoL):**
Berachain introduces a novel consensus mechanism that radically changes L1 economics, prioritizing users and applications over validator rewards. Network incentives go towards enriching ecosystem liquidity, contributing to:

* Efficient trading
* Price stability
* Chain security
* Network/user growth

**BeaconKit Framework:**
Built on BeaconKit, a modular framework for building EVM consensus clients, Berachain integrates the benefits of CometBFT consensus, including increased composability and single slot finality (SSF).

<CardGroup>
  <Card title="Berachain documentation" icon="link" href="https://docs.berachain.com/learn/">
    Access the official documentation for Berachain, providing comprehensive information about its architecture, features, and development resources.
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Event logs from smart contracts, providing insights into interactions and activities on the Berachain network.
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on blocks processed using Berachain's PoL technology, reflecting the network's capacity for high transaction throughput.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Detailed transaction data, showcasing the operational efficiency and cost-effectiveness of Berachain's solution.
  </Card>

  <Card title="decoded" icon="file" href="./decoded/overview">
    Decoded transaction data for easier analysis and better understanding of smart contract executions on Berachain.
  </Card>
</CardGroup>


# berachain.blocks
Source: https://docs.dune.com/data-catalog/evm/berachain/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Berachain.

## Table Description

The `berachain.blocks` table contains information about blocks in the Berachain blockchain. Each block contains a collection of transactions that are hashed and added to the blockchain. Berachain uses CometBFT consensus through BeaconKit, providing single slot finality (SSF) for faster and more secure block confirmations.

## Column Descriptions

| Column                     | Type        | Description                                         |
| -------------------------- | ----------- | --------------------------------------------------- |
| `time`                     | `timestamp` | The time when the block was mined                   |
| `number`                   | `bigint`    | The block number (height)                           |
| `gas_limit`                | `decimal`   | Maximum gas allowed in the block                    |
| `gas_used`                 | `decimal`   | Total gas used by all transactions in the block     |
| `difficulty`               | `bigint`    | Mining difficulty of the block                      |
| `total_difficulty`         | `decimal`   | Cumulative difficulty of the chain up to this block |
| `size`                     | `bigint`    | Size of the block in bytes                          |
| `base_fee_per_gas`         | `bigint`    | Base fee per gas unit (EIP-1559)                    |
| `hash`                     | `varbinary` | Hash of the block                                   |
| `parent_hash`              | `varbinary` | Hash of the parent block                            |
| `miner`                    | `varbinary` | Address of the miner/validator                      |
| `nonce`                    | `varbinary` | Nonce used in mining the block                      |
| `date`                     | `date`      | Date of the block (UTC)                             |
| `blob_gas_used`            | `bigint`    | Total blob gas used in the block (EIP-4844)         |
| `excess_blob_gas`          | `bigint`    | Excess blob gas for fee calculation (EIP-4844)      |
| `parent_beacon_block_root` | `varbinary` | Root of the parent beacon block                     |

## Table Sample

<TableSample />


# berachain.creation_traces
Source: https://docs.dune.com/data-catalog/evm/berachain/raw/creation-traces

Contract deployment records on Berachain — deployer address, factory context, and deployed bytecode.

## Table Description

The `creation_traces` table contains information about the creation of smart contracts on the Berachain blockchain. This includes the address of the contract, the address of the creator, the block number at which the contract was created, the transaction hash, and the contract's bytecode. This table is useful for understanding the deployment of smart contracts on the Berachain blockchain.

The `berachain.creation_traces` table is a subset of the `traces` table, which contains information about all traces on the Berachain blockchain. The `creation_traces` table is filtered to only include traces that create new smart contracts. The filter for this is `type` = `create`.

## Column Descriptions

| Column         | Type        | Description                                           |
| -------------- | ----------- | ----------------------------------------------------- |
| `block_time`   | `timestamp` | Timestamp of the block containing this creation trace |
| `block_number` | `bigint`    | Block number containing this creation trace           |
| `tx_hash`      | `varbinary` | Hash of the transaction that created the contract     |
| `address`      | `varbinary` | Address of the newly created contract                 |
| `from`         | `varbinary` | Address that deployed the contract                    |
| `code`         | `varbinary` | Bytecode of the deployed contract                     |
| `block_month`  | `date`      | Month of the block (for partitioning)                 |

## Table Sample

<TableSample />


# berachain.logs
Source: https://docs.dune.com/data-catalog/evm/berachain/raw/logs

Smart contract event logs on Berachain — indexed topics and data fields from token transfers, swaps, and protocol actions.

## Table Description

The `berachain.logs` table represents the logs generated by the Ethereum Virtual Machine (EVM) when a contract is executed on Berachain. As an EVM-identical chain, Berachain maintains complete compatibility with Ethereum's logging system while benefiting from its unique PoL consensus mechanism. Logs consist of:

* Topic list: a list of 0 to 4 32-byte data topics
* data: contains non-indexed data

## Column Descriptions

| Column             | Type        | Description                                     |
| ------------------ | ----------- | ----------------------------------------------- |
| `block_time`       | `timestamp` | Timestamp of the block containing this log      |
| `block_number`     | `bigint`    | Block number containing this log                |
| `block_hash`       | `varbinary` | Hash of the block containing this log           |
| `contract_address` | `varbinary` | Address of the contract that emitted the log    |
| `topic0`           | `varbinary` | Event signature hash (first indexed topic)      |
| `topic1`           | `varbinary` | First indexed event parameter                   |
| `topic2`           | `varbinary` | Second indexed event parameter                  |
| `topic3`           | `varbinary` | Third indexed event parameter                   |
| `data`             | `varbinary` | Non-indexed event data                          |
| `tx_hash`          | `varbinary` | Hash of the transaction that generated this log |
| `index`            | `integer`   | Position of the log within the block            |
| `tx_index`         | `integer`   | Position of the transaction within the block    |
| `block_date`       | `date`      | Date of the block (UTC)                         |
| `tx_from`          | `varbinary` | Address that initiated the transaction          |
| `tx_to`            | `varbinary` | Address the transaction was sent to             |
| `blob_gas_price`   | `bigint`    | Blob gas price of the transaction (EIP-4844)    |
| `blob_gas_used`    | `bigint`    | Blob gas used by the transaction (EIP-4844)     |

## Table Sample

<TableSample />


# berachain.traces
Source: https://docs.dune.com/data-catalog/evm/berachain/raw/traces

Internal transaction traces on Berachain — cross-contract calls, delegate calls, and value transfers with full call stack context.

## Table Description

The `berachain.traces` table contains the traces of transactions executed on the Ethereum Virtual Machine (EVM). It includes traces of both top-level and internal transactions. Traces are the result of transaction execution and are used to debug and understand how transactions are processed. They are also known as `internal transactions`.

This is the raw version of this table, for decoded transaction calls, see the [call tables](/data-catalog/evm/berachain/decoded/call-tables) section.

## Column Descriptions

| Column           | Type            | Description                                         |
| ---------------- | --------------- | --------------------------------------------------- |
| `block_time`     | `timestamp`     | Timestamp of the block containing this trace        |
| `block_number`   | `bigint`        | Block number containing this trace                  |
| `value`          | `uint256`       | Amount of native token transferred (in wei)         |
| `gas`            | `bigint`        | Gas provided for this trace                         |
| `gas_used`       | `bigint`        | Gas consumed by this trace                          |
| `block_hash`     | `varbinary`     | Hash of the block containing this trace             |
| `success`        | `boolean`       | Whether this trace executed successfully            |
| `tx_index`       | `integer`       | Position of the transaction within the block        |
| `sub_traces`     | `bigint`        | Number of child traces spawned by this trace        |
| `error`          | `varchar`       | Error message if the trace failed                   |
| `tx_success`     | `boolean`       | Whether the parent transaction succeeded            |
| `tx_hash`        | `varbinary`     | Hash of the parent transaction                      |
| `from`           | `varbinary`     | Address that initiated this trace                   |
| `to`             | `varbinary`     | Address the trace was sent to                       |
| `trace_address`  | `array(bigint)` | Path of this trace within the call tree             |
| `type`           | `varchar`       | Type of trace (call, create, suicide, reward)       |
| `address`        | `varbinary`     | Address of the contract created (for create traces) |
| `code`           | `varbinary`     | Bytecode of the contract created                    |
| `call_type`      | `varchar`       | Type of call (call, delegatecall, staticcall)       |
| `input`          | `varbinary`     | Input data for the trace                            |
| `output`         | `varbinary`     | Output data from the trace                          |
| `refund_address` | `varbinary`     | Address receiving refund (for selfdestruct)         |
| `block_date`     | `date`          | Date of the block (UTC)                             |

## Table Sample

<TableSample />


# berachain.transactions
Source: https://docs.dune.com/data-catalog/evm/berachain/raw/transactions

Every transaction on Berachain — from, to, value, gas, calldata, and receipt status.

## Table Description

The `berachain.transactions` table contains information about all transactions on the Berachain blockchain. Each row represents a single transaction and includes information such as block number, hash, timestamp, sender, recipient, value, gas, and gas price. Berachain's EVM-identical architecture ensures full compatibility with Ethereum tooling while leveraging its Proof-of-Liquidity (PoL) mechanism for enhanced efficiency.

## Column Descriptions

| Column                     | Type               | Description                                             |
| -------------------------- | ------------------ | ------------------------------------------------------- |
| `block_time`               | `timestamp`        | Timestamp of the block containing this transaction      |
| `block_number`             | `bigint`           | Block number containing this transaction                |
| `value`                    | `decimal`          | Amount of native token transferred (in wei)             |
| `gas_limit`                | `bigint`           | Maximum gas the sender is willing to use                |
| `gas_price`                | `bigint`           | Price per gas unit (in wei)                             |
| `gas_used`                 | `bigint`           | Actual gas consumed by the transaction                  |
| `max_fee_per_gas`          | `bigint`           | Maximum total fee per gas (EIP-1559)                    |
| `max_priority_fee_per_gas` | `bigint`           | Maximum priority fee (tip) per gas (EIP-1559)           |
| `priority_fee_per_gas`     | `bigint`           | Actual priority fee per gas paid                        |
| `nonce`                    | `bigint`           | Transaction count of the sender before this transaction |
| `index`                    | `bigint`           | Position of the transaction within the block            |
| `success`                  | `boolean`          | Whether the transaction executed successfully           |
| `from`                     | `varbinary`        | Address of the transaction sender                       |
| `to`                       | `varbinary`        | Address of the transaction recipient                    |
| `block_hash`               | `varbinary`        | Hash of the block containing this transaction           |
| `data`                     | `varbinary`        | Calldata sent with the transaction                      |
| `hash`                     | `varbinary`        | Unique hash of the transaction                          |
| `type`                     | `varchar`          | Transaction type (legacy, EIP-2930, EIP-1559, EIP-4844) |
| `access_list`              | `array(row)`       | List of addresses and storage keys accessed (EIP-2930)  |
| `block_date`               | `date`             | Date of the block (UTC)                                 |
| `blob_versioned_hashes`    | `array(varbinary)` | Versioned hashes of blobs (EIP-4844)                    |
| `max_fee_per_blob_gas`     | `bigint`           | Maximum fee per blob gas (EIP-4844)                     |
| `authorization_list`       | `array(row)`       | Authorization list for EIP-7702 transactions            |

## Table Sample

<TableSample />


# dex_aggregator.trades on blast
Source: https://docs.dune.com/data-catalog/evm/blast/curated-data/dex/dex-aggregator-trades

DEX aggregator swaps on Blast — trades routed through aggregators like 1inch, Paraswap, and CoW Swap with pricing and routing details.

<DexAggregatorTradesSnippet />


# dex.trades on Blast
Source: https://docs.dune.com/data-catalog/evm/blast/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on Blast.

<DexTradesSnippet />


# NFT.trades on Blast
Source: https://docs.dune.com/data-catalog/evm/blast/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on Blast.

<NFTTradesSnippet />


# Blast Call Tables
Source: https://docs.dune.com/data-catalog/evm/blast/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Blast network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# blast.contracts
Source: https://docs.dune.com/data-catalog/evm/blast/decoded/contracts

Verified contract registry on Blast — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs - Blast
Source: https://docs.dune.com/data-catalog/evm/blast/decoded/event-logs

Smart contracts on Blast emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# blast.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/blast/decoded/logs-decoded

ABI-decoded event logs on Blast — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Blast Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/blast/decoded/overview

Simplifying Blast smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# blast.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/blast/decoded/traces-decoded

ABI-decoded function calls on Blast — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Blast Overview
Source: https://docs.dune.com/data-catalog/evm/blast/overview

Blast data on Dune Analytics

<Warning>
  Starting from the 26th of September 2025 Dune is not live ingesting and indexing Blast data. The historical data of the chain will remain available to be used.
</Warning>

Blast is an Ethereum Layer 2 (L2) that natively provides yield for ETH and stablecoins. Blast is an EVM-compatible, optimistic rollup that raises the baseline yield for users and developers without changing the experience cryptonatives expect. This yield makes it possible to create new business models for Dapps that aren't possible on other L2s.

### Key Features:

* **Yield:** Blast is the only Ethereum L2 with native yield for ETH and stablecoins. The yield comes from ETH staking and RWA protocols. The default interest rate on other L2s is 0%. On Blast, it's 4% for ETH and 5% for stablecoins.

* **Auto Rebasing:** ETH itself, not WETH, STETH, or any other ERC20, is natively rebasing on the L2. The ETH balance for EOAs is automatically rebasing. Smart contracts can opt-in to this rebasing, making it easy for existing Dapps to deploy on Blast without any changes. USDB, Blast's native stablecoin, is automatically rebasing as well. Like ETH on Blast, USDB is automatically rebasing for EOAs. USDB is also automatically rebasing for smart contracts. Smart contracts can opt-out from this rebasing.

* **L1 Staking:** Blast only became possible following Ethereum's Shanghai upgrade. ETH yield from L1 staking, initially Lido, is automatically transferred to users via rebasing ETH on the L2. In the future, the Blast community will have the power to supplement, or even fully replace, Lido with Blast-native solutions or other third-party protocols.

* **T-Bill Yield:** Users who bridge stablecoins receive USDB, Blast's auto-rebasing stablecoin. The yield for USDB comes from MakerDAO's on-chain T-Bill protocol. USDB can be redeemed for DAI when bridging back to Ethereum. In the future, the Blast community will have the power to supplement, or even fully replace, MakerDAO with Blast-native solutions or other third-party protocols.

* **Gas Revenue Sharing:** Other L2s keep revenue from gas fees for themselves. Blast gives net gas revenue back to dApps programmatically. dApps developers can keep this revenue for themselves or use it to subsidize gas fees for users.

<CardGroup>
  <Card title="Blast documentation" icon="link" href="https://docs.blast.io/">
    Explore comprehensive documentation on Blast, detailing its architecture, protocol, and resources for developers.
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Detailed event logs from smart contracts, providing insights into interactions within the Blast network.
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on blocks, illustrating the operational capacity and activity levels on Blast.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Extensive transaction data, showcasing the efficiency and execution of operations on Blast.
  </Card>

  <Card title="Decoded" icon="file" href="./decoded/overview">
    Enhanced transaction data decoded for better analysis and understanding of contract executions.
  </Card>
</CardGroup>


# blast.blocks
Source: https://docs.dune.com/data-catalog/evm/blast/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Blast.

<BlockSnippet />


# blast.creation_traces
Source: https://docs.dune.com/data-catalog/evm/blast/raw/creation-traces

Contract deployment records on Blast — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# blast.logs
Source: https://docs.dune.com/data-catalog/evm/blast/raw/logs

Smart contract event logs on Blast — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# blast.traces
Source: https://docs.dune.com/data-catalog/evm/blast/raw/traces

Internal transaction traces on Blast — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# blast.transactions
Source: https://docs.dune.com/data-catalog/evm/blast/raw/transactions

Every transaction on Blast — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex_aggregator.trades on bnb
Source: https://docs.dune.com/data-catalog/evm/bnb/curated-data/dex/dex-aggregator-trades

DEX aggregator swaps on BNB Chain — trades routed through aggregators like 1inch, Paraswap, and CoW Swap with pricing and routing details.

<DexAggregatorTradesSnippet />


# dex.trades on bnb
Source: https://docs.dune.com/data-catalog/evm/bnb/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on bnb.

<DexTradesSnippet />


# NFT.trades on bnb
Source: https://docs.dune.com/data-catalog/evm/bnb/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on bnb.

<NFTTradesSnippet />


# BNB Chain Call Tables
Source: https://docs.dune.com/data-catalog/evm/bnb/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the BNB Chain network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# bnb.contracts
Source: https://docs.dune.com/data-catalog/evm/bnb/decoded/contracts

Verified contract registry on BNB Chain — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs - BNB
Source: https://docs.dune.com/data-catalog/evm/bnb/decoded/event-logs

Smart contracts on BNB emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# bnb.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/bnb/decoded/logs-decoded

ABI-decoded event logs on BNB Chain — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# BNB Chain Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/bnb/decoded/overview

Simplifying BNB Chain smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# bnb.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/bnb/decoded/traces-decoded

ABI-decoded function calls on BNB Chain — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# BNB Chain Overview
Source: https://docs.dune.com/data-catalog/evm/bnb/overview

BNB Chain data on Dune

BNB Chain is a high-performance blockchain network developed by Binance that supports the creation and functionality of decentralized applications (dApps). It is designed to provide scalability and high throughput with low transaction costs, targeting a broad and global user base.

BNB Chain operates as a dual-chain architecture, which combines the capabilities of Binance Chain (BC) and Binance Smart Chain (BSC) into a single ecosystem. This design supports interoperability and flexible user experiences, allowing transfers and cross-chain communication between different blockchains.

**Efficient and Economical:**
BNB Chain provides a scalable infrastructure with significantly reduced transaction fees, making it accessible for a wide range of applications, from small transactions to large-scale dApps.

**EVM Compatibility:**
It fully supports Ethereum Virtual Machine (EVM) compatible applications, enabling developers to migrate Ethereum-based dApps to BNB Chain with minimal adjustments and utilize the existing developer tools and ecosystem.

**Robust Community and Ecosystem:**
BNB Chain benefits from the strong community support and the extensive ecosystem of Binance, including integrations with Binance’s marketplaces, services, and large user base.

<CardGroup>
  <Card title="BNB Chain documentation" icon="link" href="https://docs.bnbchain.org">
    Access the official documentation for BNB Chain, offering detailed guides on its technology, architecture, and resources for developers.
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Event logs from smart contracts, offering insights into interactions and activities on BNB Chain.
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Data on blocks processed, indicating network activity and operational capacity on BNB Chain.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Detailed information on transactions, illustrating operational efficiency and execution on the network.
  </Card>

  <Card title="Decoded" icon="file" href="./decoded/overview">
    Decoded transaction data for easier analysis and better understanding of smart contract executions.
  </Card>
</CardGroup>


# bnb.blocks
Source: https://docs.dune.com/data-catalog/evm/bnb/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for BNB Chain.

<BlockSnippet />


# bnb.creation_traces
Source: https://docs.dune.com/data-catalog/evm/bnb/raw/creation-traces

Contract deployment records on BNB Chain — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# bnb.logs
Source: https://docs.dune.com/data-catalog/evm/bnb/raw/logs

Smart contract event logs on BNB Chain — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# bnb.traces
Source: https://docs.dune.com/data-catalog/evm/bnb/raw/traces

Internal transaction traces on BNB Chain — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# bnb.transactions
Source: https://docs.dune.com/data-catalog/evm/bnb/raw/transactions

Every transaction on BNB Chain — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# BOB Overview
Source: https://docs.dune.com/data-catalog/evm/bob/overview

BOB data on Dune

## What is BOB?

BOB ("Build on Bitcoin") is a first-of-its-kind hybrid Layer-2 powered by Bitcoin and Ethereum. It combines the security, liquidity, and userbase of Bitcoin with the innovation capabilities of Ethereum's EVM. BOB aims to become the most secure and accessible Layer-2 for developers and users.

### Why Hybrid L2?

BOB leverages Bitcoin’s robustness and Ethereum’s smart contract capabilities to bridge the gap between mass adoption and innovation. It allows developers to build dapps on a network with the highest security and user base while providing Bitcoin users access to Ethereum's innovative ecosystem without leaving the Bitcoin network.

### BOB Architecture

#### BOB Stack

<Frame>
  <img />
</Frame>

**Rollup Layer**: Utilizing Bitcoin’s PoW security and native Ethereum bridge, BOB initially launches on the OP stack, aiming to settle directly on Bitcoin L1 using merged mining and optimistic rollup mechanisms.

**EVM Core**: At its core, BOB leverages Ethereum's EVM, supporting Solidity smart contracts, existing developer tooling, wallets, and infrastructure components like block explorers and data analytics tools.

**Rust zkVM**: Supporting Bitcoin’s Rust libraries through RISC Zero zkVM, enabling off-chain execution of Rust programs with ZK proofs verified in EVM smart contracts. This paves the way for future ZK rollups on Bitcoin.

**Bitcoin Bridges**: BOB provides trustless access to Bitcoin block and transactional data via a BTC light client, supporting a range of decentralized and institutional Bitcoin bridges for seamless interaction with Ethereum assets.

**BOB SDK**: A comprehensive toolkit for developers building on Bitcoin, offering Solidity contracts to interact with Bitcoin assets, improved APIs, and tools for a unified BTC and EVM wallet experience.

#### BOB Rollup Design

BOB’s hybrid L2 design will be launched in multiple stages:

* **Phase 1 ("Launch")**: Bootstrapping as an ETH rollup.
* **Phase 2**: Bitcoin PoW security and economic alignment through merged mining.
* **Phase 3**: Hybrid L2 with settlement on Bitcoin and Ethereum, leveraging BitVM for security.

<CardGroup>
  <Card title="BOB documentation" icon="link" href="https://docs.gobob.xyz/docs/learn/introduction/stack">
    Explore comprehensive documentation on BOB, detailing its architecture, protocol, and resources for developers.
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Detailed event logs from smart contracts, providing insights into interactions within the BOB network.
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on blocks, illustrating the operational capacity and activity levels on BOB.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Extensive transaction data, showcasing the efficiency and execution of operations on BOB.
  </Card>

  <Card title="Traces" icon="file" href="./raw/traces">
    Enhanced transaction data, including internal transactions invoked by top-level transactions.
  </Card>
</CardGroup>


# bob.blocks
Source: https://docs.dune.com/data-catalog/evm/bob/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for BOB.

<BlockSnippet />


# bob.logs
Source: https://docs.dune.com/data-catalog/evm/bob/raw/logs

Smart contract event logs on BOB — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# bob.traces
Source: https://docs.dune.com/data-catalog/evm/bob/raw/traces

Internal transaction traces on BOB — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# bob.transactions
Source: https://docs.dune.com/data-catalog/evm/bob/raw/transactions

Every transaction on BOB — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex_aggregator.trades on boba
Source: https://docs.dune.com/data-catalog/evm/boba/curated-data/dex/dex-aggregator-trades

DEX aggregator swaps on Boba — trades routed through aggregators like 1inch, Paraswap, and CoW Swap with pricing and routing details.

<DexAggregatorTradesSnippet />


# dex.trades on boba
Source: https://docs.dune.com/data-catalog/evm/boba/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on boba.

<DexTradesSnippet />


# NFT.trades on Boba
Source: https://docs.dune.com/data-catalog/evm/boba/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on Boba.

<NFTTradesSnippet />


# Boba Call Tables
Source: https://docs.dune.com/data-catalog/evm/boba/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Boba network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# boba.contracts
Source: https://docs.dune.com/data-catalog/evm/boba/decoded/contracts

Verified contract registry on Boba — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs - Boba
Source: https://docs.dune.com/data-catalog/evm/boba/decoded/event-logs

Smart contracts on Boba emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# boba.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/boba/decoded/logs-decoded

ABI-decoded event logs on Boba — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Boba Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/boba/decoded/overview

Simplifying Boba smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# boba.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/boba/decoded/traces-decoded

ABI-decoded function calls on Boba — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Boba Overview
Source: https://docs.dune.com/data-catalog/evm/boba/overview

Boba data on Dune Analytics

Boba is an Ethereum Layer 2 (L2) optimistic rollup that offers fast transactions and low fees. It is EVM-compatible, allowing developers to easily deploy existing Ethereum smart contracts on Boba. Some key features of Boba include:

* **Fast Transactions:** Boba provides fast transaction confirmations by leveraging optimistic rollups, enabling high throughput and scalability.

* **Low Fees:** By processing transactions off-chain and only posting data back to Ethereum for finality, Boba offers significantly lower transaction fees compared to Ethereum mainnet.

* **EVM Compatibility:** Boba is fully compatible with the Ethereum Virtual Machine (EVM), allowing developers to deploy existing Ethereum smart contracts without modifications.

* **Security:** Boba inherits the security of Ethereum by leveraging fraud proofs and a challenge period to ensure the validity of state transitions.

<CardGroup>
  <Card title="Boba documentation" icon="link" href="https://docs.boba.network/">
    Explore comprehensive documentation on Boba, detailing its architecture, protocol, and resources for developers.
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Detailed event logs from smart contracts, providing insights into interactions within the Boba network.
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on blocks, illustrating the operational capacity and activity levels on Boba.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Extensive transaction data, showcasing the efficiency and execution of operations on Boba.
  </Card>

  <Card title="Decoded" icon="file" href="./decoded/overview">
    Enhanced transaction data decoded for better analysis and understanding of contract executions.
  </Card>
</CardGroup>


# boba.blocks
Source: https://docs.dune.com/data-catalog/evm/boba/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Boba.

<BlockSnippet />


# boba.creation_traces
Source: https://docs.dune.com/data-catalog/evm/boba/raw/creation-traces

Contract deployment records on Boba — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# boba.logs
Source: https://docs.dune.com/data-catalog/evm/boba/raw/logs

Smart contract event logs on Boba — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# boba.traces
Source: https://docs.dune.com/data-catalog/evm/boba/raw/traces

Internal transaction traces on Boba — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# boba.transactions
Source: https://docs.dune.com/data-catalog/evm/boba/raw/transactions

Every transaction on Boba — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex_aggregator.trades on Celo
Source: https://docs.dune.com/data-catalog/evm/celo/curated-data/dex/dex-aggregator-trades

DEX aggregator swaps on Celo — trades routed through aggregators like 1inch, Paraswap, and CoW Swap with pricing and routing details.

<DexAggregatorTradesSnippet />


# dex.trades on Celo
Source: https://docs.dune.com/data-catalog/evm/celo/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on Celo.

<DexTradesSnippet />


# NFT.trades on Celo
Source: https://docs.dune.com/data-catalog/evm/celo/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on Celo.

<NFTTradesSnippet />


# Celo Call Tables
Source: https://docs.dune.com/data-catalog/evm/celo/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Celo network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# celo.contracts
Source: https://docs.dune.com/data-catalog/evm/celo/decoded/contracts

Verified contract registry on Celo — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs
Source: https://docs.dune.com/data-catalog/evm/celo/decoded/event-logs

Smart Contracts emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# celo.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/celo/decoded/logs-decoded

ABI-decoded event logs on Celo — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Celo Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/celo/decoded/overview

Simplifying Celo smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# celo.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/celo/decoded/traces-decoded

ABI-decoded function calls on Celo — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Celo Overview
Source: https://docs.dune.com/data-catalog/evm/celo/overview

Celo data on Dune

Celo is a blockchain ecosystem focused on increasing cryptocurrency adoption among smartphone users. By leveraging mobile access, Celo aims to empower anyone with a smartphone to access financial services, send money to phone contacts, and pay for goods and services with crypto.

The Celo network utilizes a unique consensus algorithm and a stablecoin ecosystem to offer secure, fast, and low-cost transactions. It's designed to be light enough to run on mobile devices, reducing the barriers for entry and facilitating a user-friendly experience.

**Mobile-First Approach:**
Celo's architecture is specifically tailored for mobile users, supporting easy integration and operation on smartphones, which is essential for accessibility in regions with limited access to traditional banking.

**Stablecoin Ecosystem:**
The network supports various stablecoins pegged to fiat currencies, facilitating everyday transactions and reducing the volatility typically associated with cryptocurrencies.

**Decentralized Finance (DeFi) Capabilities:**
Celo extends the reach of DeFi applications by enabling a suite of decentralized apps that are accessible on mobile devices, broadening financial inclusion.

<CardGroup>
  <Card title="Celo documentation" icon="link" href="https://docs.celo.org">
    Access the official documentation for Celo, providing comprehensive information on its technology, mobile integration, and DeFi solutions.
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Detailed event logs from smart contracts, providing insights into interactions and activities within the Celo network.
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on blocks processed, highlighting network activity and the performance of the mobile-first infrastructure.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Extensive transaction data, showcasing the efficiency and user engagement across the network.
  </Card>

  <Card title="Decoded" icon="file" href="./decoded/overview">
    Decoded transaction data for better analysis and understanding of contract executions on Celo.
  </Card>
</CardGroup>


# celo.blocks
Source: https://docs.dune.com/data-catalog/evm/celo/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Celo.

<BlockSnippet />


# celo.creation_traces
Source: https://docs.dune.com/data-catalog/evm/celo/raw/creation-traces

Contract deployment records on Celo — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# celo.logs
Source: https://docs.dune.com/data-catalog/evm/celo/raw/logs

Smart contract event logs on Celo — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# celo.traces
Source: https://docs.dune.com/data-catalog/evm/celo/raw/traces

Internal transaction traces on Celo — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# celo.transactions
Source: https://docs.dune.com/data-catalog/evm/celo/raw/transactions

Every transaction on Celo — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex_aggregator.trades on corn
Source: https://docs.dune.com/data-catalog/evm/corn/curated-data/dex/dex-aggregator-trades

DEX aggregator swaps on Corn — trades routed through aggregators like 1inch, Paraswap, and CoW Swap with pricing and routing details.

<DexAggregatorTradesSnippet />


# dex.trades on corn
Source: https://docs.dune.com/data-catalog/evm/corn/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on corn.

<DexTradesSnippet />


# NFT.trades on corn
Source: https://docs.dune.com/data-catalog/evm/corn/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on corn.

<NFTTradesSnippet />


# Corn Call Tables
Source: https://docs.dune.com/data-catalog/evm/corn/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Corn network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# corn.contracts
Source: https://docs.dune.com/data-catalog/evm/corn/decoded/contracts

Verified contract registry on Corn — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs
Source: https://docs.dune.com/data-catalog/evm/corn/decoded/event-logs

Smart Contracts emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# corn.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/corn/decoded/logs-decoded

ABI-decoded event logs on Corn — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Corn Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/corn/decoded/overview

Simplifying Corn smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# corn.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/corn/decoded/traces-decoded

ABI-decoded function calls on Corn — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Corn Overview
Source: https://docs.dune.com/data-catalog/evm/corn/overview

Corn data on Dune

## What is Corn?

Corn is a next-generation Ethereum Layer 2 network specifically designed to unlock the full potential of Bitcoin. Built on Arbitrum Orbit, it provides a Bitcoin-centric ecosystem that combines scalability, efficiency, and innovative features to enhance the Bitcoin ecosystem.

## Key Features

* **Bitcorn (BTCN)**: Native gas token of the network
* **popCORN System**: Provides long-term incentives for ecosystem participants
* **LayerZero Integration**: Enables seamless cross-chain asset transfers
* **Arbitrum Orbit**: Leverages Arbitrum's technology for scalability and efficiency
* **Stylus Support**: Allows developers to use multiple programming languages for smart contract development

## Why Corn?

Corn positions itself as the "Butter Network" with three main value propositions:

* Butter yield
* Butter BTC
* Butter vibes

It's designed to be the optimal platform for putting Bitcoin to work, creating a rich ecosystem of Bitcoin-focused applications and services.

## Technical Architecture

Built on Arbitrum Orbit, Corn inherits the robust technical foundation of Arbitrum while adding Bitcoin-specific optimizations:

### Development Features

* **Multiple Language Support**: Through Stylus integration, developers can write smart contracts in various programming languages
* **Bitcoin Integration**: Native support for Bitcoin-related operations and assets
* **Cross-chain Capabilities**: LayerZero integration for efficient cross-chain transactions

### Network Economics

* **Gas Token**: Bitcorn (BTCN)
* **Incentive Structure**: popCORN System for sustainable long-term ecosystem growth

<CardGroup>
  <Card title="Corn Documentation" icon="link" href="https://docs.usecorn.com">
    Official documentation for developers building on Corn - The Butter Network for Bitcoin
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Insights into smart contract interactions through event logs
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on blocks processed on Corn, reflecting network activity and capacity
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Detailed data on transactions, showcasing efficiency and operational execution
  </Card>

  <Card title="decoded" icon="file" href="./decoded/overview">
    Decoded transaction information for enhanced analysis and understanding of smart contract executions
  </Card>
</CardGroup>


# corn.blocks
Source: https://docs.dune.com/data-catalog/evm/corn/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Corn.

<BlockSnippet />


# corn.creation_traces
Source: https://docs.dune.com/data-catalog/evm/corn/raw/creation-traces

Contract deployment records on Corn — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# corn.logs
Source: https://docs.dune.com/data-catalog/evm/corn/raw/logs

Smart contract event logs on Corn — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# corn.traces
Source: https://docs.dune.com/data-catalog/evm/corn/raw/traces

Internal transaction traces on Corn — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# corn.transactions
Source: https://docs.dune.com/data-catalog/evm/corn/raw/transactions

Every transaction on Corn — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# degen Overview
Source: https://docs.dune.com/data-catalog/evm/degen/overview

degen data on Dune

Degen, an ERC-20 token launched in January 2024, has reshaped the Farcaster ecosystem by enabling Casters to reward others with DEGEN for posting quality content. Our points system recognizes unique posts and comments, effectively bridging the gap between online contributions and real-world value.

Degen has launched a layer 3 solution that settles transactions on the Base network. This solution is designed to provide a more efficient and scalable way to settle transactions related to \$DEGEN.
Degen Chain uses Arbitrum Orbit for rollups, Base for transaction settlements, and Arbitrum AnyTrust for data availability.

<CardGroup>
  <Card title="degen website" icon="link" href="https://www.degen.tips/">
    The official website of degen, providing information on the project, team, and community.
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Detailed event logs from smart contracts, providing insights into interactions within the degen network.
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on blocks, illustrating the operational capacity and activity levels on degen.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Extensive transaction data, showcasing the efficiency and execution of operations on degen.
  </Card>
</CardGroup>


# degen.blocks
Source: https://docs.dune.com/data-catalog/evm/degen/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Degen.

<BlockSnippet />


# degen.logs
Source: https://docs.dune.com/data-catalog/evm/degen/raw/logs

Smart contract event logs on Degen — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# degen.traces
Source: https://docs.dune.com/data-catalog/evm/degen/raw/traces

Internal transaction traces on Degen — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# degen.transactions
Source: https://docs.dune.com/data-catalog/evm/degen/raw/transactions

Every transaction on Degen — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex_aggregator.trades on ethereum
Source: https://docs.dune.com/data-catalog/evm/ethereum/curated-data/dex/dex-aggregator-trades

DEX aggregator swaps on Ethereum — trades routed through aggregators like 1inch, Paraswap, and CoW Swap with pricing and routing details.

<DexAggregatorTradesSnippet />


# dex.trades on ethereum
Source: https://docs.dune.com/data-catalog/evm/ethereum/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on ethereum.

<DexTradesSnippet />


# NFT Trades on Ethereum
Source: https://docs.dune.com/data-catalog/evm/ethereum/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on Ethereum.

<NFTTradesSnippet />


# Ethereum Call Tables
Source: https://docs.dune.com/data-catalog/evm/ethereum/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Ethereum network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<div>
  <DuneEmbed />
</div>

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<div>
  <DuneEmbed />
</div>

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [ERC20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of a transaction, this message call will be recorded in the Dune table [`uniswap_ethereum.UNI_call_decimals`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# ethereum.contracts
Source: https://docs.dune.com/data-catalog/evm/ethereum/decoded/contracts

Verified contract registry on Ethereum — contract name, namespace, ABI, and deployment metadata.

## Table Description

The `ethereum.contracts` table contains information about the contracts Dune has decoded on the Ethereum blockchain.

## Column Descriptions

| Column             | Type             | Description                                           |
| ------------------ | ---------------- | ----------------------------------------------------- |
| `abi_id`           | `varchar`        | Unique identifier for the ABI                         |
| `abi`              | `array(varchar)` | Contract ABI (Application Binary Interface)           |
| `address`          | `varbinary`      | Contract address                                      |
| `from`             | `varbinary`      | Address that deployed the contract                    |
| `code`             | `varbinary`      | Deployed bytecode of the contract                     |
| `name`             | `varchar`        | Name of the contract                                  |
| `namespace`        | `varchar`        | Project namespace (e.g., uniswap\_v3)                 |
| `dynamic`          | `boolean`        | Whether the contract was dynamically detected         |
| `base`             | `boolean`        | Whether this is the base contract submission          |
| `factory`          | `boolean`        | Whether this contract is a factory contract           |
| `detection_source` | `varchar`        | How the contract was detected (manual, factory, etc.) |
| `created_at`       | `timestamp`      | When this record was created in Dune                  |

## Table Sample

<TableSample />


# Event Logs
Source: https://docs.dune.com/data-catalog/evm/ethereum/decoded/event-logs

Smart Contracts emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<div>
  <DuneEmbed />
</div>

## Multiple Instances

If there are multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<div>
  <DuneEmbed />
</div>

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="https://dune.com/decode" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# ethereum.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/ethereum/decoded/logs-decoded

ABI-decoded event logs on Ethereum — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Ethereum Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/ethereum/decoded/overview

Simplifying Ethereum smart contract analysis through human-readable tables.

### Overview of Dune's Decoded Data Approach

Dune uses the ABI (Application Binary Interface) of smart contracts to decode blockchain transactions into structured tables. Each event log and function call from the ABI are parsed into their own tables. This decoding process transforms the raw, encoded data on the blockchain into human-readable tables, simplifying the analysis of smart contract data.

Dune's decoded data approach offers several benefits:

* **Enhanced Readability:** The decoded data tables provide a clear and intuitive representation of smart contract activities

* **Efficient Analysis:** The structured tables enable efficient querying and analysis of smart contract data

* **Handling Multiple Contract Instances:** For smart contracts with multiple instances, Dune aggregates the data from these instances into a single table, simplifying the analysis process.

* **Collaborative Mapping:** Dune's smart contract library is continuously expanded through the active participation of the Dune community, ensuring that the decoding coverage remains comprehensive and current.

<CardGroup>
  <Card title="Explore decoded logs" icon="circle-bolt" href="/data-catalog/evm/ethereum/decoded/event-logs" />

  <Card title="Explore decoded traces" icon="layer-group" href="/data-catalog/evm/ethereum/decoded/call-tables" />
</CardGroup>

## Which contracts have decoded data?

Contract submissions on Dune are driven by the community. Usually the odds are good that the contract you are looking at is already decoded, but especially for new projects or new contracts, it might be that the contract is not decoded yet. In those cases you can submit the contract to be decoded. Decoding usually takes about 24 hours, in special cases it might take longer.

You can check if contracts are already decoded by querying [`[blockchain].contracts`](/data-catalog/evm/ethereum/decoded/contracts) tables, the [data explorer](/web-app/query-editor/data-explorer) or use [this dashboard](https://dune.com/dune/is-my-contract-decoded-yet-v2).

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>

## How does decoding work?

Smart Contracts on any EVM blockchain are mostly written in high level languages like [Solidity](https://docs.soliditylang.org/en/v0.8.2) or [Vyper](https://vyper.readthedocs.io/en/stable).

In order for them to be able to be deployed to an EVM execution environment, they need to be compiled to EVM executable bytecode. Once deployed, the bytecode gets associated to an address on the respective chain and is permanently stored in this chain's state storage.

To be able to interact with this smart contract, which is now just bytecode, we need a guide to be able to call the functions which are defined in the high-level languages. This translation of names and arguments into byte representation is done using an **Application Binary Interface (ABI)**.

The ABI documents names, types, and arguments precisely which allows us to interact with the smart contract using a somewhat human readable format. The ABI can be compiled using the high level language source code.

**The ABI is used to call a smart contract or interpret the data it emits.**

<img alt="source: https://hackernoon.com/hn-images/1*Sz1a7G2pQ62UnkHoieve4w.jpeg" />

## Decoding Example

We are going to look at an event log of an ERC20 transfer event from the [smart contract](https://etherscan.io/token/0x429881672B9AE42b8EbA0E26cD9C73711b891Ca5#readContract) that represents the \$PICKLE token.

On [Etherscan](https://etherscan.io/tx/0x2bb7c8283b782355875fa37d05e4bd962519ea294678a3dcf2fdffbbd0761bc5#eventlog) the undecoded event looks like this:

<img alt="etherscan" />

If we query for this transaction in the `ethereum.logs` table in the Dune database, we will receive the same encoded bytecode as our result dataset.

```sql theme={null}
SELECT *
FROM ethereum.logs
WHERE tx_hash = 0x2bb7c8283b782355875fa37d05e4bd962519ea294678a3dcf2fdffbbd0761bc5
```

<div>
  <DuneEmbed />
</div>

We could make short work of this encoded bytecode by using [DuneSQL Varbinary functions](/query-engine/Functions-and-operators/varbinary) to decode it, but having the contract's ABI at hand makes this process much easier. This contract is decoded in Dune, so we can use the `pickle_finance_ethereum.PickleToken_evt_Transfer` table to access the decoded event log.

```sql theme={null}
SELECT *
FROM pickle_finance_ethereum.PickleToken_evt_Transfer
WHERE evt_tx_hash = 0x2bb7c8283b782355875fa37d05e4bd962519ea294678a3dcf2fdffbbd0761bc5
```

<div>
  <DuneEmbed />
</div>

**Now this is actually useful for analyzing this transaction!**

How exactly does this work?

Since we know which event we are looking at here, we can simply convert the encoded bytecode to decoded data by decoding the bytecode according to its datatype.

The structure for the `Transfer` event log of an ERC20 token will always be:

```solidity theme={null}
Transfer(address from, address to, uint256 value)
```

This basically tells us that topic2 and topic3 are of the type `address`(32bytes) and are respectively the sender and recipient of the token transfer. An event log only has 3 indexed fields, so the `data` field is used to store the information about how much units of the token have been moved in this transaction. This field is called `value`.

Since `topic0` always is just the Keccak-256 hash of the signature of the event, we are left with decoding `topic1`, `topic2` and `data`.

In this case, they map out like this:

| raw data field | decoded data description                     | raw data                                                           | decoded data                                                                  |
| -------------- | -------------------------------------------- | ------------------------------------------------------------------ | ----------------------------------------------------------------------------- |
| topic0         | keccak('Transfer(address,address,uint256'')) | 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef | not needed, this table only contains event logs from the `transfer` event log |
| topic1         | from                                         | 0x00000000000000000000000075e89d5979e4f6fba9f97c104c2f0afb3f1dcb88 | 0x75e89d5979e4f6fba9f97c104c2f0afb3f1dcb88                                    |
| topic2         | to                                           | 0x00000000000000000000000087d9da48db6e1f925cb67d3b7d2a292846c24cf7 | 0x87d9da48db6e1f925cb67d3b7d2a292846c24cf7                                    |
| data           | value                                        | 0x00000000000000000000000000000000000000000000001a894d51f85cb08000 | 489509000000000000000                                                         |

Now what works for a single erc20 token, works for all erc20 tokens. We can use defined interfaces to decode the data of any erc20 token transfer event log.

## How do I understand decoded data?

Decoded data is the high level programming language representation of two pieces of software talking to each other via the blockchain.

It's not always easy for a human to understand what exactly is going on in these interactions, but most of the time, looking at column names and the data that is transmitted within them should help you to understand what is happening within that specific log or call.

If you are not able to make sense of the data by just searching the tables, it usually helps to look at single transactions using the transaction hash and Etherscan.

Furthermore, actually going into the smart contract's code (our favorite way to do this is [DethCode](https://etherscan.deth.net)) to read the comments or the actual logic can help to understand the smart contract's emitted data.

If that also doesn't lead to satisfactory results, scouring the relevant docs and GitHub of the project can lead you to the desired answers. Furthermore, talking to the developers and core community of a project can also help you to get an understanding of the smart contracts.


# ethereum.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/ethereum/decoded/traces-decoded

ABI-decoded function calls on Ethereum — parsed function names, inputs, and outputs from verified contracts.

## Table Description

The `traces_decoded` table contains decoded traces from Ethereum transactions. The table matches `MethodID`, which consists of the first 4 bytes of any eth call to the trace signature and the corresponding Method name. The table does not contain the full trace data and is not suitable for analysis of smart contract level data. For that, use the specific event tables as described in [Call-tables](/data-catalog/evm/ethereum/decoded/call-tables).

The `ethereum.traces_decoded` table is great for gaining a high level understanding of the types of events that are being emitted by a smart contract or smart contracts of a certain protocol.

## Column Descriptions

| Column          | Type            | Description                                    |
| --------------- | --------------- | ---------------------------------------------- |
| `block_date`    | `date`          | Date of the block (UTC)                        |
| `block_time`    | `timestamp`     | Timestamp of the block containing this trace   |
| `block_number`  | `bigint`        | Block number containing this trace             |
| `namespace`     | `varchar`       | Project namespace (e.g., uniswap\_v3)          |
| `contract_name` | `varchar`       | Name of the contract that was called           |
| `to`            | `varbinary`     | Address of the contract that was called        |
| `trace_address` | `array(bigint)` | Path of this trace within the call tree        |
| `tx_hash`       | `varbinary`     | Hash of the parent transaction                 |
| `tx_from`       | `varbinary`     | Address that initiated the transaction         |
| `tx_to`         | `varbinary`     | Address the transaction was sent to            |
| `tx_index`      | `integer`       | Position of the transaction within the block   |
| `success`       | `boolean`       | Whether this trace executed successfully       |
| `signature`     | `varbinary`     | Function signature (first 4 bytes of calldata) |
| `function_name` | `varchar`       | Decoded name of the function called            |
| `created_at`    | `timestamp`     | When this record was created in Dune           |

## Table Sample

<TableSample />


# Ethereum Overview
Source: https://docs.dune.com/data-catalog/evm/ethereum/overview

Ethereum data on Dune

Ethereum is a decentralized, open-source blockchain system that features its own cryptocurrency, Ether. It is a platform for numerous decentralized applications (dApps), including everything from financial tools to games and complex databases. Ethereum is well-known for its flexibility and its pioneering role in the introduction and use of smart contracts, which are self-executing contracts with the terms of the agreement directly written into code.

The network supports a broad range of applications due to its general-purpose nature, and it operates on a proof-of-stake consensus mechanism, enhancing its scalability and energy efficiency compared to earlier proof-of-work systems.

**Versatility and Developer Support:**
Ethereum supports the creation of a wide variety of applications beyond simple transactions. This includes decentralized finance (DeFi) applications, NFTs, and more, supported by a robust development toolkit and a strong global community.

**Smart Contract Functionality:**
Ethereum's use of smart contracts automates enforcement, management, performance, and payment — they execute automatically when conditions are met.

<CardGroup>
  <Card title="Ethereum documentation" icon="link" href="https://ethereum.org/en/developers/docs/">
    The official documentation for Ethereum, providing a wealth of resources on how to build on and interact with the platform.
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Event logs from smart contracts, showcasing the diverse and dynamic usage of Ethereum's decentralized platform.
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on Ethereum blocks, reflecting the network's activity and scalability achievements.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Detailed information on transactions, underscoring the high throughput and complexity of operations on Ethereum.
  </Card>

  <Card title="decoded" icon="file" href="./decoded/overview">
    Decoded transaction data, facilitating easier analysis and deeper understanding of smart contract operations.
  </Card>
</CardGroup>


# ethereum.blocks
Source: https://docs.dune.com/data-catalog/evm/ethereum/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Ethereum.

## Table Description

The `ethereum.blocks` table contains information about blocks in the Ethereum blockchain. A block is a collection of transactions that are hashed and added to the blockchain. Each block contains a reference to the previous block, known as the parent hash, and a timestamp. The table contains information about each block, such as the block number, the block hash, the block size, the number of transactions, and the gas used.

## Column Descriptions

| Column                     | Type        | Description                                         |
| -------------------------- | ----------- | --------------------------------------------------- |
| `time`                     | `timestamp` | The time when the block was mined                   |
| `number`                   | `bigint`    | The block number (height)                           |
| `gas_limit`                | `decimal`   | Maximum gas allowed in the block                    |
| `gas_used`                 | `decimal`   | Total gas used by all transactions in the block     |
| `difficulty`               | `bigint`    | Mining difficulty of the block                      |
| `total_difficulty`         | `decimal`   | Cumulative difficulty of the chain up to this block |
| `size`                     | `bigint`    | Size of the block in bytes                          |
| `base_fee_per_gas`         | `bigint`    | Base fee per gas unit (EIP-1559)                    |
| `hash`                     | `varbinary` | Hash of the block                                   |
| `parent_hash`              | `varbinary` | Hash of the parent block                            |
| `miner`                    | `varbinary` | Address of the miner/validator                      |
| `nonce`                    | `varbinary` | Nonce used in mining the block                      |
| `date`                     | `date`      | Date of the block (UTC)                             |
| `blob_gas_used`            | `bigint`    | Total blob gas used in the block (EIP-4844)         |
| `excess_blob_gas`          | `bigint`    | Excess blob gas for fee calculation (EIP-4844)      |
| `parent_beacon_block_root` | `varbinary` | Root of the parent beacon block                     |

## Table Sample

<TableSample />

## Examples

### Show the most recent blocks

```sql theme={null}
SELECT
  number,
  hash,
  size,
  gas_used
FROM
  ethereum.blocks
ORDER BY
  number DESC
LIMIT 10
```

### Show the number of blocks mined each day

```sql theme={null}
SELECT
  date_trunc('day', time) AS day,
  count(distinct number)
FROM
  ethereum.blocks
GROUP BY
  day
ORDER BY
  day DESC
```

### Show the number of transactions in each block

```sql theme={null}
SELECT
  number,
  count(*)
FROM
  ethereum.blocks
group by 1 

LIMIT 10
```


# ethereum.creation_traces
Source: https://docs.dune.com/data-catalog/evm/ethereum/raw/creation-traces

Contract deployment records on Ethereum — deployer address, factory context, and deployed bytecode.

## Table Description

The `creation_traces` table contains information about the creation of smart contracts on the Ethereum blockchain. This includes the address of the contract, the address of the creator, the block number at which the contract was created, the transaction hash, and the contract's bytecode. This table is useful for understanding the deployment of smart contracts on the Ethereum blockchain.

The `ethereum.creation_traces` table is a subset of the `traces` table, which contains information about all traces on the Ethereum blockchain. The `creation_traces` table is filtered to only include traces that create new smart contracts. The filter for this is `type` = `create`.

## Column Descriptions

| Column         | Type        | Description                                           |
| -------------- | ----------- | ----------------------------------------------------- |
| `block_time`   | `timestamp` | Timestamp of the block containing this creation trace |
| `block_number` | `bigint`    | Block number containing this creation trace           |
| `tx_hash`      | `varbinary` | Hash of the transaction that created the contract     |
| `address`      | `varbinary` | Address of the newly created contract                 |
| `from`         | `varbinary` | Address that deployed the contract                    |
| `code`         | `varbinary` | Bytecode of the deployed contract                     |
| `block_month`  | `date`      | Month of the block (for partitioning)                 |

## Table Sample

<TableSample />

## Examples

### Show the creation of a specific smart contract

```sql theme={null}
select * from ethereum.creation_traces
where contract_address = 0x06012c8cf97bead5deae237070f9587f8e7a266d
```

### Show the creation of smart contracts by a specific creator

```sql theme={null}
select * from ethereum.creation_traces
where "from" = 0x0d4a11d5eeaac28ec3f61d100da81f6a1b65c9d6
```

### Show the creation of smart contracts in the last 10 days

```sql theme={null}
select 
    date_trunc('day', block_time) as day,
    count(*)
from ethereum.creation_traces
group by 1
order by 1 desc
limit 10
```


# ethereum.logs
Source: https://docs.dune.com/data-catalog/evm/ethereum/raw/logs

Smart contract event logs on Ethereum — indexed topics and data fields from token transfers, swaps, and protocol actions.

## Table Description

The `ethereum.logs` table represents the logs generated by the Ethereum Virtual Machine (EVM) when a contract is executed. Logs are a way to store data on the blockchain. Logs originate from events that occur during the execution of a smart contract. A log consists of:

* topic list: a list of 0 to 4 32-byte data topics. `Topic0` is the hash of the signature of the event (indexed), and the remaining topics are indexed parameters of the event.
* data: contains non-indexed data.

This is the raw version of this table, for decoded event logs, see the [decoded logs](/data-catalog/evm/ethereum/decoded/event-logs) section.

## Column Descriptions

| Column             | Type        | Description                                     |
| ------------------ | ----------- | ----------------------------------------------- |
| `block_time`       | `timestamp` | Timestamp of the block containing this log      |
| `block_number`     | `bigint`    | Block number containing this log                |
| `block_hash`       | `varbinary` | Hash of the block containing this log           |
| `contract_address` | `varbinary` | Address of the contract that emitted the log    |
| `topic0`           | `varbinary` | Event signature hash (first indexed topic)      |
| `topic1`           | `varbinary` | First indexed event parameter                   |
| `topic2`           | `varbinary` | Second indexed event parameter                  |
| `topic3`           | `varbinary` | Third indexed event parameter                   |
| `data`             | `varbinary` | Non-indexed event data                          |
| `tx_hash`          | `varbinary` | Hash of the transaction that generated this log |
| `index`            | `integer`   | Position of the log within the block            |
| `tx_index`         | `integer`   | Position of the transaction within the block    |
| `block_date`       | `date`      | Date of the block (UTC)                         |
| `tx_from`          | `varbinary` | Address that initiated the transaction          |
| `tx_to`            | `varbinary` | Address the transaction was sent to             |
| `blob_gas_price`   | `bigint`    | Blob gas price of the transaction (EIP-4844)    |
| `blob_gas_used`    | `bigint`    | Blob gas used by the transaction (EIP-4844)     |

## Table Sample

<TableSample />

## Examples

### Filter the logs for a specific contract

```sql theme={null}
select *
from ethereum.logs
where contract_address = 0x06012c8cf97bead5deae237070f9587f8e7a266d
limit 10
```

### Filter the logs for a specific topic

```sql theme={null}
select *
from ethereum.logs
where topic0 = 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef

```

### Show the logs of a specific block

```sql theme={null}
SELECT *
FROM ethereum.logs
WHERE evt_block_number = 1000000
```


# ethereum.traces
Source: https://docs.dune.com/data-catalog/evm/ethereum/raw/traces

Internal transaction traces on Ethereum — cross-contract calls, delegate calls, and value transfers with full call stack context.

## Table Description

The `ethereum.traces` table contains the traces of transactions executed on the Ethereum Virtual Machine (EVM). It includes traces of both top-level and internal transactions. Traces are the result of transaction execution and are used to debug and understand how transactions are processed. They are also known as `internal transactions`.

This is the raw version of this table, for decoded transaction calls, see the [call tables](/data-catalog/evm/ethereum/decoded/call-tables) section.

## Column Descriptions

| Column           | Type            | Description                                         |
| ---------------- | --------------- | --------------------------------------------------- |
| `block_time`     | `timestamp`     | Timestamp of the block containing this trace        |
| `block_number`   | `bigint`        | Block number containing this trace                  |
| `value`          | `uint256`       | Amount of native token transferred (in wei)         |
| `gas`            | `bigint`        | Gas provided for this trace                         |
| `gas_used`       | `bigint`        | Gas consumed by this trace                          |
| `block_hash`     | `varbinary`     | Hash of the block containing this trace             |
| `success`        | `boolean`       | Whether this trace executed successfully            |
| `tx_index`       | `integer`       | Position of the transaction within the block        |
| `sub_traces`     | `bigint`        | Number of child traces spawned by this trace        |
| `error`          | `varchar`       | Error message if the trace failed                   |
| `tx_success`     | `boolean`       | Whether the parent transaction succeeded            |
| `tx_hash`        | `varbinary`     | Hash of the parent transaction                      |
| `from`           | `varbinary`     | Address that initiated this trace                   |
| `to`             | `varbinary`     | Address the trace was sent to                       |
| `trace_address`  | `array(bigint)` | Path of this trace within the call tree             |
| `type`           | `varchar`       | Type of trace (call, create, suicide, reward)       |
| `address`        | `varbinary`     | Address of the contract created (for create traces) |
| `code`           | `varbinary`     | Bytecode of the contract created                    |
| `call_type`      | `varchar`       | Type of call (call, delegatecall, staticcall)       |
| `input`          | `varbinary`     | Input data for the trace                            |
| `output`         | `varbinary`     | Output data from the trace                          |
| `refund_address` | `varbinary`     | Address receiving refund (for selfdestruct)         |
| `block_date`     | `date`          | Date of the block (UTC)                             |

## Table Sample

<TableSample />

## Example

### Querying traces for a specific transaction hash

```sql theme={null}
SELECT *
FROM ethereum.traces
WHERE tx_hash = 0xb30d6d67cf7d148c2257bf598c5f5cdf5912a3d05c7d3b000398d675d2fa912c
```


# ethereum.transactions
Source: https://docs.dune.com/data-catalog/evm/ethereum/raw/transactions

Every transaction on Ethereum — from, to, value, gas, calldata, and receipt status.

## Table Description

The `ethereum.transactions` table contains information about all transactions on the Ethereum blockchain. Each row represents a single transaction and includes information such as block number, hash, timestamp, sender, recipient, value, gas, gas price, and more.
Transactions are the fundamental unit of interaction with the Ethereum blockchain. Transactions are created by users and are used to send value, deploy smart contracts, and interact with smart contracts.

This is the raw version of this table, for decoded transaction calls, see the [call tables](/data-catalog/evm/ethereum/decoded/call-tables) section.

## Column Descriptions

| Column                     | Type               | Description                                             |
| -------------------------- | ------------------ | ------------------------------------------------------- |
| `block_time`               | `timestamp`        | Timestamp of the block containing this transaction      |
| `block_number`             | `bigint`           | Block number containing this transaction                |
| `value`                    | `decimal`          | Amount of native token transferred (in wei)             |
| `gas_limit`                | `bigint`           | Maximum gas the sender is willing to use                |
| `gas_price`                | `bigint`           | Price per gas unit (in wei)                             |
| `gas_used`                 | `bigint`           | Actual gas consumed by the transaction                  |
| `max_fee_per_gas`          | `bigint`           | Maximum total fee per gas (EIP-1559)                    |
| `max_priority_fee_per_gas` | `bigint`           | Maximum priority fee (tip) per gas (EIP-1559)           |
| `priority_fee_per_gas`     | `bigint`           | Actual priority fee per gas paid                        |
| `nonce`                    | `bigint`           | Transaction count of the sender before this transaction |
| `index`                    | `bigint`           | Position of the transaction within the block            |
| `success`                  | `boolean`          | Whether the transaction executed successfully           |
| `from`                     | `varbinary`        | Address of the transaction sender                       |
| `to`                       | `varbinary`        | Address of the transaction recipient                    |
| `block_hash`               | `varbinary`        | Hash of the block containing this transaction           |
| `data`                     | `varbinary`        | Calldata sent with the transaction                      |
| `hash`                     | `varbinary`        | Unique hash of the transaction                          |
| `type`                     | `varchar`          | Transaction type (legacy, EIP-2930, EIP-1559, EIP-4844) |
| `access_list`              | `array(row)`       | List of addresses and storage keys accessed (EIP-2930)  |
| `block_date`               | `date`             | Date of the block (UTC)                                 |
| `blob_versioned_hashes`    | `array(varbinary)` | Versioned hashes of blobs (EIP-4844)                    |
| `max_fee_per_blob_gas`     | `bigint`           | Maximum fee per blob gas (EIP-4844)                     |
| `authorization_list`       | `array(row)`       | Authorization list for EIP-7702 transactions            |

## Table Sample

<TableSample />

## Examples

### Show all transactions sent by a specific address

```sql theme={null}
select * 
from ethereum.transactions where "from" = 0x50A1b5c358F8D34F0d35aA2f10742c46054E247e
```

### Count the number of transactions per block

```sql theme={null}
SELECT 
    block_number, 
    COUNT(*)
FROM ethereum.transactions
GROUP BY 1
ORDER BY 1 DESC
LIMIT 10
```

### Show the top 10 transactions with the highest gas price

```sql theme={null}
SELECT 
    hash, 
    gas_price
FROM ethereum.transactions
ORDER BY gas_price DESC
LIMIT 10
```


# ethereum.withdrawals
Source: https://docs.dune.com/data-catalog/evm/ethereum/raw/withdrawals

Beacon chain ETH withdrawals on Ethereum — validator index, amount, and recipient address.

<Note>Dune does not have beacon chain data yet. This table introduces the action of withdrawing from the beacon chain only.  </Note>

The [Ethereum Improvement Proposal (EIP) 4895](https://eips.ethereum.org/EIPS/eip-4895) introduces a system-level "operation" to support validator withdrawals that are "pushed" from the beacon chain to the EVM.

Withdrawals are represented as a new type of object in the execution payload, called an "operation", that cleanly separates this "system-level" operation from regular transactions. Withdrawals provide key information from the consensus layer such as a monotonically increasing index, validator index, recipient address, and the amount of ether given in Gwei.

Using this table you can observe beacon chain withdrawals.

## How to work with this table

In order to connect deposits and withdrawals, we must identify the `validator_index` of unique depositors. Since Dune doesn't have beacon chain data yet, we have to rely on a workaround using a query to obtain a list of valid and active deposits from the Ethereum deposit contract.

This [query](https://dune.com/queries/2364548) returns a list of valid and active deposits, which we can use to identify the `validator_index` of unique depositors. We can use this query to match the `validator_index` of depositors with the `validator_index` of withdrawers in the withdrawals table.

This query provides a comprehensive list of valid deposits and is kept up to date with full historical coverage.

[LINK TO QUERY](https://dune.com/queries/2364548)

## Column Descriptions

| Column            | Type        | Description                                          |
| ----------------- | ----------- | ---------------------------------------------------- |
| `block_time`      | `timestamp` | Timestamp of the block containing this withdrawal    |
| `block_number`    | `bigint`    | Block number containing this withdrawal              |
| `index`           | `bigint`    | Monotonically increasing withdrawal index            |
| `validator_index` | `bigint`    | Index of the validator that initiated the withdrawal |
| `address`         | `varbinary` | Recipient address of the withdrawal                  |
| `amount`          | `uint256`   | Amount of ether withdrawn (in Gwei)                  |
| `block_date`      | `date`      | Date of the block (UTC)                              |

## Table Sample

<TableSample />

## Examples

### Withdrawals per day

```sql theme={null}
select
date_trunc('day', block_time) as dt,
sum(AMOUNT)/1e9 as withdraw_amount
from ethereum.withdrawals
group by 1
```

### Dashboards

[https://dune.com/hildobby/eth2-staking](https://dune.com/hildobby/eth2-staking)

[https://dune.com/hashed\_official/staking-as-a-service](https://dune.com/hashed_official/staking-as-a-service)

* [ETH Staking Dashboard](https://dune.com/hildobby/eth2-staking) - This dashboard provides an overview of the Ethereum 2.0 staking ecosystem. It includes data on the number of validators, the total amount of staked ETH, and the number of deposits and withdrawals.
* [Staking as a Service](https://dune.com/hashed_official/staking-as-a-service) - This dashboard provides a comprehensive overview of the staking-as-a-service ecosystem. It includes data on the number of validators, the total amount of staked ETH, and the number of deposits and withdrawals.

## References

* [Ethereum Improvement Proposal EIP 4895](https://eips.ethereum.org/EIPS/eip-4895)
* [Ethereum 2.0 Deposit Contract](https://etherscan.io/address/0x00000000219ab540356cbb839cbe05303d7705fa)


# dex_aggregator.trades on fantom
Source: https://docs.dune.com/data-catalog/evm/fantom/curated-data/dex/dex-aggregator-trades

DEX aggregator swaps on Fantom — trades routed through aggregators like 1inch, Paraswap, and CoW Swap with pricing and routing details.

<DexAggregatorTradesSnippet />


# dex.trades on fantom
Source: https://docs.dune.com/data-catalog/evm/fantom/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on fantom.

<DexTradesSnippet />


# NFT.trades on fantom
Source: https://docs.dune.com/data-catalog/evm/fantom/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on fantom.

<NFTTradesSnippet />


# Fantom Call Tables
Source: https://docs.dune.com/data-catalog/evm/fantom/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Fantom network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# fantom.contracts
Source: https://docs.dune.com/data-catalog/evm/fantom/decoded/contracts

Verified contract registry on Fantom — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs
Source: https://docs.dune.com/data-catalog/evm/fantom/decoded/event-logs

Smart Contracts emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# fantom.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/fantom/decoded/logs-decoded

ABI-decoded event logs on Fantom — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Fantom Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/fantom/decoded/overview

Simplifying Fantom smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# fantom.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/fantom/decoded/traces-decoded

ABI-decoded function calls on Fantom — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Fantom Overview
Source: https://docs.dune.com/data-catalog/evm/fantom/overview

Fantom data on Dune

Fantom is a high-performance, scalable, and secure smart-contract platform that is designed to overcome the limitations of previous generation blockchain platforms. Fantom is unique in its use of a directed acyclic graph (DAG) architecture, which allows for asynchronous confirmation of transactions, resulting in high throughput and minimal transaction costs.

The network uses a bespoke consensus algorithm called Lachesis, which ensures transactions are confirmed within 1-2 seconds, significantly improving the user experience and efficiency for decentralized applications (dApps) running on the platform.

**High Throughput and Low Cost:**
Fantom’s DAG architecture enables unparalleled transaction speed and drastically reduced costs, making it an ideal platform for developers looking to build scalable dApps.

**Developer-Friendly:**
Fantom is fully compatible with Ethereum, allowing developers to deploy Ethereum-based applications quickly and seamlessly using existing tools and languages like Solidity.

**Ecosystem Growth:**
Fantom supports a growing ecosystem of decentralized finance (DeFi) applications, NFT platforms, and other blockchain projects, fostering innovation and new developments within its network.

<CardGroup>
  <Card title="Fantom documentation" icon="link" href="https://docs.fantom.foundation">
    Access comprehensive documentation for Fantom, detailing its unique technology, features, and developer resources.
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Insights into smart contract interactions through detailed event logs, providing visibility into the dynamic activity on Fantom.
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on blocks processed on Fantom, reflecting the network’s high throughput and capacity for handling large volumes of transactions.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Extensive transaction data, highlighting the efficiency and speed of operations across the Fantom network.
  </Card>

  <Card title="decoded" icon="file" href="./decoded/overview">
    Decoded transaction information for enhanced analysis and understanding of smart contract executions.
  </Card>
</CardGroup>


# fantom.blocks
Source: https://docs.dune.com/data-catalog/evm/fantom/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Fantom.

<BlockSnippet />


# fantom.creation_traces
Source: https://docs.dune.com/data-catalog/evm/fantom/raw/creation-traces

Contract deployment records on Fantom — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# fantom.logs
Source: https://docs.dune.com/data-catalog/evm/fantom/raw/logs

Smart contract event logs on Fantom — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# fantom.traces
Source: https://docs.dune.com/data-catalog/evm/fantom/raw/traces

Internal transaction traces on Fantom — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# fantom.transactions
Source: https://docs.dune.com/data-catalog/evm/fantom/raw/transactions

Every transaction on Fantom — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex.trades on flare
Source: https://docs.dune.com/data-catalog/evm/flare/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on flare.

<DexTradesSnippet />


# NFT.trades on flare
Source: https://docs.dune.com/data-catalog/evm/flare/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on flare.

<NFTTradesSnippet />


# Flare Call Tables
Source: https://docs.dune.com/data-catalog/evm/flare/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Flare network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# flare.contracts
Source: https://docs.dune.com/data-catalog/evm/flare/decoded/contracts

Verified contract registry on Flare — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs
Source: https://docs.dune.com/data-catalog/evm/flare/decoded/event-logs

Smart Contracts emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# flare.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/flare/decoded/logs-decoded

ABI-decoded event logs on Flare — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Flare Chain Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/flare/decoded/overview

Simplifying Flare Chain smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# flare.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/flare/decoded/traces-decoded

ABI-decoded function calls on Flare — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Flare Chain Overview
Source: https://docs.dune.com/data-catalog/evm/flare/overview

Flare blockchain data on Dune

## What is Flare?

Flare is a layer 1, EVM-compatible smart contract platform that redefines the utility of blockchain by making data a public good. It is uniquely designed to provide developers with efficient access to extensive data resources, facilitating the creation of sophisticated applications in various domains such as DeFi, gaming, NFTs, music, social networks, real world assets, machine learning, and artificial intelligence.

## Key Features of Flare

Flare stands out by integrating robust data protocols directly into its blockchain architecture, offering developers powerful tools to leverage data efficiently and cost-effectively.

### **Data as a Public Good**

At the core of Flare’s philosophy is the provision of data as a public good. This ensures that data is accessible without central control, fostering an environment of openness and innovation.

### **Dual Role Infrastructure Providers**

Infrastructure providers on Flare serve a dual role as validators and data providers. This integration allows Flare to offer its unique native oracles: the Flare Time-Series Oracle (FTSO) and the Flare Data Connector.

### **Developing on Flare**

Developers interested in building on Flare can find comprehensive resources and guides at the Flare Developer Hub. This hub provides tools, documentation, and support to help developers create, test, and deploy their applications on Flare’s network.

## Flare Networks and chains

Flare encompasses several networks, each designed for specific functions and stages of development:

* **Flare:** The main network with \$FLR as the native currency.
* **Songbird:** The canary network where \$SGB is the native currency, used for real condition testing before mainnet deployment.
* **Coston:** The public test network for developers using Songbird.
* **Coston2:** The public test network for developers using Flare.

Flare operates on two primary chains:

* **C-Chain (Contract Chain):** Hosts smart contracts and is powered by the EVM, facilitating most of the community interactions.
* **P-Chain (Platform Chain):** Manages staking and rewards distribution among validators.

## Security and Governance

Flare integrates advanced security protocols and a decentralized governance model, allowing \$FLR token holders to participate in network decisions. This inclusive approach ensures that Flare adapts to the evolving needs of its users and developers.

<CardGroup>
  <Card title="Flare Documentation" icon="link" href="https://docs.flare.network/">
    Explore the complete documentation for Flare.
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Explore detailed logs and operational data on Flare, emphasizing transparency and access to real-time network activities and oracle updates.
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    View insights into Flare's block production and consensus mechanism, highlighting the efficiency and security of the state connector and its impact on blockchain finality.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Dive into transaction data to experience Flare’s innovative zero-gas mechanism, showcasing how it facilitates cost-effective and accessible blockchain interactions.
  </Card>

  <Card title="Decoded" icon="file" href="./decoded/overview">
    Access decoded transaction data to gain insights into the seamless integration of FAssets and interactions across Flare's unique app chains, driving a new era of blockchain utility.
  </Card>
</CardGroup>


# flare.blocks
Source: https://docs.dune.com/data-catalog/evm/flare/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Flare.

<BlockSnippet />


# flare.creation_traces
Source: https://docs.dune.com/data-catalog/evm/flare/raw/creation-traces

Contract deployment records on Flare — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# flare.logs
Source: https://docs.dune.com/data-catalog/evm/flare/raw/logs

Smart contract event logs on Flare — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# flare.traces
Source: https://docs.dune.com/data-catalog/evm/flare/raw/traces

Internal transaction traces on Flare — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# flare.transactions
Source: https://docs.dune.com/data-catalog/evm/flare/raw/transactions

Every transaction on Flare — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex_aggregator.trades on gnosis
Source: https://docs.dune.com/data-catalog/evm/gnosis/curated-data/dex/dex-aggregator-trades

DEX aggregator swaps on Gnosis — trades routed through aggregators like 1inch, Paraswap, and CoW Swap with pricing and routing details.

<DexAggregatorTradesSnippet />


# dex.trades on gnosis
Source: https://docs.dune.com/data-catalog/evm/gnosis/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on gnosis.

<DexTradesSnippet />


# NFT.trades on gnosis
Source: https://docs.dune.com/data-catalog/evm/gnosis/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on gnosis.

<NFTTradesSnippet />


# Gnosis Chain Call Tables
Source: https://docs.dune.com/data-catalog/evm/gnosis/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Gnosis Chain network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# gnosis.contracts
Source: https://docs.dune.com/data-catalog/evm/gnosis/decoded/contracts

Verified contract registry on Gnosis — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs
Source: https://docs.dune.com/data-catalog/evm/gnosis/decoded/event-logs

Smart Contracts emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# gnosis.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/gnosis/decoded/logs-decoded

ABI-decoded event logs on Gnosis — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Gnosis Chain Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/gnosis/decoded/overview

Simplifying Gnosis Chain smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# gnosis.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/gnosis/decoded/traces-decoded

ABI-decoded function calls on Gnosis — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Gnosis Chain Overview
Source: https://docs.dune.com/data-catalog/evm/gnosis/overview

Gnosis Chain data on Dune

Gnosis Chain is a Layer 2 scaling solution designed for Ethereum, focusing on creating a low-cost, high-efficiency platform for decentralized applications (dApps). Formerly known as xDai Chain, Gnosis Chain emphasizes predictability in transaction costs, which are paid in the native stablecoin, xDAI.

This platform uses a unique consensus mechanism called POSDAO, which is a Proof of Stake system that provides enhanced security and scalability while supporting environmental sustainability. Gnosis Chain is compatible with Ethereum, allowing Ethereum assets and projects to transition smoothly without the need for code changes.

**Cost Efficiency and Predictability:**
Transaction costs on Gnosis Chain are highly predictable, making it an attractive platform for developers and businesses that require consistent budgeting for blockchain operations.

**Ethereum Compatibility:**
Full compatibility with Ethereum ensures that developers can leverage existing tools and infrastructures to deploy and manage their applications on Gnosis Chain with minimal adjustments.

<CardGroup>
  <Card title="Gnosis Chain documentation" icon="link" href="https://docs.gnosischain.com">
    Explore the official documentation for Gnosis Chain, which provides a deep dive into its consensus mechanism, network features, and how to develop on the platform.
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Event logs from smart contracts, offering detailed insights into interactions and activities within the Gnosis Chain network.
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Data on blocks processed, illustrating the network’s capacity and the performance of its POSDAO system.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Comprehensive transaction data, showcasing the efficiency and cost-effectiveness of operations on Gnosis Chain.
  </Card>

  <Card title="decoded" icon="file" href="./decoded/overview">
    Decoded transaction data for easier analysis and better understanding of contract executions on Gnosis Chain.
  </Card>
</CardGroup>


# gnosis.blocks
Source: https://docs.dune.com/data-catalog/evm/gnosis/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Gnosis.

<BlockSnippet />


# gnosis.creation_traces
Source: https://docs.dune.com/data-catalog/evm/gnosis/raw/creation-traces

Contract deployment records on Gnosis — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# gnosis.logs
Source: https://docs.dune.com/data-catalog/evm/gnosis/raw/logs

Smart contract event logs on Gnosis — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# gnosis.traces
Source: https://docs.dune.com/data-catalog/evm/gnosis/raw/traces

Internal transaction traces on Gnosis — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# gnosis.transactions
Source: https://docs.dune.com/data-catalog/evm/gnosis/raw/transactions

Every transaction on Gnosis — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex.trades on hemi
Source: https://docs.dune.com/data-catalog/evm/hemi/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on hemi.

<DexTradesSnippet />


# Hemi Call Tables
Source: https://docs.dune.com/data-catalog/evm/hemi/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Hemi network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# hemi.contracts
Source: https://docs.dune.com/data-catalog/evm/hemi/decoded/contracts

Verified contract registry on Hemi — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# hemi.event_logs
Source: https://docs.dune.com/data-catalog/evm/hemi/decoded/event-logs

Smart contract event logs on Hemi — indexed topics and data fields emitted during transaction execution.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# hemi.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/hemi/decoded/logs-decoded

ABI-decoded event logs on Hemi — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Hemi Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/hemi/decoded/overview

Simplifying Hemi smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# hemi.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/hemi/decoded/traces-decoded

ABI-decoded function calls on Hemi — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Hemi Overview
Source: https://docs.dune.com/data-catalog/evm/hemi/overview

Hemi data on Dune

## What is Hemi?

Hemi is a modular Layer-2 protocol that provides superior scaling, security, and interoperability by combining the power of Bitcoin and Ethereum. Unlike other projects that treat Bitcoin and Ethereum as separate ecosystem silos, Hemi views them as components of a single supernetwork, unlocking new levels of programmability, portability, and potential.

## Key Features

* **Bitcoin-Ethereum Integration**: Combines Bitcoin and Ethereum as components of a supernetwork
* **Hemi Virtual Machine (hVM)**: Incorporates a full Bitcoin node within an Ethereum Virtual Machine
* **Proof-of-Proof (PoP) Consensus**: Ensures transactions surpass Bitcoin's security level in hours
* **Trustless Cross-chain Portability**: Secure asset transfers between Hemi and other chains via "Tunnels"
* **Bitcoin Programmability**: Smart contracts with granular indexed views of Bitcoin state
* **Extensibility**: Allows external projects to create chains secured by Hemi's technology

## Ecosystem Highlights

* Modular Layer-2 protocol for superior scaling and security
* Full integration of Bitcoin and Ethereum ecosystems
* Advanced on-chain functionalities including routing, time-lock, and password protection
* Bitcoin-Security-as-a-Service capabilities
* Enhanced dual-chain interoperability and asset handling

## Data on Dune

<CardGroup>
  <Card title="Raw Data" icon="database" href="/data-catalog/evm/hemi/raw/blocks">
    Access to raw blockchain data including blocks, transactions, logs, and traces
  </Card>

  <Card title="Decoded Data" icon="code" href="/data-catalog/evm/hemi/decoded/overview">
    Human-readable contract interactions and events
  </Card>
</CardGroup>

## Resources

<CardGroup>
  <Card title="Hemi Documentation" icon="link" href="https://docs.hemi.xyz/">
    Official documentation for developers building on Hemi
  </Card>
</CardGroup>


# hemi.blocks
Source: https://docs.dune.com/data-catalog/evm/hemi/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Hemi.

<BlockSnippet />


# hemi.creation_traces
Source: https://docs.dune.com/data-catalog/evm/hemi/raw/creation-traces

Contract deployment records on Hemi — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# hemi.logs
Source: https://docs.dune.com/data-catalog/evm/hemi/raw/logs

Smart contract event logs on Hemi — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# hemi.traces
Source: https://docs.dune.com/data-catalog/evm/hemi/raw/traces

Internal transaction traces on Hemi — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# hemi.transactions
Source: https://docs.dune.com/data-catalog/evm/hemi/raw/transactions

Every transaction on Hemi — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# Henesys Call Tables
Source: https://docs.dune.com/data-catalog/evm/henesys/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Henesys network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# henesys.contracts
Source: https://docs.dune.com/data-catalog/evm/henesys/decoded/contracts

Verified contract registry on Henesys — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# henesys.event_logs
Source: https://docs.dune.com/data-catalog/evm/henesys/decoded/event-logs

Smart contract event logs on Henesys — indexed topics and data fields emitted during transaction execution.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# henesys.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/henesys/decoded/logs-decoded

ABI-decoded event logs on Henesys — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Henesys Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/henesys/decoded/overview

Simplifying Henesys smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# henesys.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/henesys/decoded/traces-decoded

ABI-decoded function calls on Henesys — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Henesys Overview
Source: https://docs.dune.com/data-catalog/evm/henesys/overview

Henesys data on Dune

## What is Henesys?

Henesys is Avalanche's Layer 1 blockchain that powers the NEXPACE ecosystem and the MapleStory Universe. Built by Nexon's blockchain subsidiary, Henesys provides a secure, scalable platform for Web3 gaming, enabling player-owned economies, decentralized governance, and cross-chain interoperability through Chainlink's CCIP integration.

## Key Features

* **Gaming-Focused Infrastructure**: Specialized blockchain for Web3 gaming and NFT ecosystems
* **Avalanche L1**: Built on Avalanche for high performance and scalability
* **Player-Owned Economies**: Enables true ownership of in-game assets through NFTs
* **Fusion-Fission Model**: Dynamic NFT/item supply balancing mechanism
* **Cross-Chain Interoperability**: Chainlink CCIP integration for secure NFT portability across games

## Ecosystem Highlights

* MapleStory Universe integration with blockchain technology
* NFT minting and trading for in-game assets
* Synergy Apps ecosystem with open APIs for third-party developers
* Support for various gaming use cases including:
  * In-game item tokenization
  * Player-to-player trading
  * Cross-game asset portability
  * Prediction markets and dashboards
  * Community-driven tooling

## Data on Dune

<CardGroup>
  <Card title="Raw Data" icon="database" href="/data-catalog/evm/henesys/raw/blocks">
    Access to raw blockchain data including blocks, transactions, logs, and traces
  </Card>

  <Card title="Decoded Data" icon="code" href="/data-catalog/evm/henesys/decoded/overview">
    Human-readable contract interactions and events
  </Card>
</CardGroup>

## Resources

<CardGroup>
  <Card title="NEXPACE Documentation" icon="link" href="https://coinmarketcap.com/cmc-ai/maplestory-universe/what-is/">
    Learn more about the NEXPACE ecosystem and MapleStory Universe
  </Card>
</CardGroup>


# henesys.blocks
Source: https://docs.dune.com/data-catalog/evm/henesys/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Henesys.

<BlockSnippet />


# henesys.creation_traces
Source: https://docs.dune.com/data-catalog/evm/henesys/raw/creation-traces

Contract deployment records on Henesys — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# henesys.logs
Source: https://docs.dune.com/data-catalog/evm/henesys/raw/logs

Smart contract event logs on Henesys — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# henesys.traces
Source: https://docs.dune.com/data-catalog/evm/henesys/raw/traces

Internal transaction traces on Henesys — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# henesys.transactions
Source: https://docs.dune.com/data-catalog/evm/henesys/raw/transactions

Every transaction on Henesys — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex.trades on hyperevm
Source: https://docs.dune.com/data-catalog/evm/hyperevm/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on hyperevm.

<DexTradesSnippet />


# hyperevm.contracts
Source: https://docs.dune.com/data-catalog/evm/hyperevm/decoded/contracts

Verified contract registry on HyperEVM — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# hyperevm.event_logs
Source: https://docs.dune.com/data-catalog/evm/hyperevm/decoded/event-logs

Smart contract event logs on HyperEVM — indexed topics and data fields emitted during transaction execution.

<EventLogsSnippet />


# hyperevm.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/hyperevm/decoded/logs-decoded

ABI-decoded event logs on HyperEVM — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# HyperEVM Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/hyperevm/decoded/overview

Simplifying HyperEVM smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# HyperEVM Overview
Source: https://docs.dune.com/data-catalog/evm/hyperevm/overview

HyperEVM data on Dune

## What is HyperEVM?

HyperEVM is the EVM-compatible layer of the Hyperliquid blockchain, which features a dual-block architecture with HyperCore and HyperEVM. The HyperEVM is not a separate chain, but rather secured by the same HyperBFT consensus as HyperCore, allowing it to interact directly with HyperCore's spot and perpetual order books.

## Key Features

* **Dual-Block Architecture**: Combines HyperCore (for trading) and HyperEVM (for smart contracts)
* **EVM-Compatible**: Full compatibility with Ethereum smart contracts and tooling
* **Direct Order Book Access**: Smart contracts can read prices and execute trades directly on HyperCore
* **Permissionless Asset Deployment**: Projects can deploy ERC20 contracts and corresponding spot assets
* **Unified State**: No bridging risk between HyperCore and HyperEVM
* **Mature Liquidity**: Access to established, liquid onchain order books
* **Captive Audience**: Built-in user base excited about onchain finance

## Technical Capabilities

* **Read Precompiles**: Smart contracts can read prices directly from HyperCore order books
* **Write System Contracts**: Contracts can send orders directly to HyperCore order books
* **Protocolized Liquidations**: Lending protocols can implement automated liquidations
* **Native Token Integration**: Seamless connection between HyperEVM contracts and HyperCore trading

## Use Cases

* **DeFi Protocols**: Lending, borrowing, and automated trading strategies
* **Token Projects**: Permissionless listing and trading of new assets
* **Trading Bots**: Direct access to order books for algorithmic trading
* **Cross-Protocol Integration**: Seamless interaction between different DeFi applications

## Current Status

HyperEVM is currently in alpha stage with a gradual roll-out approach to ensure:

* Equal access for all developers (no insiders)
* Safe system upgrades for high-volume trading
* Live iteration based on user feedback

## Data on Dune

We currently don't support traces yet for hyperEVM so compared to usual EVM support we will not have:

* Traces
* Traces\_decoded
* "Enable bytecode matching" decoding feature
* "Decode other contracts created by the same factory" decoding feature

<CardGroup>
  <Card title="Raw Data" icon="database" href="/data-catalog/evm/hyperevm/raw/blocks">
    Access to raw blockchain data including blocks, transactions, and logs
  </Card>

  <Card title="Decoded Data" icon="code" href="/data-catalog/evm/hyperevm/decoded/overview">
    Human-readable contract interactions and events
  </Card>
</CardGroup>

## Resources

<CardGroup>
  <Card title="Hyperliquid Documentation" icon="link" href="https://hyperliquid.gitbook.io/hyperliquid-docs/hyperevm">
    Official documentation for developers building on HyperEVM
  </Card>
</CardGroup>


# hyperevm.blocks
Source: https://docs.dune.com/data-catalog/evm/hyperevm/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for HyperEVM.

<BlockSnippet />


# hyperevm.logs
Source: https://docs.dune.com/data-catalog/evm/hyperevm/raw/logs

Smart contract event logs on HyperEVM — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# hyperevm.transactions
Source: https://docs.dune.com/data-catalog/evm/hyperevm/raw/transactions

Every transaction on HyperEVM — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex_aggregator.trades on ink
Source: https://docs.dune.com/data-catalog/evm/ink/curated-data/dex/dex-aggregator-trades

DEX aggregator swaps on Ink — trades routed through aggregators like 1inch, Paraswap, and CoW Swap with pricing and routing details.

<DexAggregatorTradesSnippet />


# dex.trades on ink
Source: https://docs.dune.com/data-catalog/evm/ink/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on ink.

<DexTradesSnippet />


# NFT.trades on ink
Source: https://docs.dune.com/data-catalog/evm/ink/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on ink.

<NFTTradesSnippet />


# Ink Call Tables
Source: https://docs.dune.com/data-catalog/evm/ink/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Ink network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# ink.contracts
Source: https://docs.dune.com/data-catalog/evm/ink/decoded/contracts

Verified contract registry on Ink — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs
Source: https://docs.dune.com/data-catalog/evm/ink/decoded/event-logs

Smart Contracts emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# ink.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/ink/decoded/logs-decoded

ABI-decoded event logs on Ink — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Ink Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/ink/decoded/overview

Simplifying Ink smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# ink.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/ink/decoded/traces-decoded

ABI-decoded function calls on Ink — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Ink Overview
Source: https://docs.dune.com/data-catalog/evm/ink/overview

Ink data on Dune

## What is Ink?

Ink is Kraken's dedicated DeFi chain, built as a Layer 2 solution using the OP Stack technology. As part of the Superchain ecosystem, it provides a scalable, secure environment for decentralized finance applications while maintaining full compatibility with the Ethereum ecosystem.

## Technical Architecture

Ink's architecture leverages the OP Stack to deliver a robust DeFi-focused platform:

### Optimistic Rollup Technology

* Inherits Ethereum's security through optimistic rollups
* Posts transaction data to Ethereum mainnet
* Uses fraud proofs for security guarantees
* Provides fast transaction finality with L2 execution

### Network Specifications

* **Technology Stack**: OP Stack (Superchain)
* **Gas Token**: ETH
* **Challenge Period**: \~7 days
* **Block Time**: \~2 seconds
* **Network Type**: EVM-compatible Layer 2

### Developer Tools & Infrastructure

* **Smart Contract Development**: Support for Foundry, Hardhat, and Remix
* **Block Explorers**: Multiple options for transaction monitoring
* **Infrastructure**:
  * Account Abstraction support
  * Cross-chain bridges
  * Oracle integration
  * VRF capabilities
  * Indexing services

### Compatibility & Integration

* Full EVM compatibility
* Native bridge functionality
* Support for standard Ethereum development tools
* Seamless integration with existing Ethereum infrastructure

<CardGroup>
  <Card title="Ink Documentation" icon="link" href="https://docs.inkonchain.com">
    Official documentation for developers building on Ink - Kraken's DeFi chain
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Insights into smart contract interactions through event logs
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on blocks processed on Ink
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Detailed data on transactions
  </Card>

  <Card title="decoded" icon="file" href="./decoded/overview">
    Decoded transaction information for enhanced analysis
  </Card>
</CardGroup>


# ink.blocks
Source: https://docs.dune.com/data-catalog/evm/ink/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Ink.

<BlockSnippet />


# ink.creation_traces
Source: https://docs.dune.com/data-catalog/evm/ink/raw/creation-traces

Contract deployment records on Ink — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# ink.logs
Source: https://docs.dune.com/data-catalog/evm/ink/raw/logs

Smart contract event logs on Ink — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# ink.traces
Source: https://docs.dune.com/data-catalog/evm/ink/raw/traces

Internal transaction traces on Ink — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# ink.transactions
Source: https://docs.dune.com/data-catalog/evm/ink/raw/transactions

Every transaction on Ink — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex.trades on kaia
Source: https://docs.dune.com/data-catalog/evm/kaia/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on kaia.

<DexTradesSnippet />


# NFT.trades on kaia
Source: https://docs.dune.com/data-catalog/evm/kaia/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on kaia.

<NFTTradesSnippet />


# KAIA Call Tables
Source: https://docs.dune.com/data-catalog/evm/kaia/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the KAIA network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# kaia.contracts
Source: https://docs.dune.com/data-catalog/evm/kaia/decoded/contracts

Verified contract registry on KAIA — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs
Source: https://docs.dune.com/data-catalog/evm/kaia/decoded/event-logs

Smart Contracts emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# kaia.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/kaia/decoded/logs-decoded

ABI-decoded event logs on KAIA — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# KAIA Chain Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/kaia/decoded/overview

Simplifying KAIA Chain smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# kaia.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/kaia/decoded/traces-decoded

ABI-decoded function calls on KAIA — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# KAIA Chain Overview
Source: https://docs.dune.com/data-catalog/evm/kaia/overview

KAIA blockchain data on Dune

## What is KAIA?

KAIA is a highly optimized, BFT-based public blockchain designed to meet the performance and reliability needs of enterprises. With features like immediate finality, high transaction throughput, and EVM compatibility, KAIA provides a robust infrastructure for blockchain applications across industries.

KAIA’s network architecture and consensus mechanism prioritize security and scalability, making it a preferred choice for businesses looking to deploy fast, cost-effective, and scalable blockchain solutions.

## Key Features of KAIA

KAIA’s infrastructure is built around a few core design goals, ensuring its suitability for enterprise and real-world use cases. These goals drive the performance and flexibility of the blockchain.

### **Immediate Finality and High Throughput**

KAIA enables 1-second block generation, confirming transactions with immediate finality. The network supports up to **4,000 transactions per second (TPS)**, providing the speed and reliability needed for real-time applications.

### **Low-Cost Transactions**

KAIA offers transaction costs at approximately 1/10th the price of Ethereum, making it more accessible for businesses and developers looking to scale operations without high gas fees.

### **EVM Compatibility**

KAIA is fully compatible with the Ethereum Virtual Machine (EVM), supporting Solidity contracts. This makes it easy for Ethereum developers to migrate their applications to KAIA with minimal changes, leveraging familiar tools like Remix, Hardhat, and Foundry.

## Network Architecture

KAIA’s network architecture is divided into three logical subnetworks that work together to ensure high performance, scalability, and efficient resource utilization.

* **Core Cell Network (CCN):** Responsible for transaction verification, block creation, and execution.
* **Endpoint Node Network (ENN):** Handles API requests and processes data for auxiliary service chains.
* **Service Chain Network (SCN):** Operates independently while connected to the main chain, enabling scalable dApp development.

### **Node Types in KAIA**

KAIA employs a tiered architecture with several types of nodes, each serving specific roles:

* **Consensus Node (CN):** Generates blocks and participates in the consensus process.
* **Proxy Node (PN):** Handles transaction requests and network communication.
* **Endpoint Node (EN):** Processes API requests and ensures data flow for service chains.

## Consensus Mechanism

KAIA utilizes an optimized version of Istanbul BFT (Practical Byzantine Fault Tolerance) for its consensus. This ensures:

* **Fast Block Finality:** No forks or transaction reversals, providing certainty for real-time applications.
* **Verifiable Random Function (VRF):** Used for selecting block proposers, adding randomness to enhance security and decentralization.

## Security and Interoperability

KAIA incorporates several security measures to protect the integrity of its network:

* **Validator Key Separation:** Ensures that keys used for validation are kept separate from reward keys, reducing the risk of key theft.
* **Cross-Chain Compatibility:** EVM compatibility allows KAIA to interoperate with other EVM-based chains, supporting cross-chain transactions and smart contract execution.

## Token Economy

KAIA’s native token, **KAIA**, plays a central role in its economy:

* **Block Rewards:** Distributed to validators and stakers to incentivize network participation.
* **Inflation Rate:** Initially set at 5.2% annually, with block rewards allocated between creators, stakers, and ecosystem funds to support development and infrastructure.

## Governance and Transparency

KAIA operates with an on-chain governance system where voting power is based on staked KAIA tokens. Governance ensures:

* **Fair Representation:** Voting rights are capped to prevent dominance by large stakeholders.
* **Delegation Allowed:** Token holders can delegate voting power to trusted representatives.
* **Transparency:** All governance proposals and transactions are recorded on-chain, ensuring full auditability.

## Why KAIA?

KAIA is built to lead Web3 adoption in Asia by offering high-performance, low-cost infrastructure for businesses of all sizes. It provides real-world asset (RWA) linkage, abundant liquidity support, and convenient development tools, making it an attractive platform for decentralized applications across various sectors.

<CardGroup>
  <Card title="KAIA documentation" icon="link" href="https://docs.kaia.io/learn/">
    Access comprehensive documentation for KAIA, providing detailed insights into its zk-Rollup technology, platform architecture, and how to build on it.
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Detailed event logs from smart contracts, offering insights into contract interactions and the dynamics of kaia's zk-Rollup operations.
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on blocks processed through KAIA’s zk-Rollups, illustrating the network's enhanced throughput and scalability.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Extensive transaction data, highlighting the efficiency and reduced costs of operations on kaia.
  </Card>

  <Card title="decoded" icon="file" href="./decoded/overview">
    Decoded transaction data for easier analysis and deeper understanding of smart contract executions on the kaia network.
  </Card>
</CardGroup>


# kaia.blocks
Source: https://docs.dune.com/data-catalog/evm/kaia/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for KAIA.

<BlockSnippet />


# kaia.creation_traces
Source: https://docs.dune.com/data-catalog/evm/kaia/raw/creation-traces

Contract deployment records on KAIA — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# kaia.logs
Source: https://docs.dune.com/data-catalog/evm/kaia/raw/logs

Smart contract event logs on KAIA — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# kaia.traces
Source: https://docs.dune.com/data-catalog/evm/kaia/raw/traces

Internal transaction traces on KAIA — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# kaia.transactions
Source: https://docs.dune.com/data-catalog/evm/kaia/raw/transactions

Every transaction on KAIA — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex_aggregator.trades on katana
Source: https://docs.dune.com/data-catalog/evm/katana/curated-data/dex/dex-aggregator-trades

DEX aggregator swaps on Katana — trades routed through aggregators like 1inch, Paraswap, and CoW Swap with pricing and routing details.

<DexAggregatorTradesSnippet />


# dex.trades on katana
Source: https://docs.dune.com/data-catalog/evm/katana/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on DEX trade events across various protocols on katana.

<DexTradesSnippet />


# Call Tables
Source: https://docs.dune.com/data-catalog/evm/katana/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# katana.contracts
Source: https://docs.dune.com/data-catalog/evm/katana/decoded/contracts

Verified contract registry on Katana — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs
Source: https://docs.dune.com/data-catalog/evm/katana/decoded/event-logs

Smart Contracts emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# katana.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/katana/decoded/logs-decoded

ABI-decoded event logs on Katana — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Decoded Data Overview
Source: https://docs.dune.com/data-catalog/evm/katana/decoded/overview

Overview of decoded data on Katana

<OverviewDecodedDataApproach />


# katana.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/katana/decoded/traces-decoded

ABI-decoded function calls on Katana — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Katana Overview
Source: https://docs.dune.com/data-catalog/evm/katana/overview

Katana data on Dune

## What is Katana?

Katana is a high-performance blockchain platform designed for scalability and developer experience. It provides a robust infrastructure for building decentralized applications with advanced features and optimized performance.

## Key Features

### High Performance

* Optimized for high-frequency trading and DeFi applications
* Supports thousands of transactions per second
* Low latency transaction confirmations

### Developer Experience

* Full EVM compatibility with enhanced capabilities
* Comprehensive developer tools and SDKs
* Easy deployment and management of smart contracts

### Security and Infrastructure

* Robust security model with multiple layers of protection
* Advanced cryptographic protocols for transaction validation
* Distributed network architecture for enhanced reliability

<CardGroup>
  <Card title="Katana Documentation" icon="link" href="https://app.katana.network/krates">
    Official documentation and resources for developers building on Katana
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Insights into smart contract interactions through event logs
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on blocks processed on Katana
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Detailed data on transactions
  </Card>

  <Card title="decoded" icon="file" href="./decoded/overview">
    Decoded transaction information for enhanced analysis
  </Card>
</CardGroup>


# katana.blocks
Source: https://docs.dune.com/data-catalog/evm/katana/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Katana.

<BlockSnippet />


# katana.creation_traces
Source: https://docs.dune.com/data-catalog/evm/katana/raw/creation-traces

Contract deployment records on Katana — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# katana.logs
Source: https://docs.dune.com/data-catalog/evm/katana/raw/logs

Smart contract event logs on Katana — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# katana.traces
Source: https://docs.dune.com/data-catalog/evm/katana/raw/traces

Internal transaction traces on Katana — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# katana.transactions
Source: https://docs.dune.com/data-catalog/evm/katana/raw/transactions

Every transaction on Katana — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex.trades on lens
Source: https://docs.dune.com/data-catalog/evm/lens/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on lens.

<Warning>
  **Deprecation Notice**: Lens data ingestion has been discontinued as of December 2025. Only historical data is available, and no new data will be added.
</Warning>

<DexTradesSnippet />


# NFT.trades on lens
Source: https://docs.dune.com/data-catalog/evm/lens/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on lens.

<Warning>
  **Deprecation Notice**: Lens data ingestion has been discontinued as of December 2025. Only historical data is available, and no new data will be added.
</Warning>

<NFTTradesSnippet />


# Lens Call Tables
Source: https://docs.dune.com/data-catalog/evm/lens/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Lens network in their own tables.

<Warning>
  **Deprecation Notice**: Lens data ingestion has been discontinued as of December 2025. Only historical data is available, and no new data will be added.
</Warning>

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# lens.contracts
Source: https://docs.dune.com/data-catalog/evm/lens/decoded/contracts

Verified contract registry on Lens — contract name, namespace, ABI, and deployment metadata.

<Warning>
  **Deprecation Notice**: Lens data ingestion has been discontinued as of December 2025. Only historical data is available, and no new data will be added.
</Warning>

<ContractsSnippet />


# Event Logs
Source: https://docs.dune.com/data-catalog/evm/lens/decoded/event-logs

Smart Contracts emit event logs when certain predefined actions are completed.

<Warning>
  **Deprecation Notice**: Lens data ingestion has been discontinued as of December 2025. Only historical data is available, and no new data will be added.
</Warning>

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# lens.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/lens/decoded/logs-decoded

ABI-decoded event logs on Lens — human-readable event names and parsed parameters from verified contracts.

<Warning>
  **Deprecation Notice**: Lens data ingestion has been discontinued as of December 2025. Only historical data is available, and no new data will be added.
</Warning>

<LogsDecodedSnippet />


# Lens Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/lens/decoded/overview

Simplifying Lens smart contract analysis through human-readable tables.

<Warning>
  **Deprecation Notice**: Lens data ingestion has been discontinued as of December 2025. Only historical data is available, and no new data will be added.
</Warning>

<Warning>
  Due to bugs in the Lens client, some contract creation traces are missing, and data in the code field is incomplete for certain blocks. Consequently, we cannot support factory and bytecode matching for this chain. Once the bugs are addressed, we will work to restore this functionality. We apologize for the inconvenience.
</Warning>

<OverviewDecodedDataApproach />


# lens.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/lens/decoded/traces-decoded

ABI-decoded function calls on Lens — parsed function names, inputs, and outputs from verified contracts.

<Warning>
  **Deprecation Notice**: Lens data ingestion has been discontinued as of December 2025. Only historical data is available, and no new data will be added.
</Warning>

<TracesDecodedSnippet />


# Lens Overview
Source: https://docs.dune.com/data-catalog/evm/lens/overview

Lens data on Dune

<Warning>
  **Deprecation Notice**: Starting from the 19th of December 2025 Dune is not live ingesting and indexing Lens data. The historical data of the chain will remain available to be used.
</Warning>

Lens is a ZK chain that combines social primitives with a simple user experience and high scalability. Built on ZK technology, Lens Chain aims to bring SocialFi accessibility to a wider audience while maintaining robust security and performance.

**Architecture and Technology:**

* **ZKSync**: A ZK-based scaling solution that provides high throughput and security
* **Social Protocol**: Core social primitives for building social applications
* **Storage Nodes**: Decentralized storage with centralized performance
* **Account Abstraction**: Built-in support for smart accounts and improved user experience

**Enhanced User Experience:**
Lens focuses on simplifying the blockchain experience while maintaining high performance. The platform is designed to make social applications accessible to everyday users while providing the tools and infrastructure developers need to build sophisticated applications.

**Developer-Centric Approach:**
The platform provides a comprehensive environment for developers to build and deploy applications, with native support for advanced features like account abstraction and paymaster functionality, enabling more sophisticated and user-friendly dApps.

<CardGroup>
  <Card title="Lens documentation" icon="link" href="https://lens.xyz/docs/chain/overview">
    Access the official documentation for Lens to explore its architecture, features, and development resources.
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Event logs from smart contracts, providing insights into interactions and activities on the Lens network.
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on blocks processed using Lens's ZK technology, reflecting the network's capacity for high transaction throughput.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Detailed transaction data, showcasing the operational efficiency and cost-effectiveness of Lens's validium solution.
  </Card>

  <Card title="decoded" icon="file" href="./decoded/overview">
    Decoded transaction data for easier analysis and better understanding of smart contract executions on Lens.
  </Card>
</CardGroup>


# lens.blocks
Source: https://docs.dune.com/data-catalog/evm/lens/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Lens.

<Warning>
  **Deprecation Notice**: Lens data ingestion has been discontinued as of December 2025. Only historical data is available, and no new data will be added.
</Warning>

<BlockSnippet />


# lens.creation_traces
Source: https://docs.dune.com/data-catalog/evm/lens/raw/creation-traces

Contract deployment records on Lens — deployer address, factory context, and deployed bytecode.

<Warning>
  **Deprecation Notice**: Lens data ingestion has been discontinued as of December 2025. Only historical data is available, and no new data will be added.
</Warning>

<CreationTracesSnippet />


# lens.logs
Source: https://docs.dune.com/data-catalog/evm/lens/raw/logs

Smart contract event logs on Lens — indexed topics and data fields from token transfers, swaps, and protocol actions.

<Warning>
  **Deprecation Notice**: Lens data ingestion has been discontinued as of December 2025. Only historical data is available, and no new data will be added.
</Warning>

<LogsSnippet />


# lens.traces
Source: https://docs.dune.com/data-catalog/evm/lens/raw/traces

Internal transaction traces on Lens — cross-contract calls, delegate calls, and value transfers with full call stack context.

<Warning>
  **Deprecation Notice**: Lens data ingestion has been discontinued as of December 2025. Only historical data is available, and no new data will be added.
</Warning>

<Warning>
  You may see duplicate records in the `traces` table for the Lens chain. This is not a bug, but a result of trace calls appearing twice within the same transaction. These consecutive calls—an outer and an inner call—are identical except for their gas values. They share the same `from`, `to`, `input`, `output`, `success`, and `value` fields.
</Warning>

<TracesSnippet />


# lens.transactions
Source: https://docs.dune.com/data-catalog/evm/lens/raw/transactions

Every transaction on Lens — from, to, value, gas, calldata, and receipt status.

<Warning>
  **Deprecation Notice**: Lens data ingestion has been discontinued as of December 2025. Only historical data is available, and no new data will be added.
</Warning>

<TransactionsSnippet />


# dex_aggregator.trades on linea
Source: https://docs.dune.com/data-catalog/evm/linea/curated-data/dex/dex-aggregator-trades

DEX aggregator swaps on Linea — trades routed through aggregators like 1inch, Paraswap, and CoW Swap with pricing and routing details.

<DexAggregatorTradesSnippet />


# dex.trades on linea
Source: https://docs.dune.com/data-catalog/evm/linea/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on linea.

<DexTradesSnippet />


# NFT.trades on linea
Source: https://docs.dune.com/data-catalog/evm/linea/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on linea.

<NFTTradesSnippet />


# Linea Call Tables
Source: https://docs.dune.com/data-catalog/evm/linea/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Linea network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# linea.contracts
Source: https://docs.dune.com/data-catalog/evm/linea/decoded/contracts

Verified contract registry on Linea — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs
Source: https://docs.dune.com/data-catalog/evm/linea/decoded/event-logs

Smart Contracts emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# linea.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/linea/decoded/logs-decoded

ABI-decoded event logs on Linea — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Linea Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/linea/decoded/overview

Simplifying Linea smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# linea.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/linea/decoded/traces-decoded

ABI-decoded function calls on Linea — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Linea Overview
Source: https://docs.dune.com/data-catalog/evm/linea/overview

Linea data on Dune

Linea is an EVM-equivalent network, scaling the Ethereum experience. Secured with a zero-knowledge rollup to Ethereum, built on lattice-based cryptography, and powered by Consensys. Linea behaves like Ethereum, but with a higher throughput and lower fees.

<CardGroup>
  <Card title="Linea docs" icon="link" href="https://https://docs.linea.build/">
    The official documentation for Linea, providing detailed information on the protocol, architecture, and developer resources
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="/data-catalog/evm/linea/raw/logs">
    Event logs from smart contracts, providing insights into contract interactions
  </Card>

  <Card title="Blocks" icon="cubes" href="/data-catalog/evm/linea/raw/blocks">
    Information and statistics on blocks, showcasing the network's activity and throughput
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="/data-catalog/evm/linea/raw/transactions">
    Detailed transaction data, highlighting the execution and efficiency of operations
  </Card>

  <Card title="Decoded" icon="file" href="/data-catalog/evm/linea/decoded/overview">
    Decoded transaction data for easier understanding and analysis of smart contract executions
  </Card>
</CardGroup>


# linea.blocks
Source: https://docs.dune.com/data-catalog/evm/linea/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Linea.

<BlockSnippet />


# linea.creation_traces
Source: https://docs.dune.com/data-catalog/evm/linea/raw/creation-traces

Contract deployment records on Linea — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# linea.logs
Source: https://docs.dune.com/data-catalog/evm/linea/raw/logs

Smart contract event logs on Linea — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# linea.traces
Source: https://docs.dune.com/data-catalog/evm/linea/raw/traces

Internal transaction traces on Linea — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# linea.transactions
Source: https://docs.dune.com/data-catalog/evm/linea/raw/transactions

Every transaction on Linea — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex_aggregator.trades on mantle
Source: https://docs.dune.com/data-catalog/evm/mantle/curated-data/dex/dex-aggregator-trades

DEX aggregator swaps on Mantle — trades routed through aggregators like 1inch, Paraswap, and CoW Swap with pricing and routing details.

<DexAggregatorTradesSnippet />


# dex.trades on mantle
Source: https://docs.dune.com/data-catalog/evm/mantle/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on mantle.

<DexTradesSnippet />


# NFT.trades on mantle
Source: https://docs.dune.com/data-catalog/evm/mantle/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on mantle.

<NFTTradesSnippet />


# Mantle Call Tables
Source: https://docs.dune.com/data-catalog/evm/mantle/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Mantle network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# mantle.contracts
Source: https://docs.dune.com/data-catalog/evm/mantle/decoded/contracts

Verified contract registry on Mantle — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs
Source: https://docs.dune.com/data-catalog/evm/mantle/decoded/event-logs

Smart Contracts emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# mantle.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/mantle/decoded/logs-decoded

ABI-decoded event logs on Mantle — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Mantle Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/mantle/decoded/overview

Simplifying Mantle smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# mantle.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/mantle/decoded/traces-decoded

ABI-decoded function calls on Mantle — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Mantle Overview
Source: https://docs.dune.com/data-catalog/evm/mantle/overview

Mantle data on Dune

Mantle Network is dedicated to building an EVM-compatible scaling solution for Ethereum. This means that all contracts and tools running on Ethereum can operate on the Mantle Network with minimal modifications. Taking advantage of its modular architecture, Mantle Network combines an optimistic rollup with various innovative data availability solutions, providing cheaper and more accessible data availability while inheriting the security of Ethereum.

Mantle's design philosophy aims to offer users a less costly and more user-friendly experience, provide developers with a simpler and more flexible development environment, and deliver a comprehensive set of infrastructure for the next wave of mass-adopted dApps.

As an Ethereum L2, Mantle Network offers the security, stability, and scalability necessary to support your onchain applications. Developers can deploy any EVM-compatible codebase and smoothly transition users and assets from Ethereum L1 and other compatible chains.

## Key Features

* **Built as a Rollup**: Utilizes Ethereum validators and consensus protocols to significantly reduce gas fees, decrease latency, and increase throughput. Users can customize transaction confirmation requirements to provide near real-time confirmation latency with minimal security settings.

* **Modular Architecture**: Unlike traditional monolithic chains that execute transaction execution, consensus, settlement, and storage at the same network layer, Mantle separates these functions into individual modules as a modular chain. These include an EVM-compatible execution layer developed by Mantle for transaction execution, a consensus layer and settlement layer completed on Ethereum, and an external DA component (currently Mantle DA powered by EigenDA technology; we will switch to EigenDA upon its mainnet stable launch).

* **Secured by Ethereum**: L2 state transitions are verified by Ethereum validators, undergoing the same consensus and settlement processes as L1 transactions.

* **Modular Data Availability**: Independent DA modules, such as Mantle DA powered by EigenLayer's EigenDA technology. According to internal assessments, this translates to potential cost savings of more than 90% compared to on-chain L1.

<CardGroup>
  <Card title="Mantle documentation" icon="link" href="https://mantle.network/docs">
    Explore comprehensive documentation on Mantle, detailing its architecture, protocol, and resources for developers.
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Detailed event logs from smart contracts, providing insights into interactions within the Mantle network.
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on blocks, illustrating the operational capacity and activity levels on Mantle.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Extensive transaction data, showcasing the efficiency and execution of operations on Mantle.
  </Card>

  <Card title="Decoded" icon="file" href="./decoded/overview">
    Enhanced transaction data decoded for better analysis and understanding of contract executions.
  </Card>
</CardGroup>


# mantle.blocks
Source: https://docs.dune.com/data-catalog/evm/mantle/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Mantle.

<BlockSnippet />


# mantle.creation_traces
Source: https://docs.dune.com/data-catalog/evm/mantle/raw/creation-traces

Contract deployment records on Mantle — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# mantle.logs
Source: https://docs.dune.com/data-catalog/evm/mantle/raw/logs

Smart contract event logs on Mantle — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# mantle.traces
Source: https://docs.dune.com/data-catalog/evm/mantle/raw/traces

Internal transaction traces on Mantle — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# mantle.transactions
Source: https://docs.dune.com/data-catalog/evm/mantle/raw/transactions

Every transaction on Mantle — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex.trades on megaeth
Source: https://docs.dune.com/data-catalog/evm/megaeth/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on megaeth.

<DexTradesSnippet />


# MegaETH Call Tables
Source: https://docs.dune.com/data-catalog/evm/megaeth/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the MegaETH network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# megaeth.contracts
Source: https://docs.dune.com/data-catalog/evm/megaeth/decoded/contracts

Verified contract registry on MegaETH — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# megaeth.event_logs
Source: https://docs.dune.com/data-catalog/evm/megaeth/decoded/event-logs

Smart contract event logs on MegaETH — indexed topics and data fields emitted during transaction execution.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# megaeth.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/megaeth/decoded/logs-decoded

ABI-decoded event logs on MegaETH — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# MegaETH Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/megaeth/decoded/overview

Simplifying MegaETH smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# megaeth.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/megaeth/decoded/traces-decoded

ABI-decoded function calls on MegaETH — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# MegaETH Overview
Source: https://docs.dune.com/data-catalog/evm/megaeth/overview

MegaETH data on Dune

## What is MegaETH?

MegaETH is an EVM-compatible blockchain built to deliver **real-time performance**, aiming for millisecond-level responsiveness while sustaining high throughput and substantial compute capacity. The goal is to push performance toward hardware limits so developers can build applications with fast feedback loops and high update rates.

## Key Features

* **Real-time execution**: Process transactions as they arrive and publish state updates in real time.
* **High throughput + compute**: Designed to support demanding on-chain applications that are bottlenecked by gas-per-second and compute limits on typical EVM chains.
* **Node specialization**: Uses specialized node roles (sequencers, provers, full nodes, replica nodes) to reduce consensus/execution overhead while preserving verifiability.
* **EVM compatibility**: Supports the EVM environment so existing Ethereum tooling and contracts can be used.
* **Security via base layers**: Delegates security and censorship-resistance constraints to base layers such as Ethereum and EigenDA, enabling a broader performance optimization design space.

## Data on Dune

<CardGroup>
  <Card title="Raw Data" icon="database" href="/data-catalog/evm/megaeth/raw/blocks">
    Access to raw blockchain data including blocks, transactions, logs, and traces
  </Card>

  <Card title="Decoded Data" icon="code" href="/data-catalog/evm/megaeth/decoded/overview">
    Human-readable contract interactions and events
  </Card>
</CardGroup>

## Resources

<CardGroup>
  <Card title="MegaETH Research" icon="link" href="https://www.megaeth.com/research">
    MegaETH research and technical deep dives
  </Card>
</CardGroup>


# megaeth.blocks
Source: https://docs.dune.com/data-catalog/evm/megaeth/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for MegaETH.

<BlockSnippet />


# megaeth.creation_traces
Source: https://docs.dune.com/data-catalog/evm/megaeth/raw/creation-traces

Contract deployment records on MegaETH — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# megaeth.logs
Source: https://docs.dune.com/data-catalog/evm/megaeth/raw/logs

Smart contract event logs on MegaETH — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# megaeth.traces
Source: https://docs.dune.com/data-catalog/evm/megaeth/raw/traces

Internal transaction traces on MegaETH — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# megaeth.transactions
Source: https://docs.dune.com/data-catalog/evm/megaeth/raw/transactions

Every transaction on MegaETH — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex.trades on mezo
Source: https://docs.dune.com/data-catalog/evm/mezo/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on mezo.

<DexTradesSnippet />


# Mezo Call Tables
Source: https://docs.dune.com/data-catalog/evm/mezo/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Mezo network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# mezo.contracts
Source: https://docs.dune.com/data-catalog/evm/mezo/decoded/contracts

Verified contract registry on Mezo — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs
Source: https://docs.dune.com/data-catalog/evm/mezo/decoded/event-logs

Smart Contracts emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# mezo.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/mezo/decoded/logs-decoded

ABI-decoded event logs on Mezo — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Mezo Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/mezo/decoded/overview

Simplifying Mezo smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# mezo.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/mezo/decoded/traces-decoded

ABI-decoded function calls on Mezo — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Mezo Overview
Source: https://docs.dune.com/data-catalog/evm/mezo/overview

Mezo data on Dune

## What is Mezo?

Mezo is the onchain Bitcoin banking platform owned by its users. Users can access self-service Bitcoin finance without interacting with loan officers, undergoing credit checks, or observing operational hours. It's just you, your Bitcoin, and permissionless access to financial services 24/7.

Mezo eliminates traditional banking middlemen, giving you the power to manage your finances intelligently on your own terms. The platform is built on tBTC, the most battle-tested decentralized Bitcoin bridge with 24k+ BTC bridged since 2020.

## Key Features and Advantages

### Flagship Feature: Fixed Rate Bitcoin Loans

**MUSD: Bitcoin-Backed Money with Complete Autonomy**

Deposit Bitcoin as collateral, mint MUSD (a dollar-pegged stablecoin), and use it however you need. Your Bitcoin stays yours while MUSD provides you with instant liquidity. Fixed rates start as low as 1% and stay fixed for the entire life of the loan.

This is self-service banking with complete autonomy. Unlike any traditional banking experience, there are no minimum payments, set repayment schedules, or penalties for early repayment. Close your position tomorrow or keep it open for years.

### Core Features

* **Bitcoin Loans (MUSD)**: Self-service loans at fixed 1% rates. Borrow MUSD against your Bitcoin and manage everything yourself. Access up to 90% of your Bitcoin's value.

* **Bitcoin Savings Accounts (Yield Vaults)**: Deposit BTC or MUSD into automated vaults that generate yield through lending, liquidity provision, and DeFi strategies. Like a high-yield savings account, but transparent, onchain. No minimum balance, withdraw anytime.

* **Native Swaps**: Trade directly on Mezo without leaving the platform. Swap between BTC, MUSD, and other assets with deep liquidity and competitive rates.

* **Mezo Market**: Spend your MUSD on real goods and services. Buy gift cards, pay for subscriptions, and access everyday purchases, all without selling your Bitcoin.

* **BTC as Gas**: Every transaction on Mezo is paid in Bitcoin. This keeps the experience pure Bitcoin while creating a revenue stream that flows back to participants in the Mezo ecosystem.

### Network Specifications

* **Technology Stack**: EVM-compatible blockchain
* **Gas Token**: BTC (Bitcoin)
* **Network Type**: EVM-compatible Layer 2
* **Base Bridge**: tBTC (decentralized Bitcoin bridge)
* **Reserve Verification**: Verifiable 24/7 reserves

### Developer Tools & Infrastructure

* **Full EVM Compatibility**: Support for standard Ethereum development tools
* **Permissionless Building**: Developers can build without permission
* **Open Source**: Contracts and documentation are open source
* **Infrastructure**:
  * Cross-chain bridges
  * DeFi integrations
  * Payment systems
  * Financial primitives

<CardGroup>
  <Card title="Mezo Documentation" icon="link" href="https://mezo.org/docs/users/introduction/mezo-self-service-banking">
    Official documentation for users and developers building on Mezo
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Insights into smart contract interactions through event logs
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on blocks processed on Mezo
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Detailed data on transactions
  </Card>

  <Card title="decoded" icon="file" href="./decoded/overview">
    Decoded transaction information for enhanced analysis
  </Card>
</CardGroup>


# mezo.blocks
Source: https://docs.dune.com/data-catalog/evm/mezo/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Mezo.

<BlockSnippet />


# mezo.creation_traces
Source: https://docs.dune.com/data-catalog/evm/mezo/raw/creation-traces

Contract deployment records on Mezo — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# mezo.logs
Source: https://docs.dune.com/data-catalog/evm/mezo/raw/logs

Smart contract event logs on Mezo — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# mezo.traces
Source: https://docs.dune.com/data-catalog/evm/mezo/raw/traces

Internal transaction traces on Mezo — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# mezo.transactions
Source: https://docs.dune.com/data-catalog/evm/mezo/raw/transactions

Every transaction on Mezo — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# Monad Testnet Call Tables
Source: https://docs.dune.com/data-catalog/evm/monad-testnet/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Monad testnet in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# monad_testnet.contracts
Source: https://docs.dune.com/data-catalog/evm/monad-testnet/decoded/contracts

Verified contract registry on Monad Testnet — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# monad_testnet.event_logs
Source: https://docs.dune.com/data-catalog/evm/monad-testnet/decoded/event-logs

Smart contract event logs on Monad Testnet — indexed topics and data fields emitted during transaction execution.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# monad_testnet.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/monad-testnet/decoded/logs-decoded

ABI-decoded event logs on Monad Testnet — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Monad Testnet Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/monad-testnet/decoded/overview

Simplifying Monad testnet smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# monad_testnet.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/monad-testnet/decoded/traces-decoded

ABI-decoded function calls on Monad Testnet — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Monad Testnet Overview
Source: https://docs.dune.com/data-catalog/evm/monad-testnet/overview

Monad Testnet data on Dune

## What is Monad?

Monad is a high-performance Ethereum-compatible L1 that materially advances the efficient frontier in the balance between decentralization and scalability. Monad introduces optimizations in five major areas, resulting in an Ethereum-compatible Layer-1 blockchain with 10,000 tps of throughput, 400ms block frequency, and 800ms finality.

## Key Features

* **MonadBFT**: Performant, tail-fork-resistant BFT consensus
* **RaptorCast**: Efficient block transmission
* **Asynchronous Execution**: Pipelining consensus and execution to raise the time budget for execution
* **Parallel Execution**: Efficient transaction execution
* **MonadDb**: Efficient state access
* **Full EVM Compatibility**: Complete bytecode equivalence for seamless application deployment
* **Ethereum RPC API Compatibility**: Familiar interface for users and developers

## Performance Characteristics

* **10,000 TPS**: High throughput for scalable applications
* **400ms Block Frequency**: Fast block production
* **800ms Finality**: Quick transaction finalization
* **Commodity Hardware**: Designed to run on standard hardware

## Architecture

Monad is designed with a focus on performance and scalability. The first Monad client is built by Category Labs and is written from scratch in C++ and Rust. The monad-bft consensus client implementation is open-source under GPL-3.0.

## Testnet

Monad's public testnet provides developers with a sandbox environment to test and deploy applications before mainnet launch. The testnet supports many leading Ethereum developer tools and infrastructure providers.

## Data on Dune

<CardGroup>
  <Card title="Raw Data" icon="database" href="/data-catalog/evm/monad-testnet/raw/blocks">
    Access to raw blockchain data including blocks, transactions, logs, and traces
  </Card>

  <Card title="Decoded Data" icon="code" href="/data-catalog/evm/monad-testnet/decoded/overview">
    Human-readable contract interactions and events
  </Card>
</CardGroup>

## Resources

<CardGroup>
  <Card title="Monad Documentation" icon="link" href="https://docs.monad.xyz/">
    Official documentation for developers building on Monad
  </Card>
</CardGroup>


# monad_testnet.blocks
Source: https://docs.dune.com/data-catalog/evm/monad-testnet/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Monad Testnet.

<BlockSnippet />


# monad_testnet.creation_traces
Source: https://docs.dune.com/data-catalog/evm/monad-testnet/raw/creation-traces

Contract deployment records on Monad Testnet — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# monad_testnet.logs
Source: https://docs.dune.com/data-catalog/evm/monad-testnet/raw/logs

Smart contract event logs on Monad Testnet — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# monad_testnet.traces
Source: https://docs.dune.com/data-catalog/evm/monad-testnet/raw/traces

Internal transaction traces on Monad Testnet — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# monad_testnet.transactions
Source: https://docs.dune.com/data-catalog/evm/monad-testnet/raw/transactions

Every transaction on Monad Testnet — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex.trades on monad
Source: https://docs.dune.com/data-catalog/evm/monad/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on monad.

<DexTradesSnippet />


# Monad Call Tables
Source: https://docs.dune.com/data-catalog/evm/monad/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Monad in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# monad.contracts
Source: https://docs.dune.com/data-catalog/evm/monad/decoded/contracts

Verified contract registry on Monad — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# monad.event_logs
Source: https://docs.dune.com/data-catalog/evm/monad/decoded/event-logs

Smart contract event logs on Monad — indexed topics and data fields emitted during transaction execution.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# monad.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/monad/decoded/logs-decoded

ABI-decoded event logs on Monad — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Monad Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/monad/decoded/overview

Simplifying Monad smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# monad.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/monad/decoded/traces-decoded

ABI-decoded function calls on Monad — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Monad Overview
Source: https://docs.dune.com/data-catalog/evm/monad/overview

Monad data on Dune

## What is Monad?

Monad is a high-performance Ethereum-compatible L1 that materially advances the efficient frontier in the balance between decentralization and scalability. Monad introduces optimizations in five major areas, resulting in an Ethereum-compatible Layer-1 blockchain with 10,000 tps of throughput, 400ms block frequency, and 800ms finality.

## Key Features

* **MonadBFT**: Performant, tail-fork-resistant BFT consensus
* **RaptorCast**: Efficient block transmission
* **Asynchronous Execution**: Pipelining consensus and execution to raise the time budget for execution
* **Parallel Execution**: Efficient transaction execution
* **MonadDb**: Efficient state access
* **Full EVM Compatibility**: Complete bytecode equivalence for seamless application deployment
* **Ethereum RPC API Compatibility**: Familiar interface for users and developers

## Performance Characteristics

* **10,000 TPS**: High throughput for scalable applications
* **400ms Block Frequency**: Fast block production
* **800ms Finality**: Quick transaction finalization
* **Commodity Hardware**: Designed to run on standard hardware

## Architecture

Monad is designed with a focus on performance and scalability. The first Monad client is built by Category Labs and is written from scratch in C++ and Rust. The monad-bft consensus client implementation is open-source under GPL-3.0.

## Mainnet

Monad mainnet provides developers with a production-ready environment to deploy and run applications. The mainnet supports many leading Ethereum developer tools and infrastructure providers.

## Data on Dune

<CardGroup>
  <Card title="Raw Data" icon="database" href="/data-catalog/evm/monad/raw/blocks">
    Access to raw blockchain data including blocks, transactions, logs, and traces
  </Card>

  <Card title="Decoded Data" icon="code" href="/data-catalog/evm/monad/decoded/overview">
    Human-readable contract interactions and events
  </Card>
</CardGroup>

## Resources

<CardGroup>
  <Card title="Monad Documentation" icon="link" href="https://docs.monad.xyz/">
    Official documentation for developers building on Monad
  </Card>
</CardGroup>


# monad.blocks
Source: https://docs.dune.com/data-catalog/evm/monad/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Monad.

<BlockSnippet />


# monad.creation_traces
Source: https://docs.dune.com/data-catalog/evm/monad/raw/creation-traces

Contract deployment records on Monad — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# monad.logs
Source: https://docs.dune.com/data-catalog/evm/monad/raw/logs

Smart contract event logs on Monad — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# monad.traces
Source: https://docs.dune.com/data-catalog/evm/monad/raw/traces

Internal transaction traces on Monad — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# monad.transactions
Source: https://docs.dune.com/data-catalog/evm/monad/raw/transactions

Every transaction on Monad — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex_aggregator.trades on opbnb
Source: https://docs.dune.com/data-catalog/evm/opbnb/curated-data/dex/dex-aggregator-trades

DEX aggregator swaps on opBNB — trades routed through aggregators like 1inch, Paraswap, and CoW Swap with pricing and routing details.

<DexAggregatorTradesSnippet />


# dex.trades on opbnb
Source: https://docs.dune.com/data-catalog/evm/opbnb/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on opbnb.

<DexTradesSnippet />


# NFT.trades on opbnb
Source: https://docs.dune.com/data-catalog/evm/opbnb/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on opbnb.

<NFTTradesSnippet />


# opBNB Call Tables
Source: https://docs.dune.com/data-catalog/evm/opbnb/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the opBNB network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# opbnb.contracts
Source: https://docs.dune.com/data-catalog/evm/opbnb/decoded/contracts

Verified contract registry on opBNB — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs
Source: https://docs.dune.com/data-catalog/evm/opbnb/decoded/event-logs

Smart Contracts emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# opbnb.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/opbnb/decoded/logs-decoded

ABI-decoded event logs on opBNB — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# opBNB Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/opbnb/decoded/overview

Simplifying opBNB smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# opbnb.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/opbnb/decoded/traces-decoded

ABI-decoded function calls on opBNB — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# opBNB Overview
Source: https://docs.dune.com/data-catalog/evm/opbnb/overview

opBNB data on Dune

## What is opBNB?

opBNB is a high-performance Layer 2 scaling solution for the BNB Smart Chain, powered by the bedrock version of Optimism OP Stack. It works by offloading transaction processing and resource usage from the BNB Smart Chain while maintaining data posting to the underlying mainnet. Users interact with opBNB by depositing funds from BSC and using applications and contracts on opBNB.

## Key Features and Advantages

### Optimistic Rollup Technology

* Processes transactions off-chain while maintaining BSC chain security
* Bundles multiple transactions into single batches for main chain submission
* Reduces computational load on BSC for faster and cheaper transactions
* Supports up to 5,000 transactions per second (TPS)

### Transaction Efficiency

* Lower transaction fees through off-chain processing
* Faster transaction confirmations
* Enhanced user experience for DApps and DeFi platforms
* Ideal for micro-transactions

### Security and Infrastructure

* Maintains security through BSC main chain's security model
* Fraud-proof mechanism for transaction validation
* Sequencers aggregate transactions and compute state transitions
* Provers generate cryptographic proofs for state validity
* Verifiers check proofs to ensure network integrity

### Network Specifications

* **Technology Stack**: OP Stack (bedrock version)
* **Gas Token**: BNB
* **Network Type**: EVM-compatible Layer 2
* **Base Chain**: BNB Smart Chain

### Developer Tools & Infrastructure

* **Smart Contract Development**: Support for standard Ethereum development tools
* **Block Explorers**: Multiple options for transaction monitoring
* **Infrastructure**:
  * Cross-chain bridges
  * Oracle integration
  * VRF capabilities
  * Indexing services

<CardGroup>
  <Card title="opBNB Documentation" icon="link" href="https://docs.bnbchain.org/bnb-opbnb/overview/">
    Official documentation for developers building on opBNB
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Insights into smart contract interactions through event logs
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on blocks processed on opBNB
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Detailed data on transactions
  </Card>

  <Card title="decoded" icon="file" href="./decoded/overview">
    Decoded transaction information for enhanced analysis
  </Card>
</CardGroup>


# opbnb.blocks
Source: https://docs.dune.com/data-catalog/evm/opbnb/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for opBNB.

<BlockSnippet />


# opbnb.creation_traces
Source: https://docs.dune.com/data-catalog/evm/opbnb/raw/creation-traces

Contract deployment records on opBNB — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# opbnb.logs
Source: https://docs.dune.com/data-catalog/evm/opbnb/raw/logs

Smart contract event logs on opBNB — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# opbnb.traces
Source: https://docs.dune.com/data-catalog/evm/opbnb/raw/traces

Internal transaction traces on opBNB — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# opbnb.transactions
Source: https://docs.dune.com/data-catalog/evm/opbnb/raw/transactions

Every transaction on opBNB — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex_aggregator.trades on optimism
Source: https://docs.dune.com/data-catalog/evm/optimism/curated-data/dex/dex-aggregator-trades

DEX aggregator swaps on Optimism — trades routed through aggregators like 1inch, Paraswap, and CoW Swap with pricing and routing details.

<DexAggregatorTradesSnippet />


# dex.trades on optimism
Source: https://docs.dune.com/data-catalog/evm/optimism/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on optimism.

<DexTradesSnippet />


# NFT.trades on optimism
Source: https://docs.dune.com/data-catalog/evm/optimism/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on optimism.

<NFTTradesSnippet />


# Optimism Call Tables
Source: https://docs.dune.com/data-catalog/evm/optimism/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Optimism network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# optimism.contracts
Source: https://docs.dune.com/data-catalog/evm/optimism/decoded/contracts

Verified contract registry on Optimism — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs
Source: https://docs.dune.com/data-catalog/evm/optimism/decoded/event-logs

Smart Contracts emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# optimism.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/optimism/decoded/logs-decoded

ABI-decoded event logs on Optimism — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Optimism Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/optimism/decoded/overview

Simplifying Optimism smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# ethereum.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/optimism/decoded/traces-decoded

ABI-decoded function calls on Ethereum — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Optimism Overview
Source: https://docs.dune.com/data-catalog/evm/optimism/overview

Optimism data on Dune

Optimism is a Layer 2 scaling solution for Ethereum that utilizes Optimistic Rollups to drastically improve transaction throughput while reducing costs. Optimism is designed to be fully compatible with Ethereum, allowing developers to deploy existing Ethereum applications without significant modifications.

Optimism operates under the principle of "optimistic execution," where transactions are assumed to be valid by default and only fully verified if a challenge is raised. This method greatly accelerates transaction processing times and lowers gas fees.

**Scalability and Cost-Efficiency:**
Optimism enhances Ethereum’s scalability by handling transactions off-chain while maintaining the security and decentralization of the main Ethereum network. It reduces the overall transaction costs, making it more accessible for users and developers.

**Ethereum Compatibility:**
Being fully compatible with Ethereum, Optimism allows for seamless migration of dApps and smart contracts, utilizing the same tools and programming languages used on Ethereum.

**Community-Driven Governance:**
Optimism actively supports a community-driven approach to its governance and development, promoting a decentralized and inclusive platform ecosystem.

<CardGroup>
  <Card title="Optimism documentation" icon="link" href="https://community.optimism.io/docs/">
    Access the official documentation for Optimism, providing detailed information on its technology, architecture, and how to build on the platform.
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Event logs from smart contracts, providing insights into contract interactions and the dynamic activity on Optimism.
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on blocks processed, reflecting the enhanced throughput and capacity of the Optimism network.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Detailed information on transactions, highlighting the operational efficiency and reduced costs facilitated by Optimistic Rollups.
  </Card>

  <Card title="decoded" icon="file" href="./decoded/overview">
    Decoded transaction data for easier analysis and understanding of contract executions on the Optimism network.
  </Card>
</CardGroup>


# optimism.blocks
Source: https://docs.dune.com/data-catalog/evm/optimism/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Optimism.

<BlockSnippet />


# optimism.creation_traces
Source: https://docs.dune.com/data-catalog/evm/optimism/raw/creation-traces

Contract deployment records on Optimism — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# optimism.logs
Source: https://docs.dune.com/data-catalog/evm/optimism/raw/logs

Smart contract event logs on Optimism — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# optimism.traces
Source: https://docs.dune.com/data-catalog/evm/optimism/raw/traces

Internal transaction traces on Optimism — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# optimism.transactions
Source: https://docs.dune.com/data-catalog/evm/optimism/raw/transactions

Every transaction on Optimism — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# EVM Overview
Source: https://docs.dune.com/data-catalog/evm/overview

EVM chains on Dune

## Introduction to EVM Chains

The Ethereum Virtual Machine (EVM) is the runtime environment for smart contracts in Ethereum. It's not only the cornerstone of Ethereum but also serves as a standard for decentralized applications across various blockchain networks. Due to its robustness and developer-friendly attributes, numerous blockchains have adopted the EVM framework, enabling them to leverage Ethereum's thriving ecosystem and interoperability.

### EVM Chains

We provide the most comprehensive data catalog for Ethereum Mainnet and EVM-compatible rollups, sidechains and other layer 2 solutions.
All EVM chains on Dune have raw data, decoded data and curated data tables available.

e.g. here are the available data sets for Ethereum Mainnet:

<CardGroup>
  <Card title="Raw data" icon="bolt" href="./ethereum/raw/transactions" />

  <Card title="Decoded data" icon="file" href="./ethereum/decoded/overview" />

  <Card title="Curated data" icon="star" href="/data-catalog/curated/overview" />
</CardGroup>

<div>
  <DuneEmbed />
</div>


# dex.trades on peaq
Source: https://docs.dune.com/data-catalog/evm/peaq-evm/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on peaq.

<DexTradesSnippet />


# Peaq EVM Call Tables
Source: https://docs.dune.com/data-catalog/evm/peaq-evm/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the peaq network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# peaq.contracts
Source: https://docs.dune.com/data-catalog/evm/peaq-evm/decoded/contracts

Verified contract registry on Peaq — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs
Source: https://docs.dune.com/data-catalog/evm/peaq-evm/decoded/event-logs

Smart Contracts emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# peaq.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/peaq-evm/decoded/logs-decoded

ABI-decoded event logs on Peaq — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Peaq Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/peaq-evm/decoded/overview

Simplifying peaq smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# peaq.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/peaq-evm/decoded/traces-decoded

ABI-decoded function calls on Peaq — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Peaq EVM Overview
Source: https://docs.dune.com/data-catalog/evm/peaq-evm/overview

Peaq EVM data on Dune

## What is Peaq?

Peaq EVM is the EVM chain of the layer-1 blockchain purpose-built PEAQ and optimized to power the Machine Economy. The platform enables decentralized physical infrastructure networks (DePINs), decentralized physical AI (DePAI), Machine DeFi, and Machine RWAs (Real-World Assets).

By leveraging parallelized block production, asynchronous backing, and agile core time, peaq currently handles up to 10,000 transactions per second (TPS). It is set to scale beyond 100,000 TPS after future upgrades, all while maintaining a minimum transaction cost of approximately \$0.00025.

## Key Features and Advantages

### Machine Economy Focus

Peaq is purpose-built for the Machine Economy, supporting:

* **DePINs (Decentralized Physical Infrastructure Networks)**: Networks that incentivize people to deploy hardware for real-world services
* **DePAI (Decentralized Physical AI)**: Decentralized AI systems that interact with physical infrastructure
* **Machine DeFi**: Decentralized Finance based on machines' on-chain economic value and activity
* **Machine RWAs**: Tokenized machines bringing real-world economic value on-chain

### High Performance & Scalability

* **Current Throughput**: Up to 10,000 transactions per second (TPS)
* **Future Scalability**: Set to scale beyond 100,000 TPS after future upgrades
* **Low Transaction Costs**: Minimum transaction cost of approximately \$0.00025
* **Parallelized Block Production**: Enables high throughput and efficiency
* **Asynchronous Backing**: Advanced consensus mechanism for performance

### Security & Decentralization

* **Environmentally-Friendly Architecture**: Leverages the world's environmentally-friendliest blockchain architecture
* **High Nakamoto Coefficient**: One of the highest Nakamoto Coefficients in the industry to ensure censorship resistance
* **EVM Compatibility**: Full EVM compatibility for familiar development tools

### Modular DePIN and DePAI Functions

Peaq offers a comprehensive suite of ready-to-use Modular DePIN and DePAI Functions, granting builders and machines essential core functionalities:

* **Self-Sovereign Machine IDs**: Unique identity for machines on-chain
* **Role-Based Access Control**: Secure permission management
* **Data Verification**: Ensure data integrity and authenticity
* **Universal Machine Time**: Synchronized time across the network
* **Seamless Machine Payment Processing**: Built-in payment infrastructure
* **Data Storage**: On-chain and off-chain storage solutions
* **Data Indexing**: Efficient data retrieval and querying
* **AI Agents**: AI-powered automation and decision-making

All functions are accessible via the Peaq SDK, allowing developers to deploy them with just \~15 lines of code.

### Network Specifications

* **Technology Stack**: EVM-compatible Layer 1
* **Network Type**: EVM-compatible blockchain
* **Consensus**: Asynchronous backing with parallelized block production
* **Transaction Speed**: Up to 10,000 TPS (scaling to 100,000+ TPS)
* **Transaction Cost**: Minimum \~\$0.00025 per transaction

### Developer Tools & Infrastructure

* **Full EVM Compatibility**: Support for standard Ethereum development tools
* **Peaq SDK**: Comprehensive SDK for deploying DePIN and DePAI functions
* **Modular Functions**: Ready-to-use functions for machine economy applications
* **Smart Contract Development**: Standard Solidity development support
* **Infrastructure**:
  * Machine identity management
  * Data verification systems
  * Payment processing
  * Storage solutions
  * AI agent integration

<CardGroup>
  <Card title="Peaq Documentation" icon="link" href="https://docs.peaq.xyz/build/introduction">
    Official documentation for developers building on Peaq
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="/data-catalog/evm/peaq-evm/raw/logs">
    Insights into smart contract interactions through event logs
  </Card>

  <Card title="Blocks" icon="cubes" href="/data-catalog/evm/peaq-evm/raw/blocks">
    Information on blocks processed on Peaq EVM
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="/data-catalog/evm/peaq-evm/raw/transactions">
    Detailed data on transactions
  </Card>

  <Card title="Decoded" icon="file" href="/data-catalog/evm/peaq-evm/decoded/overview">
    Decoded transaction information for enhanced analysis
  </Card>
</CardGroup>


# peaq.evm_blocks
Source: https://docs.dune.com/data-catalog/evm/peaq-evm/raw/blocks

Peaq EVM-compatible block data.

<BlockSnippet />


# peaq.creation_traces
Source: https://docs.dune.com/data-catalog/evm/peaq-evm/raw/creation-traces

Contract deployment records on Peaq — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# peaq.logs
Source: https://docs.dune.com/data-catalog/evm/peaq-evm/raw/logs

Smart contract event logs on Peaq — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# peaq.traces
Source: https://docs.dune.com/data-catalog/evm/peaq-evm/raw/traces

Internal transaction traces on Peaq — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# peaq.transactions
Source: https://docs.dune.com/data-catalog/evm/peaq-evm/raw/transactions

Every transaction on Peaq — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex.trades on plasma
Source: https://docs.dune.com/data-catalog/evm/plasma/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on plasma.

<DexTradesSnippet />


# Plasma Call Tables
Source: https://docs.dune.com/data-catalog/evm/plasma/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Plasma network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# plasma.contracts
Source: https://docs.dune.com/data-catalog/evm/plasma/decoded/contracts

Verified contract registry on Plasma — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# plasma.event_logs
Source: https://docs.dune.com/data-catalog/evm/plasma/decoded/event-logs

Smart contract event logs on Plasma — indexed topics and data fields emitted during transaction execution.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# plasma.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/plasma/decoded/logs-decoded

ABI-decoded event logs on Plasma — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Plasma Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/plasma/decoded/overview

Simplifying Plasma smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# plasma.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/plasma/decoded/traces-decoded

ABI-decoded function calls on Plasma — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Plasma Overview
Source: https://docs.dune.com/data-catalog/evm/plasma/overview

Plasma data on Dune

## What is Plasma?

Plasma is a stablecoin-native blockchain designed specifically for building stablecoin applications. It provides a secure, scalable platform that enables zero-fee USD₮ transfers and supports custom gas tokens, making it ideal for payment applications and stablecoin-focused DeFi protocols.

## Key Features

* **Stablecoin-Native**: Purpose-built for stablecoin applications and payments
* **Zero-Fee USD₮ Transfers**: Native support for fee-free USDT transactions
* **Custom Gas Tokens**: Flexibility to use different tokens for gas payments
* **Confidential Payments**: Privacy-preserving transaction capabilities
* **Account Abstraction**: Advanced account management features
* **Bitcoin Bridge**: Native integration with Bitcoin network

## Architecture

Plasma features a unique architecture optimized for stablecoin operations:

* **Consensus**: Robust consensus mechanism for network security
* **Execution**: Optimized execution layer for stablecoin transactions
* **Bitcoin Bridge**: Secure cross-chain connectivity with Bitcoin
* **System Overview**: Comprehensive infrastructure for payment applications

## Ecosystem Highlights

* Advanced stablecoin-native smart contracts
* Zero-fee transfer capabilities for USD₮
* Support for confidential payment protocols
* Comprehensive tooling and infrastructure including:
  * Block explorers and analytics
  * Cross-chain bridges
  * RPC providers and indexers
  * Oracles and account abstraction tools
  * Testnet faucets for XPL tokens

## Data on Dune

<CardGroup>
  <Card title="Raw Data" icon="database" href="/data-catalog/evm/plasma/raw/blocks">
    Access to raw blockchain data including blocks, transactions, logs, and traces
  </Card>

  <Card title="Decoded Data" icon="code" href="/data-catalog/evm/plasma/decoded/overview">
    Human-readable contract interactions and events
  </Card>
</CardGroup>

## Resources

<CardGroup>
  <Card title="Plasma Documentation" icon="link" href="http://docs.plasma.to/docs/plasma-chain/introduction/start-here">
    Official documentation for developers building on Plasma
  </Card>
</CardGroup>


# plasma.blocks
Source: https://docs.dune.com/data-catalog/evm/plasma/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Plasma.

<BlockSnippet />


# plasma.creation_traces
Source: https://docs.dune.com/data-catalog/evm/plasma/raw/creation-traces

Contract deployment records on Plasma — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# plasma.logs
Source: https://docs.dune.com/data-catalog/evm/plasma/raw/logs

Smart contract event logs on Plasma — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# plasma.traces
Source: https://docs.dune.com/data-catalog/evm/plasma/raw/traces

Internal transaction traces on Plasma — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# plasma.transactions
Source: https://docs.dune.com/data-catalog/evm/plasma/raw/transactions

Every transaction on Plasma — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# plume.dex_aggregator_trades
Source: https://docs.dune.com/data-catalog/evm/plume/curated-data/dex/dex-aggregator-trades

DEX aggregator swaps on Plume — trades routed through aggregators like 1inch, Paraswap, and CoW Swap with pricing and routing details.

<DexAggregatorTradesSnippet />


# plume.dex_trades
Source: https://docs.dune.com/data-catalog/evm/plume/curated-data/dex/dex-trades

DEX trade data on Plume — swaps across Uniswap, SushiSwap, and other decentralized exchanges with token amounts and USD pricing.

<DexTradesSnippet />


# plume.contracts
Source: https://docs.dune.com/data-catalog/evm/plume/decoded/contracts

Verified contract registry on Plume — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# plume.event_logs
Source: https://docs.dune.com/data-catalog/evm/plume/decoded/event-logs

Smart contract event logs on Plume — indexed topics and data fields emitted during transaction execution.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# plume.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/plume/decoded/logs-decoded

ABI-decoded event logs on Plume — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Plume Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/plume/decoded/overview

Simplifying Plume smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# plume.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/plume/decoded/traces-decoded

ABI-decoded function calls on Plume — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Plume Overview
Source: https://docs.dune.com/data-catalog/evm/plume/overview

Plume data on Dune

## What is Plume?

Plume is a public, EVM-compatible blockchain specifically designed for Real World Assets (RWAs). It serves as the onchain home for real-world assets, enabling them to be used like crypto-native assets through features like staking, swapping, lending, borrowing, and looping.

## Key Features

* **RWA-Focused**: Built specifically for the next evolution of Real World Assets
* **EVM-Compatible**: Seamless integration with existing Ethereum tools and infrastructure
* **Institutional Integration**: Designed to work with major institutions and asset managers
* **Composability**: RWAs can be used across the DeFi stack for yield stacking, leverage, and structured products

## Ecosystem Highlights

* Over 200 protocols onboarded and growing
* Testnet success with 18 million wallets and 280 million transactions
* Partnerships with major institutions and asset managers
* Support for various asset types including:
  * Private credit
  * ETFs
  * Commodities
  * Esoteric assets (GPUs, uranium, mineral rights, etc.)

## Data on Dune

<CardGroup>
  <Card title="Raw Data" icon="database" href="/data-catalog/evm/plume/raw/blocks">
    Access to raw blockchain data including blocks, transactions, logs, and traces
  </Card>

  <Card title="Decoded Data" icon="code" href="/data-catalog/evm/plume/decoded/overview">
    Human-readable contract interactions and events
  </Card>

  <Card title="DEX Data" icon="shuffle" href="/data-catalog/evm/plume/curated-data/dex/dex-trades">
    Track DEX trading activity and aggregator trades
  </Card>
</CardGroup>

## Resources

<CardGroup>
  <Card title="Plume Documentation" icon="link" href="https://docs.plume.org/plume">
    Official documentation for developers building on Plume
  </Card>
</CardGroup>


# plume.blocks
Source: https://docs.dune.com/data-catalog/evm/plume/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Plume.

<BlockSnippet />


# plume.creation_traces
Source: https://docs.dune.com/data-catalog/evm/plume/raw/creation-traces

Contract deployment records on Plume — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# plume.logs
Source: https://docs.dune.com/data-catalog/evm/plume/raw/logs

Smart contract event logs on Plume — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# plume.traces
Source: https://docs.dune.com/data-catalog/evm/plume/raw/traces

Internal transaction traces on Plume — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# plume.transactions
Source: https://docs.dune.com/data-catalog/evm/plume/raw/transactions

Every transaction on Plume — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex_aggregator.trades on Polygon zkEVM
Source: https://docs.dune.com/data-catalog/evm/polygon-zkEVM/curated-data/dex/dex-aggregator-trades

DEX aggregator swaps on Polygon zkEVM — trades routed through aggregators like 1inch, Paraswap, and CoW Swap with pricing and routing details.

<DexAggregatorTradesSnippet />


# dex.trades on Polygon zkEVM
Source: https://docs.dune.com/data-catalog/evm/polygon-zkEVM/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on Polygon zkEVM.

<DexTradesSnippet />


# NFT.trades on Polygon zkEVM
Source: https://docs.dune.com/data-catalog/evm/polygon-zkEVM/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on Polygon zkEVM.

<NFTTradesSnippet />


# Polygon zkEVM Call Tables
Source: https://docs.dune.com/data-catalog/evm/polygon-zkEVM/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Polygon zkEVM network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# zkevm.contracts
Source: https://docs.dune.com/data-catalog/evm/polygon-zkEVM/decoded/contracts

Verified contract registry on Polygon zkEVM — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs
Source: https://docs.dune.com/data-catalog/evm/polygon-zkEVM/decoded/event-logs

Smart Contracts emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# zkevm.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/polygon-zkEVM/decoded/logs-decoded

ABI-decoded event logs on Polygon zkEVM — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Polygon zkEVM Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/polygon-zkEVM/decoded/overview

Simplifying Polygon zkEVM smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# zkevm.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/polygon-zkEVM/decoded/traces-decoded

ABI-decoded function calls on Polygon zkEVM — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Polygon zkEVM Overview
Source: https://docs.dune.com/data-catalog/evm/polygon-zkEVM/overview

Polygon zkEVM data on Dune

Polygon zkEVM is a Layer 2 scaling solution for Ethereum that leverages zero-knowledge proofs to ensure scalability. It is designed to be Ethereum Virtual Machine (EVM)-compatible, enabling developers to deploy existing Solidity smart contracts without modifications.

The core feature of Polygon zkEVM is its use of zk-SNARKs (zero-knowledge Succinct Non-Interactive Arguments of Knowledge) to bundle hundreds of transactions into a single proof, verifying them on the Ethereum mainnet. This process enhances throughput, reduces transaction costs, and maintains the robust security guarantees of Ethereum.

The native utility token for Polygon zkEVM is Ether, used primarily for transaction fees. Unlike Layer1 blockchains, Polygon zkEVM aims to provide a seamless scaling solution that inherits Ethereum's security and decentralization features while significantly improving performance and cost-efficiency.

Dune offers comprehensive datasets for Polygon zkEVM, including event logs, transactions, blocks, and token activities. These datasets enable deep insights into the network's performance, usage patterns, and smart contract interactions.

<CardGroup>
  <Card title="Polygon zkEVM docs" icon="link" href="https://polygon.technology/polygon-zkevm">
    The official documentation for Polygon zkEVM, providing detailed information on the protocol, architecture, and developer resources
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Event logs from smart contracts, providing insights into contract interactions
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information and statistics on blocks, showcasing the network's activity and throughput
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Detailed transaction data, highlighting the execution and efficiency of operations
  </Card>

  <Card title="decoded" icon="file" href="./decoded/overview">
    Decoded transaction data for easier understanding and analysis of smart contract executions
  </Card>
</CardGroup>


# zkevm.blocks
Source: https://docs.dune.com/data-catalog/evm/polygon-zkEVM/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Polygon zkEVM.

<BlockSnippet />


# zkevm.creation_traces
Source: https://docs.dune.com/data-catalog/evm/polygon-zkEVM/raw/creation-traces

Contract deployment records on Polygon zkEVM — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# zkevm.logs
Source: https://docs.dune.com/data-catalog/evm/polygon-zkEVM/raw/logs

Smart contract event logs on Polygon zkEVM — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# zkevm.traces
Source: https://docs.dune.com/data-catalog/evm/polygon-zkEVM/raw/traces

Internal transaction traces on Polygon zkEVM — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# zkevm.transactions
Source: https://docs.dune.com/data-catalog/evm/polygon-zkEVM/raw/transactions

Every transaction on Polygon zkEVM — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex_aggregator.trades on polygon
Source: https://docs.dune.com/data-catalog/evm/polygon/curated-data/dex/dex-aggregator-trades

DEX aggregator swaps on Polygon — trades routed through aggregators like 1inch, Paraswap, and CoW Swap with pricing and routing details.

<DexAggregatorTradesSnippet />


# dex.trades on polygon
Source: https://docs.dune.com/data-catalog/evm/polygon/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on polygon.

<DexTradesSnippet />


# NFT.trades on polygon
Source: https://docs.dune.com/data-catalog/evm/polygon/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on polygon.

<NFTTradesSnippet />


# Polygon PoS Network Call Tables
Source: https://docs.dune.com/data-catalog/evm/polygon/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Polygon PoS Network network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# polygon.contracts
Source: https://docs.dune.com/data-catalog/evm/polygon/decoded/contracts

Verified contract registry on Polygon — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs
Source: https://docs.dune.com/data-catalog/evm/polygon/decoded/event-logs

Smart Contracts emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# polygon.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/polygon/decoded/logs-decoded

ABI-decoded event logs on Polygon — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Polygon PoS Network Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/polygon/decoded/overview

Simplifying Polygon PoS Network smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# polygon.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/polygon/decoded/traces-decoded

ABI-decoded function calls on Polygon — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Polygon PoS Network Overview
Source: https://docs.dune.com/data-catalog/evm/polygon/overview

Polygon PoS Network data on Dune

Polygon PoS is a proof-of-stake blockchain network that serves as a scaling solution for Ethereum. It combines the security and interoperability of Ethereum with the speed and efficiency of standalone networks, facilitating faster and cheaper transactions. Polygon PoS leverages a network of validators who stake their tokens to secure the network, participate in consensus, and manage governance.

**High Performance and Low Transaction Costs:**
Polygon PoS offers significant improvements in speed and transaction costs over Ethereum's mainnet by processing transactions on a sidechain before committing them to the Ethereum blockchain. This approach minimizes congestion and gas fees.

**Ethereum Compatibility:**
Fully compatible with Ethereum, Polygon PoS enables developers to deploy existing Ethereum applications without significant changes, using familiar tools and frameworks.

**Decentralized and Secure:**
The proof-of-stake model ensures that the network remains decentralized and secure, with validators and delegators actively participating in the consensus and governance processes.

<CardGroup>
  <Card title="Polygon PoS documentation" icon="link" href="https://docs.polygon.technology/docs/home">
    Comprehensive documentation on the Polygon PoS network, including guides on its architecture, staking mechanisms, and development resources.
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Insights into smart contract interactions through detailed event logs, providing visibility into the dynamic activity on the Polygon PoS network.
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on blocks processed on the Polygon PoS network, reflecting the network’s high throughput and capacity for handling large volumes of transactions.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Extensive transaction data, highlighting the operational efficiency and reduced costs facilitated by the PoS mechanism.
  </Card>

  <Card title="decoded" icon="file" href="./decoded/overview">
    Decoded transaction information for enhanced analysis and understanding of smart contract executions on the Polygon PoS network.
  </Card>
</CardGroup>


# polygon.blocks
Source: https://docs.dune.com/data-catalog/evm/polygon/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Polygon.

<BlockSnippet />


# polygon.creation_traces
Source: https://docs.dune.com/data-catalog/evm/polygon/raw/creation-traces

Contract deployment records on Polygon — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# polygon.logs
Source: https://docs.dune.com/data-catalog/evm/polygon/raw/logs

Smart contract event logs on Polygon — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# polygon.traces
Source: https://docs.dune.com/data-catalog/evm/polygon/raw/traces

Internal transaction traces on Polygon — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# polygon.transactions
Source: https://docs.dune.com/data-catalog/evm/polygon/raw/transactions

Every transaction on Polygon — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# RISE Call Tables
Source: https://docs.dune.com/data-catalog/evm/rise/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the RISE network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# rise.contracts
Source: https://docs.dune.com/data-catalog/evm/rise/decoded/contracts

Verified contract registry on RISE — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs - RISE
Source: https://docs.dune.com/data-catalog/evm/rise/decoded/event-logs

Smart contracts on RISE emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# rise.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/rise/decoded/logs-decoded

ABI-decoded event logs on RISE — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# RISE Chain Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/rise/decoded/overview

Simplifying RISE Chain smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# rise.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/rise/decoded/traces-decoded

ABI-decoded function calls on RISE — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# RISE Chain Overview
Source: https://docs.dune.com/data-catalog/evm/rise/overview

RISE blockchain data on Dune

## What is RISE?

RISE is a high-performance Ethereum Layer 2 designed for onchain markets, delivering near-instant transactions at scale with full EVM compatibility. The chain advertises 1ms latency, 50,000+ TPS, and 5 Ggas/s of compute throughput, while remaining secured by Ethereum. RISE pairs a low-latency execution environment with native orderbook infrastructure (RISE MarketCore) and a perpetuals platform (RISEx) so trading and other latency-sensitive applications can share deep liquidity onchain.

## Key Features

* **Sub-second blocks**: RISE produces a new block every \~1 second, enabling sub-second user-perceivable finality and very tight feedback loops for trading applications.
* **EVM compatibility**: Standard Solidity tooling (Foundry, Hardhat, etc.) works without modification — contracts deploy as on any EVM chain.
* **High throughput**: Architecture targets >50K TPS and 5 Ggas/s, well above mainstream rollups, intended for orderbook-style applications that demand many small writes per second.
* **Native market infrastructure**: RISE MarketCore exposes a shared orderbook substrate so any application can permissionlessly launch onchain spot or perpetual markets backed by network-wide liquidity.
* **Modular DA**: RISE leverages a modular data availability layer (Celestia / EigenDA) with Ethereum fallbacks for security, allowing high throughput without Ethereum L1 calldata cost.

## EVM Specifics on Dune

* **Native gas token**: ETH (gas paid in ETH like other Ethereum L2s).
* **Block time**: \~1 second average (verified against `rise.blocks` time deltas).
* **TIP-20**: RISE indexes a TIP-20 token-event family alongside ERC-20 — `tip20_rise.evt_*` tables surface RISE-specific token primitives (memo transfers, reward distribution, supply caps, transfer policies). Standard ERC-20 events live under `erc20_rise.evt_*`.

## Data on Dune

<CardGroup>
  <Card title="Raw Data" icon="database" href="/data-catalog/evm/rise/raw/blocks">
    Block, transaction, log, and trace data indexed directly from RISE nodes.
  </Card>

  <Card title="Decoded Data" icon="code" href="/data-catalog/evm/rise/decoded/overview">
    ABI-decoded contract interactions and events including the native RISEx perps stack.
  </Card>
</CardGroup>

## Resources

<CardGroup>
  <Card title="RISE Chain" icon="link" href="https://risechain.com/">
    Project home page.
  </Card>

  <Card title="RISE Documentation" icon="book" href="https://docs.risechain.com/">
    Architecture, tooling, and developer guides.
  </Card>
</CardGroup>


# rise.blocks
Source: https://docs.dune.com/data-catalog/evm/rise/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for RISE.

<BlockSnippet />


# rise.creation_traces
Source: https://docs.dune.com/data-catalog/evm/rise/raw/creation-traces

Contract deployment records on RISE — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# rise.logs
Source: https://docs.dune.com/data-catalog/evm/rise/raw/logs

Smart contract event logs on RISE — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# rise.traces
Source: https://docs.dune.com/data-catalog/evm/rise/raw/traces

Internal transaction traces on RISE — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# rise.transactions
Source: https://docs.dune.com/data-catalog/evm/rise/raw/transactions

Every transaction on RISE — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex.trades on ronin
Source: https://docs.dune.com/data-catalog/evm/ronin/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on ronin.

<DexTradesSnippet />


# NFT.trades on ronin
Source: https://docs.dune.com/data-catalog/evm/ronin/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on ronin.

<NFTTradesSnippet />


# Ronin Call Tables
Source: https://docs.dune.com/data-catalog/evm/ronin/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Ronin network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# ronin.contracts
Source: https://docs.dune.com/data-catalog/evm/ronin/decoded/contracts

Verified contract registry on Ronin — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs
Source: https://docs.dune.com/data-catalog/evm/ronin/decoded/event-logs

Smart Contracts emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# ronin.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/ronin/decoded/logs-decoded

ABI-decoded event logs on Ronin — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Ronin Chain Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/ronin/decoded/overview

Simplifying Ronin Chain smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# ronin.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/ronin/decoded/traces-decoded

ABI-decoded function calls on Ronin — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Ronin Chain Overview
Source: https://docs.dune.com/data-catalog/evm/ronin/overview

Ronin blockchain data on Dune

## What is Ronin?

Ronin is an EVM-based blockchain purpose-built for gaming, created by Sky Mavis, the team behind Axie Infinity. As one of the few blockchains capable of scaling a single game to millions of daily active users, Ronin powers the vibrant Axie Infinity ecosystem and has processed over \$4 billion in NFT volumes. With near-instant transactions and minimal fees, Ronin is optimized to support the high demand of Web3 gaming experiences.

## Key Features of Ronin

Ronin’s infrastructure focuses on performance, scalability, and seamless user experience for in-game transactions, making it the top choice for Web3 games.

### **Scalability and Gaming Optimization**

Ronin has demonstrated its ability to scale, processing 15% of the global NFT trading volume at its peak and handling millions of daily users in the Axie Infinity ecosystem. It prioritizes only high-quality applications and maintains high uptime, ensuring a spam-free, optimized gaming environment.

### **Low-Cost Transactions**

With negligible transaction fees, Ronin makes it feasible for users to perform frequent in-game transactions, eliminating cost barriers for players and developers alike.

### **EVM Compatibility**

As an EVM-compatible chain, Ronin allows developers familiar with Ethereum to migrate applications easily, benefiting from tools like Remix, Hardhat, and Foundry.

## Network Architecture

Ronin’s architecture is designed to support high-performance gaming applications with an emphasis on minimal latency and cost-effectiveness. It also supports selective onboarding of apps, preserving quality across the ecosystem.

* **Gaming-Focused Environment:** Allows only high-quality applications to join, reducing bloat and increasing uptime.
* **Security Measures:** Incorporates advanced security measures following past challenges, including zero-trust architecture and rigorous internal security practices.

## Consensus Mechanism

Ronin initially adopted a **Proof of Authority (PoA)** consensus, relying on a trusted validator set selected by Sky Mavis and the community. To increase decentralization, Ronin transitioned in 2023 to **Delegated Proof of Stake (DPoS)**, allowing any RON token holder to participate in validator selection, creating a more community-driven governance model.

* **Block Production and Finality Voting:** Validators are selected to produce blocks and vote for finality, with weighted voting based on staked RON.
* **Rotating Validators:** Introduced in July 2024, ensuring all validators have block production opportunities and receive rewards, fostering greater inclusivity.

## Security and Slashing Mechanism

Ronin has implemented robust security measures, including slashing penalties for validators who act maliciously or are frequently unavailable. The credit score and bailout system enables validators to recover from unexpected downtime, while tiered penalties discourage continuous underperformance.

* **Double Signing Penalties:** Validators involved in double-signing or publishing contradictory votes are permanently jailed and face RON slashing.
* **Validator Credit Score:** A unique system allows validators to earn credits daily, which can be used to bail out of jail in case of unexpected downtime.

## Token Economy

The native token, **RON**, is central to Ronin's economy, supporting validator incentives and governance:

* **Staking and Rewards:** Validators and delegators earn rewards through block production and finality voting.
* **Governance Participation:** Token holders can delegate stake to preferred validators, enhancing decentralization.

<CardGroup>
  <Card title="Ronin documentation" icon="link" href="https://docs.roninchain.com/">
    Access comprehensive documentation for Ronin, covering details on its consensus mechanisms, security features, and how to build on the network.
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Access logs of in-game transactions and other activities on Ronin, providing insight into the chain’s high transaction volume.
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on block production and finality, illustrating Ronin's ability to handle gaming-scale operations.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Transaction data with a focus on minimal fees, showing how Ronin enables smooth in-game interactions.
  </Card>

  <Card title="decoded" icon="file" href="./decoded/overview">
    Decoded transaction data, making it easier to analyze in-game economies and smart contract interactions.
  </Card>
</CardGroup>


# ronin.blocks
Source: https://docs.dune.com/data-catalog/evm/ronin/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Ronin.

<BlockSnippet />


# ronin.creation_traces
Source: https://docs.dune.com/data-catalog/evm/ronin/raw/creation-traces

Contract deployment records on Ronin — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# ronin.logs
Source: https://docs.dune.com/data-catalog/evm/ronin/raw/logs

Smart contract event logs on Ronin — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# ronin.traces
Source: https://docs.dune.com/data-catalog/evm/ronin/raw/traces

Internal transaction traces on Ronin — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# ronin.transactions
Source: https://docs.dune.com/data-catalog/evm/ronin/raw/transactions

Every transaction on Ronin — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex_aggregator.trades on scroll
Source: https://docs.dune.com/data-catalog/evm/scroll/curated-data/dex/dex-aggregator-trades

DEX aggregator swaps on Scroll — trades routed through aggregators like 1inch, Paraswap, and CoW Swap with pricing and routing details.

<DexAggregatorTradesSnippet />


# dex.trades on scroll
Source: https://docs.dune.com/data-catalog/evm/scroll/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on scroll.

<DexTradesSnippet />


# NFT.trades on scroll
Source: https://docs.dune.com/data-catalog/evm/scroll/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on scroll.

<NFTTradesSnippet />


# Scroll Call Tables
Source: https://docs.dune.com/data-catalog/evm/scroll/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Scroll network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# scroll.contracts
Source: https://docs.dune.com/data-catalog/evm/scroll/decoded/contracts

Verified contract registry on Scroll — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs
Source: https://docs.dune.com/data-catalog/evm/scroll/decoded/event-logs

Smart Contracts emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# scroll.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/scroll/decoded/logs-decoded

ABI-decoded event logs on Scroll — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Scroll Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/scroll/decoded/overview

Simplifying Scroll smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# scroll.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/scroll/decoded/traces-decoded

ABI-decoded function calls on Scroll — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Scroll Overview
Source: https://docs.dune.com/data-catalog/evm/scroll/overview

Scroll data on Dune

Scroll is a Layer 2 scaling solution for Ethereum that utilizes zk-Rollups to enhance transaction throughput while maintaining low costs and high security. Scroll is designed to facilitate scalable and efficient blockchain applications by bundling multiple transactions into a single rollup block, which is then verified on the Ethereum mainnet using zero-knowledge proofs.

**High Scalability and Efficiency:**
Scroll leverages zk-Rollups to significantly increase transaction capacity and reduce blockchain congestion. This technology allows for rapid processing and finalization of transactions at a fraction of the cost of traditional Ethereum transactions.

**Strong Security and Ethereum Compatibility:**
By using zero-knowledge proofs, Scroll ensures that all transactions maintain the same level of security as those on the Ethereum mainnet. Additionally, Scroll is fully compatible with Ethereum, enabling developers to deploy existing smart contracts and dApps without the need for extensive modifications.

**Developer-Friendly Environment:**
Scroll provides a robust environment for developers, with tools that simplify the integration and deployment of Ethereum-compatible applications on a scalable Layer 2 platform.

<CardGroup>
  <Card title="Scroll documentation" icon="link" href="https://docs.scroll.io">
    Access comprehensive documentation for Scroll, providing detailed insights into its zk-Rollup technology, platform architecture, and how to build on it.
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Detailed event logs from smart contracts, offering insights into contract interactions and the dynamics of Scroll's zk-Rollup operations.
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on blocks processed through Scroll’s zk-Rollups, illustrating the network's enhanced throughput and scalability.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Extensive transaction data, highlighting the efficiency and reduced costs of operations on Scroll.
  </Card>

  <Card title="decoded" icon="file" href="./decoded/overview">
    Decoded transaction data for easier analysis and deeper understanding of smart contract executions on the Scroll network.
  </Card>
</CardGroup>


# scroll.blocks
Source: https://docs.dune.com/data-catalog/evm/scroll/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Scroll.

<BlockSnippet />


# scroll.creation_traces
Source: https://docs.dune.com/data-catalog/evm/scroll/raw/creation-traces

Contract deployment records on Scroll — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# scroll.logs
Source: https://docs.dune.com/data-catalog/evm/scroll/raw/logs

Smart contract event logs on Scroll — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# scroll.traces
Source: https://docs.dune.com/data-catalog/evm/scroll/raw/traces

Internal transaction traces on Scroll — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# scroll.transactions
Source: https://docs.dune.com/data-catalog/evm/scroll/raw/transactions

Every transaction on Scroll — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# sei.cosmos_block_events
Source: https://docs.dune.com/data-catalog/evm/sei/cosmos/cosmos_block_events

Block-level events emitted during block processing on Sei.

## Table description

The `sei.cosmos_block_events` table contains all block-level events and attributes in the chain, partitioned by `event_index`.

## Column Descriptions

| Column name          | Data Type                   | Description                                          |
| -------------------- | --------------------------- | ---------------------------------------------------- |
| **block\_date**      | date                        | The date of the block.                               |
| **block\_height**    | bigint                      | The height of the block where the event occurred.    |
| **block\_timestamp** | timestamp(3) with time zone | Timestamp when the block was validated.              |
| **chain\_id**        | varchar                     | The ID of the chain where the block belongs.         |
| **event\_index**     | bigint                      | A unique index for events within the block.          |
| **event\_type**      | varchar                     | The type of event that was triggered.                |
| **event\_source**    | varchar                     | The source of the event.                             |
| **attribute\_key**   | varchar                     | The key of the event attribute.                      |
| **attribute\_value** | varchar                     | The value of the event attribute.                    |
| **attribute\_index** | bigint                      | A unique index for attributes within the event.      |
| **updated\_at**      | timestamp(3) with time zone | Timestamp of when the record was last updated.       |
| **ingested\_at**     | timestamp(3) with time zone | Timestamp of when the record was ingested into Dune. |

## Table Sample

<TableSample />


# sei.cosmos_blocks
Source: https://docs.dune.com/data-catalog/evm/sei/cosmos/cosmos_blocks

Block data — block height, timestamp, proposer, and transaction count on Sei.

## Table description

The `sei.cosmos_blocks` table contains each validated block in the chain. `block_timestamp` is only available in this table, so you need to do an inner join on `block_height` to get `block_timestamp` to other tables.

## Column Descriptions

| Column name           | Data Type                   | Description                                                  |
| --------------------- | --------------------------- | ------------------------------------------------------------ |
| **block\_date**       | date                        | The date of the block.                                       |
| **block\_height**     | bigint                      | The height of the block, a unique identifier for each block. |
| **block\_timestamp**  | timestamp(3) with time zone | Timestamp when the block was validated.                      |
| **chain\_id**         | varchar                     | The ID of the chain where the block belongs.                 |
| **proposer\_address** | varchar                     | The address of the validator proposing the block.            |
| **validators\_hash**  | varchar                     | The hash of the validators set for the block.                |
| **updated\_at**       | timestamp(3) with time zone | Timestamp of when the record was last updated.               |
| **ingested\_at**      | timestamp(3) with time zone | Timestamp of when the record was ingested into Dune.         |

## Table Sample

<TableSample />


# sei.cosmos_message_events
Source: https://docs.dune.com/data-catalog/evm/sei/cosmos/cosmos_message_events

Message-level events — events emitted by specific transaction messages on Sei.

## Table description

Contains all events and their corresponding attributes partitioned by `message_index`. Events are linked to transactions via column `tx_id`.

<Tip>
  On execution, transactions from Cosmos emit data in two formats:

  * Messages (`sei.cosmos_tx_messages`): These provide a high-level, readable summary of actions, such as "send money" or "execute contract." They are easier to understand and track transaction types.
  * Events (`sei.cosmos_message_events`): These capture detailed, low-level changes at the chain level, including underlying blockchain modifications that may not always be directly related to state changes.
  * Use Messages for a general overview and Events when you need detailed insights. The two tables are complementary.
</Tip>

## Column Descriptions

| Column name          | Data Type                   | Description                                               |
| -------------------- | --------------------------- | --------------------------------------------------------- |
| **block\_date**      | date                        | The date of the block.                                    |
| **block\_height**    | bigint                      | The height of the block where the message event occurred. |
| **block\_timestamp** | timestamp(3) with time zone | Timestamp when the block was validated.                   |
| **chain\_id**        | varchar                     | The ID of the chain where the message event belongs.      |
| **tx\_id**           | varchar                     | The hash of the transaction containing the message event. |
| **tx\_index**        | bigint                      | The index of the transaction in the block.                |
| **message\_index**   | bigint                      | The index of the message in the transaction.              |
| **event\_index**     | bigint                      | The index of the event in the message.                    |
| **event\_type**      | varchar                     | The type of event that was triggered.                     |
| **event\_source**    | varchar                     | The source of the event.                                  |
| **attribute\_key**   | varchar                     | The key of the event attribute.                           |
| **attribute\_value** | varchar                     | The value of the event attribute.                         |
| **attribute\_index** | bigint                      | A unique index for attributes within the event.           |
| **updated\_at**      | timestamp(3) with time zone | Timestamp of when the record was last updated.            |
| **ingested\_at**     | timestamp(3) with time zone | Timestamp of when the record was ingested into Dune.      |

## Table Sample

<TableSample />


# sei.cosmos_transactions
Source: https://docs.dune.com/data-catalog/evm/sei/cosmos/cosmos_transactions

Transaction records — messages, fees, gas, and execution status on Sei.

## Table description

The `sei.cosmos_transactions` table contains relevant data associated with each transaction.

## Column Descriptions

| Column name            | Data Type                   | Description                                             |
| ---------------------- | --------------------------- | ------------------------------------------------------- |
| **block\_height**      | bigint                      | The height of the block where the transaction occurred. |
| **chain\_id**          | varchar                     | The ID of the chain where the transaction occurred.     |
| **tx\_id**             | varchar                     | The unique ID of the transaction.                       |
| **tx\_info**           | varchar                     | Information related to the transaction.                 |
| **tx\_log\_message**   | varchar                     | The log message associated with the transaction.        |
| **memo**               | varchar                     | A memo associated with the transaction.                 |
| **fee**                | varchar                     | The fee associated with the transaction.                |
| **tx\_code**           | bigint                      | The result code of the transaction.                     |
| **tx\_index**          | bigint                      | The index of the transaction within the block.          |
| **gas\_used**          | bigint                      | The amount of gas used by the transaction.              |
| **gas\_wanted**        | bigint                      | The amount of gas requested by the transaction.         |
| **schema\_version**    | bigint                      | The schema version for the transaction data.            |
| **fee\_coins**         | varchar                     | The coins used to pay the transaction fee.              |
| **fee\_granter**       | varchar                     | The address granting the fee for the transaction.       |
| **fee\_payer**         | varchar                     | The address paying the fee for the transaction.         |
| **gas\_limit**         | bigint                      | The gas limit set for the transaction.                  |
| **single\_sign\_mode** | bigint                      | The signing mode for single-signature transactions.     |
| **multi\_sign\_json**  | varchar                     | JSON structure for multi-signature transactions.        |
| **timeout\_height**    | varchar                     | The timeout height set for the transaction.             |
| **updated\_at**        | timestamp(3) with time zone | Timestamp of when the record was last updated.          |
| **ingested\_at**       | timestamp(3) with time zone | Timestamp of when the record was ingested into Dune.    |

## Table Sample

<TableSample />


# sei.cosmos_tx_messages
Source: https://docs.dune.com/data-catalog/evm/sei/cosmos/cosmos_tx_messages

Transaction messages — individual message types and payloads on Sei.

## Table description

The `sei.cosmos_tx_messages` table contains all messages submitted to the blockchain. Each row represents one message, so there may be repeated `tx_id` if the transaction contains multiple messages.

<Tip>
  On execution, transactions from Cosmos emit data in two formats:

  * Messages (`sei.cosmos_tx_messages`): These provide a high-level, readable summary of actions, such as "send money" or "execute contract." They are easier to understand and track transaction types.
  * Events (`sei.cosmos_message_events`): These capture detailed, low-level changes at the chain level, including underlying blockchain modifications that may not always be directly related to state changes.
  * Use Messages for a general overview and Events when you need detailed insights. The two tables are complementary.
</Tip>

## Column Description

| Column name          | Data Type                   | Description                                          |
| -------------------- | --------------------------- | ---------------------------------------------------- |
| **block\_date**      | date                        | The date of the block.                               |
| **block\_height**    | bigint                      | The height of the block where the message occurred.  |
| **block\_timestamp** | timestamp(3) with time zone | Timestamp when the block was validated.              |
| **chain\_id**        | varchar                     | The ID of the chain where the message belongs.       |
| **tx\_id**           | varchar                     | The hash of the transaction containing the message.  |
| **tx\_index**        | bigint                      | The index of the transaction in the block.           |
| **message\_index**   | bigint                      | The index of the message in the transaction.         |
| **message\_type**    | varchar                     | The type of message.                                 |
| **message**          | varchar                     | The value/content of the message.                    |
| **schema\_version**  | bigint                      | The version of the schema in provider database.      |
| **updated\_at**      | timestamp(3) with time zone | Timestamp of when the record was last updated.       |
| **ingested\_at**     | timestamp(3) with time zone | Timestamp of when the record was ingested into Dune. |

## Table Sample

<TableSample />


# sei.cosmos_validators
Source: https://docs.dune.com/data-catalog/evm/sei/cosmos/cosmos_validators

Validator set data — operator address, voting power, and commission on Sei.

## Table description

The `sei.cosmos_validators` table maps validator addresses to monikers (human-readable description) and other metadata.

## Column Descriptions

| Column name                       | Data Type                   | Description                                                        |
| --------------------------------- | --------------------------- | ------------------------------------------------------------------ |
| **operator\_address**             | varchar                     | The operator address of the validator.                             |
| **account\_address**              | varchar                     | The account address of the validator.                              |
| **consensus\_pubkey**             | varchar                     | The consensus public key of the validator.                         |
| **jailed**                        | boolean                     | Indicates whether the validator is jailed.                         |
| **status**                        | varchar                     | The status of the validator (e.g., active, inactive).              |
| **tokens**                        | varchar                     | The number of tokens held by the validator.                        |
| **moniker**                       | varchar                     | The moniker or name of the validator.                              |
| **identity**                      | varchar                     | The identity information of the validator.                         |
| **website**                       | varchar                     | The website of the validator.                                      |
| **security\_contact**             | varchar                     | The security contact information for the validator.                |
| **details**                       | varchar                     | Additional details about the validator.                            |
| **unbonding\_height**             | bigint                      | The block height at which the validator started unbonding.         |
| **unbonding\_time**               | varchar                     | The time when the validator will complete unbonding.               |
| **commission\_rate**              | double                      | The commission rate charged by the validator.                      |
| **commission\_max\_rate**         | double                      | The maximum commission rate allowed for the validator.             |
| **commission\_max\_change\_rate** | double                      | The maximum rate at which the validator can change its commission. |
| **commission\_update\_time**      | varchar                     | The time when the validator last updated its commission.           |
| **min\_self\_delegation**         | varchar                     | The minimum self-delegation required for the validator.            |
| **snapshot\_height**              | bigint                      | The block height at which the snapshot was taken.                  |
| **snapshot\_time**                | varchar                     | The time when the snapshot was taken.                              |
| **updated\_at**                   | timestamp(3) with time zone | Timestamp of when the record was last updated.                     |
| **ingested\_at**                  | timestamp(3) with time zone | Timestamp of when the record was ingested into Dune.               |

## Table Sample

<TableSample />


# dex_aggregator.trades on sei
Source: https://docs.dune.com/data-catalog/evm/sei/curated-data/dex/dex-aggregator-trades

DEX aggregator swaps on Sei — trades routed through aggregators like 1inch, Paraswap, and CoW Swap with pricing and routing details.

<DexAggregatorTradesSnippet />


# dex.trades on sei
Source: https://docs.dune.com/data-catalog/evm/sei/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on sei.

<DexTradesSnippet />


# NFT.trades on sei
Source: https://docs.dune.com/data-catalog/evm/sei/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on sei.

<NFTTradesSnippet />


# Sei Call Tables
Source: https://docs.dune.com/data-catalog/evm/sei/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Sei network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# sei.contracts
Source: https://docs.dune.com/data-catalog/evm/sei/decoded/contracts

Verified contract registry on Sei — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs
Source: https://docs.dune.com/data-catalog/evm/sei/decoded/event-logs

Smart Contracts emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# sei.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/sei/decoded/logs-decoded

ABI-decoded event logs on Sei — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Sei Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/sei/decoded/overview

Simplifying Sei smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# sei.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/sei/decoded/traces-decoded

ABI-decoded function calls on Sei — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Sei Overview
Source: https://docs.dune.com/data-catalog/evm/sei/overview

Sei data on Dune

## What is Sei?

Sei is a Layer-1 blockchain optimized for trading and decentralized finance (DeFi). It combines the strengths of Solana and Ethereum by implementing a fast parallelized EVM chain, providing a hyper optimized execution layer that benefits from the tooling and mindshare around the EVM.

<Warning>
  Sei is a Cosmos chain with EVM modules added in the [v2 upgrade](https://www.mintscan.io/sei/proposals/55). Dune indexes the EVM data separately from the Cosmos data. As such, data latency between the two can be expected.
</Warning>

<Tip>
  * Sei (v1) was originally a Cosmos chain. On May 20, 2024, a proposal to [upgrade Sei (v2) to include EVM support](https://www.mintscan.io/sei/proposals/55) was passed. Consequently, on May 27, 2024, Sei upgraded to [v2 with EVM support](https://github.com/sei-protocol/sei-chain/blob/main/CHANGELOG.md#v552).
  * Dune indexes the EVM component of Sei directly from RPC providers, supporting standard EVM chain decoding capabilities.
  * For Cosmos data, Dune partners with a data provider, and these tables and schemas can be found in the [Cosmos Data](#cosmos-data) section.
  * The EVM and Cosmos components share the same consensus mechanism, validated by the same validators, but they operate independently with interoperability features.
  * Interoperability between EVM and Cosmos relies on [EVM Precompiles](https://www.docs.sei.io/dev-interoperability/precompiles/addr) and [Pointer Contracts](https://www.docs.sei.io/dev-interoperability/pointer-contracts). If these do not emit events, it may result in data gaps.
  * Dune's EVM data for Sei starts from the v2 upgrade at [block height 73,123,881](https://seitrace.com/block/79123881).
</Tip>

### Parallelization

Parallelization allows Sei to process multiple independent transactions simultaneously, leveraging modern hardware capabilities for enhanced performance.

### Sei Optimizations

Sei introduces four major innovations:

1. **Twin Turbo Consensus**: This feature allows Sei to reach the fastest time to finality of any blockchain at 400ms, unlocking web2 like experiences for applications.
2. **Optimistic Parallelization**: This feature allows developers to unlock parallel processing for their Ethereum applications, with no additional work.
3. **SeiDB**: This major upgrade allows Sei to handle the much higher rate of data storage, reads and writes which become extremely important for a high performance blockchain.
4. **Interoperable EVM**: This allows existing developers in the Ethereum ecosystem to deploy their applications, tooling and infrastructure to Sei with no changes, while benefiting from the 100x performance improvements offered by Sei.

### Performance Metrics

* **Time to Finality**: 400 milliseconds
* **Transactions per Second**: 5,030 (12,500 theoretical max)

### Virtual Machine Interoperability

Sei supports both EVM and CosmWasm smart contracts in different execution environments. It introduces interoperability features, such as precompiled EVM contracts and Pointer Contracts, to enable smooth interactions between both environments.

For more details, visit [Sei Interoperability Documentation](https://www.docs.sei.io/dev-interoperability).

<CardGroup>
  <Card title="Sei documentation" icon="link" href="https://www.docs.sei.io/">
    Explore comprehensive documentation on Sei, detailing its architecture, protocol, and resources for developers.
  </Card>
</CardGroup>

## Data Catalog

### EVM Data

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Access detailed event logs from smart contracts to analyze contract activity and interactions.
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Explore data on blocks processed by the Sei chain, illustrating network throughput and activity.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Transaction details that highlight the efficiency and speed of the Sei chain.
  </Card>

  <Card title="decoded" icon="file" href="./decoded/overview">
    Decoded transaction data for easier analysis and deeper understanding of contract executions.
  </Card>
</CardGroup>

### Cosmos Data

<Tip>
  Timestamp is only available on block level tables (e.g. `sei.cosmos_blocks`) with field `block_timestamp`, so you need to do an inner join on `block_height` to get timestamp to other tables.
</Tip>

<CardGroup>
  <Card title="Blocks" icon="cube" href="/data-catalog/evm/sei/cosmos/cosmos_blocks">
    Contains each validated block in the chain.
  </Card>

  <Card title="Block Events" icon="note-sticky" href="/data-catalog/evm/sei/cosmos/cosmos_block_events">
    Contains all block-level events and attributes in the chain, partitioned by event\_index.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="/data-catalog/evm/sei/cosmos/cosmos_transactions">
    Contains relevant data associated with each transaction.
  </Card>

  <Card title="Transaction Message Events" icon="notes" href="/data-catalog/evm/sei/cosmos/cosmos_message_events">
    Contains all events and their corresponding attributes partitioned by message\_index.
  </Card>

  <Card title="Transaction Messages" icon="note" href="/data-catalog/evm/sei/cosmos/cosmos_tx_messages">
    Contains all messages submitted to the blockchain.
  </Card>

  <Card title="Validators" icon="badge-check" href="/data-catalog/evm/sei/cosmos/cosmos_validators">
    Maps validator addresses to monikers (human-readable description) and other metadata.
  </Card>
</CardGroup>


# sei.blocks
Source: https://docs.dune.com/data-catalog/evm/sei/raw/blocks

Block data — block height, timestamp, and metadata on Sei.

<BlockSnippet />


# sei.creation_traces
Source: https://docs.dune.com/data-catalog/evm/sei/raw/creation-traces

Contract deployment records on Sei — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# sei.logs
Source: https://docs.dune.com/data-catalog/evm/sei/raw/logs

Smart contract event logs on Sei — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# sei.traces
Source: https://docs.dune.com/data-catalog/evm/sei/raw/traces

Internal transaction traces on Sei — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# sei.transactions
Source: https://docs.dune.com/data-catalog/evm/sei/raw/transactions

Transaction records — messages, fees, and execution results on Sei.

<TransactionsSnippet />


# Sepolia Call Tables
Source: https://docs.dune.com/data-catalog/evm/sepolia/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Sepolia network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# sepolia.contracts
Source: https://docs.dune.com/data-catalog/evm/sepolia/decoded/contracts

Verified contract registry on Sepolia — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs
Source: https://docs.dune.com/data-catalog/evm/sepolia/decoded/event-logs

Smart Contracts emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# sepolia.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/sepolia/decoded/logs-decoded

ABI-decoded event logs on Sepolia — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Sepolia Testnet Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/sepolia/decoded/overview

Simplifying Sepolia Testnet smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# sepolia.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/sepolia/decoded/traces-decoded

ABI-decoded function calls on Sepolia — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Sepolia Testnet Overview
Source: https://docs.dune.com/data-catalog/evm/sepolia/overview

Sepolia data on Dune Analytics

Sepolia is an Ethereum testnet that provides a stable environment for developers to test and deploy their applications before launching on the Ethereum mainnet. Sepolia is designed to mirror the conditions of the mainnet, providing a realistic testing environment without the financial risks.

### Key Features:

* **Mainnet Parity:** Sepolia offers an environment that closely replicates the Ethereum mainnet, allowing developers to test their applications under conditions similar to the mainnet.

* **EVM Compatibility:** Sepolia supports all Ethereum Virtual Machine (EVM) compatible codebases, enabling seamless testing and deployment of smart contracts and decentralized applications (dApps).

* **Cost-Effective Testing:** Transactions on Sepolia are conducted using test ETH, which has no real-world value, allowing developers to experiment and troubleshoot without incurring any costs.

* **Stability and Reliability:** Sepolia is maintained to ensure a stable and reliable test environment, providing developers with confidence that their applications will perform as expected on the mainnet.

* **Community Support:** Sepolia is backed by a robust community of developers and enthusiasts who contribute to its maintenance and improvement, ensuring it remains a valuable resource for the Ethereum ecosystem.

<CardGroup>
  <Card title="Sepolia documentation" icon="link" href="https://sepolia.dev/">
    Explore comprehensive documentation on Sepolia, detailing its architecture, protocol, and resources for developers.
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Detailed event logs from smart contracts, providing insights into interactions within the Sepolia network.
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on blocks, illustrating the operational capacity and activity levels on Sepolia.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Extensive transaction data, showcasing the efficiency and execution of operations on Sepolia.
  </Card>

  <Card title="Decoded" icon="file" href="./decoded/overview">
    Enhanced transaction data decoded for better analysis and understanding of contract executions.
  </Card>
</CardGroup>


# sepolia.blocks
Source: https://docs.dune.com/data-catalog/evm/sepolia/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Sepolia.

<BlockSnippet />


# sepolia.creation_traces
Source: https://docs.dune.com/data-catalog/evm/sepolia/raw/creation-traces

Contract deployment records on Sepolia — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# sepolia.logs
Source: https://docs.dune.com/data-catalog/evm/sepolia/raw/logs

Smart contract event logs on Sepolia — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# sepolia.traces
Source: https://docs.dune.com/data-catalog/evm/sepolia/raw/traces

Internal transaction traces on Sepolia — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# sepolia.transactions
Source: https://docs.dune.com/data-catalog/evm/sepolia/raw/transactions

Every transaction on Sepolia — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex_aggregator.trades on shape
Source: https://docs.dune.com/data-catalog/evm/shape/curated-data/dex/dex-aggregator-trades

DEX aggregator swaps on Shape — trades routed through aggregators like 1inch, Paraswap, and CoW Swap with pricing and routing details.

<DexAggregatorTradesSnippet />


# dex.trades on shape
Source: https://docs.dune.com/data-catalog/evm/shape/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on shape.

<DexTradesSnippet />


# NFT.trades on shape
Source: https://docs.dune.com/data-catalog/evm/shape/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on shape.

<NFTTradesSnippet />


# Shape Call Tables
Source: https://docs.dune.com/data-catalog/evm/shape/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Shape network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# shape.contracts
Source: https://docs.dune.com/data-catalog/evm/shape/decoded/contracts

Verified contract registry on Shape — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs
Source: https://docs.dune.com/data-catalog/evm/shape/decoded/event-logs

Smart Contracts emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# shape.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/shape/decoded/logs-decoded

ABI-decoded event logs on Shape — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Shape Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/shape/decoded/overview

Simplifying Shape smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# shape.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/shape/decoded/traces-decoded

ABI-decoded function calls on Shape — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Shape Overview
Source: https://docs.dune.com/data-catalog/evm/shape/overview

Shape data on Dune

Shape is the chain for creators, built on top of Ethereum. It is an EVM equivalent Layer 2 scaling solution that inherits its security directly from Ethereum, keeping the networks intrinsically linked forever.

**Chain for Creators with Gasback:**
As a creator on Shape, you can claim back 80% of sequencer fees users spend interacting with your contracts. This includes contracts you build yourself, contracts you acquire ownership of, and contracts that you deploy through other platforms.

**EVM Equivalent:**
Shape is fully EVM equivalent, providing the same creator experience as on Ethereum, just at a fraction of the cost. This enables developers to deploy existing smart contracts and dApps without the need for extensive modifications.

**Secure, Stable & Scalable:**
Shape inherits its security directly from Ethereum and prioritizes stability and scalability, utilizing Alchemy and Optimism as key infrastructure partners to help achieve and maintain these states.

**Part of the Superchain:**
Shape is a member of the Superchain, which unlocks a range of further benefits for the entire ecosystem - including ongoing network-level cooperation, funding of public goods, and additional builder incentives on Shape.

<CardGroup>
  <Card title="Shape documentation" icon="link" href="https://docs.shape.network/documentation/introduction">
    Access comprehensive documentation for Shape, providing detailed insights into its technology, platform architecture, and how to build on it.
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Detailed event logs from smart contracts, offering insights into contract interactions and the dynamics of Shape's operations.
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on blocks processed through Shape, illustrating the network's enhanced throughput and scalability.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Extensive transaction data, highlighting the efficiency and reduced costs of operations on Shape.
  </Card>

  <Card title="decoded" icon="file" href="./decoded/overview">
    Decoded transaction data for easier analysis and deeper understanding of smart contract executions on the Shape network.
  </Card>
</CardGroup>


# shape.blocks
Source: https://docs.dune.com/data-catalog/evm/shape/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Shape.

<BlockSnippet />


# shape.creation_traces
Source: https://docs.dune.com/data-catalog/evm/shape/raw/creation-traces

Contract deployment records on Shape — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# shape.logs
Source: https://docs.dune.com/data-catalog/evm/shape/raw/logs

Smart contract event logs on Shape — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# shape.traces
Source: https://docs.dune.com/data-catalog/evm/shape/raw/traces

Internal transaction traces on Shape — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# shape.transactions
Source: https://docs.dune.com/data-catalog/evm/shape/raw/transactions

Every transaction on Shape — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex.trades on somnia
Source: https://docs.dune.com/data-catalog/evm/somnia/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on somnia.

<DexTradesSnippet />


# Somnia Call Tables
Source: https://docs.dune.com/data-catalog/evm/somnia/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Somnia network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# somnia.contracts
Source: https://docs.dune.com/data-catalog/evm/somnia/decoded/contracts

Verified contract registry on Somnia — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# somnia.event_logs
Source: https://docs.dune.com/data-catalog/evm/somnia/decoded/event-logs

Smart contract event logs on Somnia — indexed topics and data fields emitted during transaction execution.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# somnia.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/somnia/decoded/logs-decoded

ABI-decoded event logs on Somnia — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Somnia Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/somnia/decoded/overview

Simplifying Somnia smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# somnia.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/somnia/decoded/traces-decoded

ABI-decoded function calls on Somnia — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Somnia Overview
Source: https://docs.dune.com/data-catalog/evm/somnia/overview

Somnia data on Dune

## What is Somnia?

Somnia is a high-performance, cost-efficient EVM-compatible Layer 1 blockchain capable of processing over 1,000,000 transactions per second (TPS) with sub-second finality. It is suitable for serving millions of users and building real-time mass-consumer applications like games, social applications, metaverses, and more, all fully on-chain.

## Key Features

* **Ultra-High Performance**: Capable of processing over 1,000,000 TPS with sub-second finality
* **EVM-Compatible**: Full compatibility with Ethereum smart contracts and tooling
* **Mass-Consumer Focus**: Designed for real-time applications serving millions of users
* **Cost-Efficient**: Optimized for high-throughput, low-cost transactions
* **Gaming & Metaverse Ready**: Specialized infrastructure for gaming and metaverse applications
* **Social Applications**: Built to support large-scale social platforms and applications

## Performance Benchmarks

* **1,050,000 TPS**: Achieved with ERC-20 transfers between several hundred thousand accounts
* **50,000 Uniswaps per second**: Running Uniswap V3 with several hundred thousand accounts trading one LP pool
* **300,000 NFT mints per second**: Supporting 100,000 accounts minting NFTs simultaneously

## Ecosystem Highlights

* High-performance infrastructure for mass-consumer applications
* Gaming and metaverse platform capabilities
* Social application support at scale
* Real-time transaction processing
* Support for various application types including:
  * Games
  * Social applications
  * Metaverses
  * Real-time consumer applications
  * High-throughput DeFi protocols

## Data on Dune

<CardGroup>
  <Card title="Raw Data" icon="database" href="/data-catalog/evm/somnia/raw/blocks">
    Access to raw blockchain data including blocks, transactions, logs, and traces
  </Card>

  <Card title="Decoded Data" icon="code" href="/data-catalog/evm/somnia/decoded/overview">
    Human-readable contract interactions and events
  </Card>
</CardGroup>

## Resources

<CardGroup>
  <Card title="Somnia Documentation" icon="link" href="https://docs.somnia.network/">
    Official documentation for developers building on Somnia
  </Card>
</CardGroup>


# somnia.blocks
Source: https://docs.dune.com/data-catalog/evm/somnia/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Somnia.

<BlockSnippet />


# somnia.creation_traces
Source: https://docs.dune.com/data-catalog/evm/somnia/raw/creation-traces

Contract deployment records on Somnia — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# somnia.logs
Source: https://docs.dune.com/data-catalog/evm/somnia/raw/logs

Smart contract event logs on Somnia — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# somnia.traces
Source: https://docs.dune.com/data-catalog/evm/somnia/raw/traces

Internal transaction traces on Somnia — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# somnia.transactions
Source: https://docs.dune.com/data-catalog/evm/somnia/raw/transactions

Every transaction on Somnia — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex_aggregator.trades on sonic
Source: https://docs.dune.com/data-catalog/evm/sonic/curated-data/dex/dex-aggregator-trades

DEX aggregator swaps on Sonic — trades routed through aggregators like 1inch, Paraswap, and CoW Swap with pricing and routing details.

<DexAggregatorTradesSnippet />


# dex.trades on sonic
Source: https://docs.dune.com/data-catalog/evm/sonic/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on sonic.

<DexTradesSnippet />


# NFT.trades on sonic
Source: https://docs.dune.com/data-catalog/evm/sonic/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on sonic.

<NFTTradesSnippet />


# Sonic Call Tables
Source: https://docs.dune.com/data-catalog/evm/sonic/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Sonic network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# sonic.contracts
Source: https://docs.dune.com/data-catalog/evm/sonic/decoded/contracts

Verified contract registry on Sonic — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs
Source: https://docs.dune.com/data-catalog/evm/sonic/decoded/event-logs

Smart Contracts emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# sonic.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/sonic/decoded/logs-decoded

ABI-decoded event logs on Sonic — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Sonic Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/sonic/decoded/overview

Simplifying Sonic smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# sonic.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/sonic/decoded/traces-decoded

ABI-decoded function calls on Sonic — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Sonic Overview
Source: https://docs.dune.com/data-catalog/evm/sonic/overview

Sonic data on Dune

Sonic is an EVM layer-1 blockchain platform that offers developers attractive incentives and powerful infrastructure, powering the next generation of decentralized applications. The platform features exceptional performance metrics including 10,000 transactions per second and sub-second finality while maintaining full EVM compatibility.

**High Scalability and Efficiency:**
Sonic delivers exceptional performance with:

* 10,000 Transactions per Second
* Sub-Second Finality
* Low Transaction Costs
* Full EVM Compatibility

**Strong Security and Ethereum Compatibility:**
Sonic maintains robust security through its aBFT (asynchronous Byzantine Fault Tolerance) consensus while offering full EVM compatibility. This allows developers to easily port their Ethereum applications to Sonic or build new ones using familiar tools and languages.

**Developer-Friendly Environment:**
Sonic provides developers with powerful incentives and infrastructure including:

* Fee Monetization: Earn up to 90% of the fees your apps generate
* Innovator Fund: Up to 200 million S to support new ventures
* Solidity/Vyper Support
* Comprehensive development tooling

<CardGroup>
  <Card title="Sonic documentation" icon="link" href="https://docs.soniclabs.com/sonic/overview">
    Access comprehensive documentation for Sonic, providing detailed insights into its consensus mechanism, architecture, and development resources.
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Detailed event logs from smart contracts, offering insights into contract interactions and network activities on Sonic.
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on blocks processed through Sonic's Lachesis consensus, demonstrating the network's high throughput and fast finality.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Extensive transaction data, showcasing the high-performance and cost-effective nature of operations on Sonic.
  </Card>

  <Card title="decoded" icon="file" href="./decoded/overview">
    Decoded transaction data for easier analysis and deeper understanding of smart contract executions on the Sonic network.
  </Card>
</CardGroup>


# sonic.blocks
Source: https://docs.dune.com/data-catalog/evm/sonic/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Sonic.

<BlockSnippet />


# sonic.creation_traces
Source: https://docs.dune.com/data-catalog/evm/sonic/raw/creation-traces

Contract deployment records on Sonic — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# sonic.logs
Source: https://docs.dune.com/data-catalog/evm/sonic/raw/logs

Smart contract event logs on Sonic — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# sonic.traces
Source: https://docs.dune.com/data-catalog/evm/sonic/raw/traces

Internal transaction traces on Sonic — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# sonic.transactions
Source: https://docs.dune.com/data-catalog/evm/sonic/raw/transactions

Every transaction on Sonic — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex_aggregator.trades on sophon
Source: https://docs.dune.com/data-catalog/evm/sophon/curated-data/dex/dex-aggregator-trades

DEX aggregator swaps on Sophon — trades routed through aggregators like 1inch, Paraswap, and CoW Swap with pricing and routing details.

<DexAggregatorTradesSnippet />


# dex.trades on sophon
Source: https://docs.dune.com/data-catalog/evm/sophon/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on sophon.

<DexTradesSnippet />


# NFT.trades on sophon
Source: https://docs.dune.com/data-catalog/evm/sophon/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on sophon.

<NFTTradesSnippet />


# Sophon Call Tables
Source: https://docs.dune.com/data-catalog/evm/sophon/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Sophon network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# sophon.contracts
Source: https://docs.dune.com/data-catalog/evm/sophon/decoded/contracts

Verified contract registry on Sophon — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs
Source: https://docs.dune.com/data-catalog/evm/sophon/decoded/event-logs

Smart Contracts emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# sophon.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/sophon/decoded/logs-decoded

ABI-decoded event logs on Sophon — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Sophon Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/sophon/decoded/overview

Simplifying Sophon smart contract analysis through human-readable tables.

<Warning>
  Due to bugs in the Sophon client, some contract creation traces are missing, and data in the code field is incomplete for certain blocks. Consequently, we cannot support factory and bytecode matching for this chain. Once the bugs are addressed, we will work to restore this functionality. We apologize for the inconvenience.
</Warning>

<OverviewDecodedDataApproach />


# sophon.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/sophon/decoded/traces-decoded

ABI-decoded function calls on Sophon — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Sophon Overview
Source: https://docs.dune.com/data-catalog/evm/sophon/overview

Sophon data on Dune

Sophon is a ZK chain that redefines onchain experiences by combining real applications with a simple user experience and high scalability. Built on ZK technology, Sophon aims to bring crypto accessibility to a wider audience while maintaining robust security and performance.

**Architecture and Technology:**
Sophon is built on three key technological pillars:

* **Validiums**: A ZK-based scaling solution that provides high throughput and security
* **The ZK Stack**: A comprehensive infrastructure that powers the network
* **Native Account Abstraction**: Built-in support for smart accounts and improved user experience
* **Paymasters**: Advanced fee abstraction mechanisms for better user onboarding

**Enhanced User Experience:**
Sophon focuses on simplifying the blockchain experience while maintaining high performance. The platform is designed to make crypto applications accessible to everyday users while providing the tools and infrastructure developers need to build sophisticated applications.

**Developer-Centric Approach:**
The platform provides a comprehensive environment for developers to build and deploy applications, with native support for advanced features like account abstraction and paymaster functionality, enabling more sophisticated and user-friendly dApps.

<CardGroup>
  <Card title="Sophon documentation" icon="link" href="https://docs.sophon.xyz/welcome">
    Access the official documentation for Sophon to explore its architecture, features, and development resources.
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Event logs from smart contracts, providing insights into interactions and activities on the Sophon network.
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on blocks processed using Sophon's ZK technology, reflecting the network's capacity for high transaction throughput.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Detailed transaction data, showcasing the operational efficiency and cost-effectiveness of Sophon's validium solution.
  </Card>

  <Card title="decoded" icon="file" href="./decoded/overview">
    Decoded transaction data for easier analysis and better understanding of smart contract executions on Sophon.
  </Card>
</CardGroup>


# sophon.blocks
Source: https://docs.dune.com/data-catalog/evm/sophon/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Sophon.

<BlockSnippet />


# sophon.creation_traces
Source: https://docs.dune.com/data-catalog/evm/sophon/raw/creation-traces

Contract deployment records on Sophon — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# sophon.logs
Source: https://docs.dune.com/data-catalog/evm/sophon/raw/logs

Smart contract event logs on Sophon — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# sophon.traces
Source: https://docs.dune.com/data-catalog/evm/sophon/raw/traces

Internal transaction traces on Sophon — cross-contract calls, delegate calls, and value transfers with full call stack context.

<Warning>
  You may see duplicate records in the `traces` table for the Sophon chain. This is not a bug, but a result of trace calls appearing twice within the same transaction. These consecutive calls—an outer and an inner call—are identical except for their gas values. They share the same `from`, `to`, `input`, `output`, `success`, and `value` fields.
</Warning>

<TracesSnippet />


# sophon.transactions
Source: https://docs.dune.com/data-catalog/evm/sophon/raw/transactions

Every transaction on Sophon — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex.trades on story
Source: https://docs.dune.com/data-catalog/evm/story/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on story.

<DexTradesSnippet />


# Story Call Tables
Source: https://docs.dune.com/data-catalog/evm/story/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Story network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# story.contracts
Source: https://docs.dune.com/data-catalog/evm/story/decoded/contracts

Verified contract registry on Story — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs
Source: https://docs.dune.com/data-catalog/evm/story/decoded/event-logs

Smart Contracts emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# story.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/story/decoded/logs-decoded

ABI-decoded event logs on Story — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Story Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/story/decoded/overview

Simplifying Story smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# story.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/story/decoded/traces-decoded

ABI-decoded function calls on Story — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Story Overview
Source: https://docs.dune.com/data-catalog/evm/story/overview

Story data on Dune

## What is Story?

Story is the world's IP blockchain - a purpose-built layer 1 blockchain designed specifically for intellectual property. You can register your IP on-chain and add usage terms to it in seconds, massively lowering the barrier to the currently complex & antiquated legal system for IP.

By making IP programmable on the blockchain, it becomes a transparent & decentralized global IP repository where AI agents (or any other software) and humans alike can transact on & monetize IP with a simple API call.

## Key Features and Advantages

### The World's IP Blockchain

Story Network is a purpose-built layer 1 blockchain achieving the best of EVM and Cosmos SDK. It is 100% EVM-compatible alongside deep execution layer optimizations to support graph data structures, purpose-built for handling complex data structures like IP quickly and cost-efficiently.

### Proof-of-Creativity Protocol

The "Proof-of-Creativity" Protocol, made up of smart contracts written in Solidity, are natively deployed on Story Network and allow anyone to onramp IP to Story.

* **IP Assets**: Creators register their IP as IP Assets on Story. IP could be an image, a song, an RWA, AI training data, or anything in-between.
* **Modules**: You use Modules to interact with IP Assets. For example:
  * **Licensing Module**: Enforcing proper usage of your IP
  * **Royalty Module**: Paying & claiming revenue
  * **Dispute Module**: Disputing infringing IP
* **Ownership**: Each IP Asset has an associated ERC721 NFT, which represents ownership over the IP. This means IP ownership can be bought & sold.
* **IPFi**: The licenses minted from an IP are also ERC721 NFTs, meaning you can buy & sell the rights to use an IP under certain terms, unlocking a new realm of IP Finance.

### Programmable IP License (PIL)

Although on-chain, an IP's usage terms and minted licenses are enforced by an off-chain legal contract called the Programmable IP License (PIL). The PIL allows anyone to offramp tokenized IP on Story into the "real world" legal system and outlines real legal terms for how creators can remix, monetize, and create derivatives of their IP.

### Network Specifications

* **Technology Stack**: EVM-compatible Layer 1 with Cosmos SDK
* **Gas Token**: \$IP
* **Network Type**: EVM-compatible Layer 1
* **Consensus**: CometBFT-based consensus layer for fast finality and cheap transactions
* **Optimizations**: Precompiled primitives to traverse complex data structures like IP graphs within seconds at marginal costs

### Developer Tools & Infrastructure

* **Full EVM Compatibility**: Support for standard Ethereum development tools
* **Smart Contract Development**: Solidity smart contracts
* **Graph Data Structures**: Purpose-built for handling complex IP data structures
* **Infrastructure**:
  * Cross-chain bridges (Stargate, deBridge, Orbiter Finance)
  * Stablecoin support (bridged USDC.e)
  * Wallet support (MetaMask, OKX, and other EVM-based wallets)

<CardGroup>
  <Card title="Story Documentation" icon="link" href="https://docs.story.foundation/introduction">
    Official documentation for developers building on Story
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Insights into smart contract interactions through event logs
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on blocks processed on Story
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Detailed data on transactions
  </Card>

  <Card title="decoded" icon="file" href="./decoded/overview">
    Decoded transaction information for enhanced analysis
  </Card>
</CardGroup>


# story.blocks
Source: https://docs.dune.com/data-catalog/evm/story/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Story.

<BlockSnippet />


# story.creation_traces
Source: https://docs.dune.com/data-catalog/evm/story/raw/creation-traces

Contract deployment records on Story — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# story.logs
Source: https://docs.dune.com/data-catalog/evm/story/raw/logs

Smart contract event logs on Story — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# story.traces
Source: https://docs.dune.com/data-catalog/evm/story/raw/traces

Internal transaction traces on Story — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# story.transactions
Source: https://docs.dune.com/data-catalog/evm/story/raw/transactions

Every transaction on Story — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex.trades on superseed
Source: https://docs.dune.com/data-catalog/evm/superseed/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on superseed.

<DexTradesSnippet />


# Hemi Call Tables
Source: https://docs.dune.com/data-catalog/evm/superseed/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Hemi network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# superseed.contracts
Source: https://docs.dune.com/data-catalog/evm/superseed/decoded/contracts

Verified contract registry on Superseed — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# superseed.event_logs
Source: https://docs.dune.com/data-catalog/evm/superseed/decoded/event-logs

Smart contract event logs on Superseed — indexed topics and data fields emitted during transaction execution.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# superseed.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/superseed/decoded/logs-decoded

ABI-decoded event logs on Superseed — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Superseed Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/superseed/decoded/overview

Simplifying Superseed smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# superseed.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/superseed/decoded/traces-decoded

ABI-decoded function calls on Superseed — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Superseed Overview
Source: https://docs.dune.com/data-catalog/evm/superseed/overview

Superseed data on Dune

## What is Superseed?

Superseed is a network that transforms Ethereum scaling into self-repaying loans. Built on the OP Stack, Superseed is an optimistic rollup that extends Ethereum's ability to enable financial freedom by maximizing capital efficiency and returning 100% of protocol revenue to users.

## Key Features

* **Zero Interest Yield**: Access yield at zero percent interest, with loans repaid effortlessly through protocol-generated fees
* **Proof-of-Repayment**: A unique programmatic reward mechanism where a small percentage of the native token's total supply is distributed daily through an auction, with proceeds used to repay Supercollateral users
* **Supercollateral**: Superseed's governance token plays a special role within the CDP protocol, allowing borrowers who meet safety requirements (e.g., a collateralization ratio of 500%) to secure loans without interest
* **Dynamic Repayment Vault**: Channels protocol fees into a smart contract that systematically burns debt, stabilizing the repayment rate for Supercollateral users
* **Native CDP Platform**: A Collateralized Debt Position platform enshrined in the rollup protocol
* **Superseed Stablecoin**: An overcollateralized stablecoin generated when users borrow against their assets, requiring collateral value to exceed 150% of the stablecoin's value

## Protocol Components

* **General-purpose Ethereum Layer 2**: Built on the OP stack, open-source, permissionless, and Ethereum-equivalent
* **CDP Protocol**: Native collateralized debt position platform integrated into the rollup
* **Revenue Sources**: Sequencer profits, CDP interest, and inflationary rewards
* **Automatic Loan Repayment**: All fees generated across the network are used to burn the debt of Supercollateral users

## Data on Dune

<CardGroup>
  <Card title="Raw Data" icon="database" href="/data-catalog/evm/superseed/raw/blocks">
    Access to raw blockchain data including blocks, transactions, logs, and traces
  </Card>

  <Card title="Decoded Data" icon="code" href="/data-catalog/evm/superseed/decoded/overview">
    Human-readable contract interactions and events
  </Card>
</CardGroup>

## Resources

<CardGroup>
  <Card title="Superseed Documentation" icon="link" href="https://docs.superseed.xyz/">
    Official documentation for developers building on Superseed
  </Card>
</CardGroup>


# superseed.blocks
Source: https://docs.dune.com/data-catalog/evm/superseed/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Superseed.

<BlockSnippet />


# superseed.creation_traces
Source: https://docs.dune.com/data-catalog/evm/superseed/raw/creation-traces

Contract deployment records on Superseed — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# superseed.logs
Source: https://docs.dune.com/data-catalog/evm/superseed/raw/logs

Smart contract event logs on Superseed — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# superseed.traces
Source: https://docs.dune.com/data-catalog/evm/superseed/raw/traces

Internal transaction traces on Superseed — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# superseed.transactions
Source: https://docs.dune.com/data-catalog/evm/superseed/raw/transactions

Every transaction on Superseed — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex.trades on tac
Source: https://docs.dune.com/data-catalog/evm/tac/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on tac.

<DexTradesSnippet />


# TAC Call Tables
Source: https://docs.dune.com/data-catalog/evm/tac/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the TAC network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# tac.contracts
Source: https://docs.dune.com/data-catalog/evm/tac/decoded/contracts

Verified contract registry on Tac — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# tac.event_logs
Source: https://docs.dune.com/data-catalog/evm/tac/decoded/event-logs

Smart contract event logs on Tac — indexed topics and data fields emitted during transaction execution.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# tac.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/tac/decoded/logs-decoded

ABI-decoded event logs on Tac — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# TAC Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/tac/decoded/overview

Simplifying TAC smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# tac.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/tac/decoded/traces-decoded

ABI-decoded function calls on Tac — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# TAC Overview
Source: https://docs.dune.com/data-catalog/evm/tac/overview

TAC data on Dune

## What is TAC?

TAC (The Asset Chain) is a Layer 2 blockchain built on Ethereum that provides a secure, scalable, and efficient platform for real-world asset tokenization and trading. It enables the seamless integration of traditional financial assets into the blockchain ecosystem, offering institutional-grade infrastructure for asset management and trading.

## Key Features

* **Real-World Asset Focus**: Specialized infrastructure for tokenizing and trading real-world assets
* **Ethereum L2**: Built on Ethereum for security and composability
* **Institutional Grade**: Designed to meet regulatory and institutional requirements
* **High Performance**: Optimized for high-throughput trading and asset management
* **Composability**: Seamless integration with the broader Ethereum ecosystem

## Ecosystem Highlights

* Advanced infrastructure for real-world asset tokenization
* Institutional-grade trading and settlement capabilities
* Regulatory-compliant framework for asset management
* Support for various asset classes including:
  * Real estate
  * Commodities
  * Private equity
  * Fixed income instruments
  * Alternative investments

## Data on Dune

<CardGroup>
  <Card title="Raw Data" icon="database" href="/data-catalog/evm/tac/raw/blocks">
    Access to raw blockchain data including blocks, transactions, logs, and traces
  </Card>

  <Card title="Decoded Data" icon="code" href="/data-catalog/evm/tac/decoded/overview">
    Human-readable contract interactions and events
  </Card>
</CardGroup>

## Resources

<CardGroup>
  <Card title="TAC Documentation" icon="link" href="https://docs.tac.build/core-concepts/overview/what-is-tac">
    Official documentation for developers building on TAC
  </Card>
</CardGroup>


# tac.blocks
Source: https://docs.dune.com/data-catalog/evm/tac/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Tac.

<BlockSnippet />


# tac.creation_traces
Source: https://docs.dune.com/data-catalog/evm/tac/raw/creation-traces

Contract deployment records on Tac — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# tac.logs
Source: https://docs.dune.com/data-catalog/evm/tac/raw/logs

Smart contract event logs on Tac — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# tac.traces
Source: https://docs.dune.com/data-catalog/evm/tac/raw/traces

Internal transaction traces on Tac — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# tac.transactions
Source: https://docs.dune.com/data-catalog/evm/tac/raw/transactions

Every transaction on Tac — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex.trades on taiko
Source: https://docs.dune.com/data-catalog/evm/taiko/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on taiko.

<DexTradesSnippet />


# Taiko Call Tables
Source: https://docs.dune.com/data-catalog/evm/taiko/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Taiko network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# taiko.contracts
Source: https://docs.dune.com/data-catalog/evm/taiko/decoded/contracts

Verified contract registry on Taiko — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# taiko.event_logs
Source: https://docs.dune.com/data-catalog/evm/taiko/decoded/event-logs

Smart contract event logs on Taiko — indexed topics and data fields emitted during transaction execution.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# taiko.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/taiko/decoded/logs-decoded

ABI-decoded event logs on Taiko — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Taiko Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/taiko/decoded/overview

Simplifying Taiko smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# taiko.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/taiko/decoded/traces-decoded

ABI-decoded function calls on Taiko — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Taiko Overview
Source: https://docs.dune.com/data-catalog/evm/taiko/overview

Taiko data on Dune

## What is Taiko?

Taiko is a decentralized, Ethereum-equivalent ZK-Rollup that provides a seamless and secure scaling solution for Ethereum. Built with the Taiko Alethia Protocol, it offers full EVM compatibility while maintaining the security and decentralization of Ethereum through zero-knowledge proofs.

## Key Features

* **Ethereum-Equivalent**: Full EVM compatibility with no modifications required
* **ZK-Rollup Technology**: Secure scaling through zero-knowledge proofs
* **Decentralized**: Maintains Ethereum's security and decentralization principles
* **High Performance**: Significantly higher throughput than Ethereum mainnet
* **Gas Efficiency**: Reduced transaction costs while maintaining security

## Ecosystem Highlights

* Based on the Taiko Alethia Protocol for secure and efficient scaling
* Full compatibility with existing Ethereum tools and infrastructure
* Decentralized sequencer network for enhanced security
* Support for all Ethereum smart contracts and dApps
* Advanced ZK-proof generation for transaction validation

## Data on Dune

<CardGroup>
  <Card title="Raw Data" icon="database" href="/data-catalog/evm/taiko/raw/blocks">
    Access to raw blockchain data including blocks, transactions, logs, and traces
  </Card>

  <Card title="Decoded Data" icon="code" href="/data-catalog/evm/taiko/decoded/overview">
    Human-readable contract interactions and events
  </Card>
</CardGroup>

## Resources

<CardGroup>
  <Card title="Taiko Documentation" icon="link" href="https://docs.taiko.xyz/taiko-alethia-protocol/what-is-taiko-alethia">
    Official documentation for developers building on Taiko
  </Card>
</CardGroup>


# taiko.blocks
Source: https://docs.dune.com/data-catalog/evm/taiko/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Taiko.

<BlockSnippet />


# taiko.creation_traces
Source: https://docs.dune.com/data-catalog/evm/taiko/raw/creation-traces

Contract deployment records on Taiko — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# taiko.logs
Source: https://docs.dune.com/data-catalog/evm/taiko/raw/logs

Smart contract event logs on Taiko — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# taiko.traces
Source: https://docs.dune.com/data-catalog/evm/taiko/raw/traces

Internal transaction traces on Taiko — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# taiko.transactions
Source: https://docs.dune.com/data-catalog/evm/taiko/raw/transactions

Every transaction on Taiko — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# Tempo Call Tables
Source: https://docs.dune.com/data-catalog/evm/tempo/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Tempo network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# tempo.contracts
Source: https://docs.dune.com/data-catalog/evm/tempo/decoded/contracts

Verified contract registry on Tempo — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs - Tempo
Source: https://docs.dune.com/data-catalog/evm/tempo/decoded/event-logs

Smart contracts on Tempo emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# tempo.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/tempo/decoded/logs-decoded

ABI-decoded event logs on Tempo — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Tempo Chain Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/tempo/decoded/overview

Simplifying Tempo Chain smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# tempo.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/tempo/decoded/traces-decoded

ABI-decoded function calls on Tempo — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Tempo Chain Overview
Source: https://docs.dune.com/data-catalog/evm/tempo/overview

Tempo blockchain data on Dune

## What is Tempo?

Tempo is a Layer 1 blockchain purpose-built for stablecoin payments at scale. Incubated by Paradigm and Stripe, Tempo is built on Paradigm's high-performance Ethereum client Reth and uses Simplex BFT consensus for sub-second, deterministic finality. It is fully EVM-compatible, allowing developers to use familiar Solidity tooling like Foundry and Hardhat.

Tempo is often referred to as a "stablechain" because its entire design is optimized around stablecoin-based payments rather than general-purpose computation.

## Key Features of Tempo

### **No Native Gas Token**

Unlike virtually every other blockchain, Tempo has no native cryptocurrency. Gas fees are paid directly in USD-denominated stablecoins (USDC, USDT, etc.) via a Fee AMM that converts user-selected fee tokens to validator-preferred assets. This means `value` fields in transactions and traces behave differently than on other EVM chains — there is no native ETH-like asset being transferred.

### **Sub-Second Finality**

Tempo produces blocks every \~0.5 seconds with deterministic, immediate finality powered by Simplex BFT consensus. Once a block is committed, it is final with no re-orgs or probabilistic finality.

### **Ultra-Low Fees**

Transaction costs target under \$0.001 per transaction, with dedicated payment lanes that reserve blockspace for payment transactions to ensure low fees even during congestion.

### **TIP-20 Token Standard**

Tempo extends ERC-20 with its own TIP-20 standard, adding currency identifiers (USD, EUR), gas payment capability, a 32-byte memo field for invoice IDs and metadata, reward distribution mechanisms, and compliance policy integration. TIP-20 events are indexed on Dune under `tip20_tempo.*` tables alongside standard ERC-20 tables.

### **Built-in StablecoinDEX**

A native decentralized exchange optimized for stablecoin conversions and tokenized deposits. The StablecoinDEX is decoded on Dune under `tempoexchange_tempo.stablecoindex_*` tables.

## EVM Differences Impacting Data

While Tempo is EVM-compatible, several design choices affect how data appears compared to standard EVM chains:

* **No native token**: The `value` field in transactions and traces is not meaningful in the traditional sense since there is no native gas token. Token transfers happen via TIP-20/ERC-20 events instead.
* **TIP-20 events**: In addition to standard ERC-20 `Transfer` and `Approval` events, Tempo tokens emit TIP-20-specific events like `TransferWithMemo`, `RewardDistributed`, `QuoteTokenUpdate`, `TransferPolicyUpdate`, and `SupplyCapUpdate`.
* **Gas paid in stablecoins**: Gas fee fields (`gas_price`, `max_fee_per_gas`) denominate fees in stablecoins rather than a native token, which affects `gas.fees` computations.

<CardGroup>
  <Card title="Tempo documentation" icon="link" href="https://docs.tempo.xyz">
    Access full documentation for Tempo, including architecture, token standards, and developer guides.
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Smart contract event logs on Tempo.
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on processed blocks, highlighting Tempo's sub-second throughput.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Data on transactions, illustrating Tempo's ultra-low-cost stablecoin payments.
  </Card>

  <Card title="Decoded" icon="file" href="./decoded/overview">
    Decoded transaction data for in-depth analysis of contract executions including the native StablecoinDEX and Uniswap deployments.
  </Card>
</CardGroup>


# tempo.blocks
Source: https://docs.dune.com/data-catalog/evm/tempo/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Tempo.

<BlockSnippet />


# tempo.creation_traces
Source: https://docs.dune.com/data-catalog/evm/tempo/raw/creation-traces

Contract deployment records on Tempo — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# tempo.logs
Source: https://docs.dune.com/data-catalog/evm/tempo/raw/logs

Smart contract event logs on Tempo — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# tempo.traces
Source: https://docs.dune.com/data-catalog/evm/tempo/raw/traces

Internal transaction traces on Tempo — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# tempo.transactions
Source: https://docs.dune.com/data-catalog/evm/tempo/raw/transactions

Every transaction on Tempo — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# Tezos EVM Call Tables
Source: https://docs.dune.com/data-catalog/evm/tezos_evm/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Tezos EVM network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# tezos_evm.contracts
Source: https://docs.dune.com/data-catalog/evm/tezos_evm/decoded/contracts

Verified contract registry on Tezos EVM — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs - Tezos EVM
Source: https://docs.dune.com/data-catalog/evm/tezos_evm/decoded/event-logs

Smart contracts on Tezos EVM emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null} theme={null} theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# tezos_evm.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/tezos_evm/decoded/logs-decoded

ABI-decoded event logs on Tezos EVM — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Tezos EVM Chain Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/tezos_evm/decoded/overview

Simplifying Tezos EVM smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# tezos_evm.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/tezos_evm/decoded/traces-decoded

ABI-decoded function calls on Tezos EVM — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Tezos EVM Chain Overview
Source: https://docs.dune.com/data-catalog/evm/tezos_evm/overview

Tezos EVM blockchain data on Dune

## What is Tezos EVM?

Tezos EVM is the EVM-compatible execution environment running as an L2 rollup on Tezos. It is an optimistic rollup that posts proofs back to Tezos L1 for settlement and uses Tezos' Smart Rollup framework for data availability. Standard Ethereum tooling (Solidity, Foundry, Hardhat, MetaMask, etc.) works without modification, while transaction costs and finality benefit from Tezos' underlying consensus.

## Key Features

* **EVM compatibility**: Full bytecode compatibility — Solidity contracts deploy with no source changes; Ethereum wallets and RPC clients work out of the box.
* **Tezos-backed settlement**: An optimistic rollup anchored to Tezos L1. Sequencing and DA leverage Tezos' Smart Rollup primitives, with fraud-proof–style dispute resolution on L1.
* **Sub-second blocks**: The chain produces a new block every \~2 seconds on average (verified against `tezos_evm.blocks` time deltas), enabling fast UX for trading and other latency-sensitive use cases.
* **Native gas token**: Gas is paid in XTZ (Tezos' native token) bridged into the EVM context, not ETH — be careful when comparing fee data with other EVM chains.

## Data on Dune

<CardGroup>
  <Card title="Raw Data" icon="database" href="/data-catalog/evm/tezos_evm/raw/blocks">
    Block, transaction, log, and trace data indexed directly from Tezos EVM nodes.
  </Card>

  <Card title="Decoded Data" icon="code" href="/data-catalog/evm/tezos_evm/decoded/overview">
    ABI-decoded contract interactions and events from verified Tezos EVM contracts.
  </Card>
</CardGroup>

## Resources

<CardGroup>
  <Card title="Tezos EVM" icon="link" href="https://www.etherlink.com/">
    Project home page.
  </Card>

  <Card title="Tezos EVM Documentation" icon="book" href="https://docs.etherlink.com/">
    Architecture, tooling, and developer guides.
  </Card>
</CardGroup>


# tezos_evm.blocks
Source: https://docs.dune.com/data-catalog/evm/tezos_evm/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Tezos EVM.

<BlockSnippet />


# tezos_evm.creation_traces
Source: https://docs.dune.com/data-catalog/evm/tezos_evm/raw/creation-traces

Contract deployment records on Tezos EVM — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# tezos_evm.logs
Source: https://docs.dune.com/data-catalog/evm/tezos_evm/raw/logs

Smart contract event logs on Tezos EVM — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# tezos_evm.traces
Source: https://docs.dune.com/data-catalog/evm/tezos_evm/raw/traces

Internal transaction traces on Tezos EVM — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# tezos_evm.transactions
Source: https://docs.dune.com/data-catalog/evm/tezos_evm/raw/transactions

Every transaction on Tezos EVM — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex_aggregator.trades on unichain
Source: https://docs.dune.com/data-catalog/evm/unichain/curated-data/dex/dex-aggregator-trades

DEX aggregator swaps on Unichain — trades routed through aggregators like 1inch, Paraswap, and CoW Swap with pricing and routing details.

<DexAggregatorTradesSnippet />


# dex.trades on unichain
Source: https://docs.dune.com/data-catalog/evm/unichain/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on unichain.

<DexTradesSnippet />


# NFT.trades on unichain
Source: https://docs.dune.com/data-catalog/evm/unichain/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on unichain.

<NFTTradesSnippet />


# Unichain Call Tables
Source: https://docs.dune.com/data-catalog/evm/unichain/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Unichain network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# unichain.contracts
Source: https://docs.dune.com/data-catalog/evm/unichain/decoded/contracts

Verified contract registry on Unichain — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs
Source: https://docs.dune.com/data-catalog/evm/unichain/decoded/event-logs

Smart Contracts emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# unichain.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/unichain/decoded/logs-decoded

ABI-decoded event logs on Unichain — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Unichain Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/unichain/decoded/overview

Simplifying Unichain smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# unichain.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/unichain/decoded/traces-decoded

ABI-decoded function calls on Unichain — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Unichain Overview
Source: https://docs.dune.com/data-catalog/evm/unichain/overview

Unichain data on Dune

Unichain is a DeFi-native Ethereum Layer 2 solution designed to be the home for cross-chain liquidity. It aims to revolutionize DeFi by providing the fastest, most cost-effective Layer 2 network for uniting fragmented blockchain ecosystems.

**Key Features:**

**Instant Transactions:**
Unichain launches with 1-second block times, with plans to achieve 250ms block times. This reduced latency significantly improves market efficiency by increasing arbitrage frequency and reducing MEV impact.

**Cost-Effective & Decentralized:**
Built to leverage Ethereum's scaling roadmap, Unichain reduces transaction costs by approximately 95% in the short term, with further reductions expected over time. While utilizing a single sequencer for efficiency, it enhances decentralization through full node block verification.

**Cross-Chain Liquidity:**
As part of the Superchain ecosystem, Unichain supports native interoperability across dozens of chains, making it seamless to access liquidity regardless of users' origin chains. Uniswap Labs continues to pioneer standards for seamless cross-chain interoperability.

<CardGroup>
  <Card title="Unichain documentation" icon="link" href="https://docs.unichain.org/docs">
    Explore comprehensive documentation on Unichain, including technical details and developer resources.
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Detailed event logs from smart contracts, providing insights into interactions within the Unichain network.
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on blocks, illustrating the operational capacity and activity levels on Unichain.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Extensive transaction data, showcasing the efficiency and execution of operations on Unichain.
  </Card>

  <Card title="decoded" icon="file" href="./decoded/overview">
    Enhanced transaction data decoded for better analysis and understanding of contract executions.
  </Card>
</CardGroup>


# unichain.blocks
Source: https://docs.dune.com/data-catalog/evm/unichain/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Unichain.

<BlockSnippet />


# unichain.creation_traces
Source: https://docs.dune.com/data-catalog/evm/unichain/raw/creation-traces

Contract deployment records on Unichain — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# unichain.logs
Source: https://docs.dune.com/data-catalog/evm/unichain/raw/logs

Smart contract event logs on Unichain — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# unichain.traces
Source: https://docs.dune.com/data-catalog/evm/unichain/raw/traces

Internal transaction traces on Unichain — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# unichain.transactions
Source: https://docs.dune.com/data-catalog/evm/unichain/raw/transactions

Every transaction on Unichain — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex.trades on viction
Source: https://docs.dune.com/data-catalog/evm/viction/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on viction.

<DexTradesSnippet />


# NFT.trades on viction
Source: https://docs.dune.com/data-catalog/evm/viction/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on viction.

<NFTTradesSnippet />


# Viction Call Tables
Source: https://docs.dune.com/data-catalog/evm/viction/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Viction network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# viction.contracts
Source: https://docs.dune.com/data-catalog/evm/viction/decoded/contracts

Verified contract registry on Viction — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs
Source: https://docs.dune.com/data-catalog/evm/viction/decoded/event-logs

Smart Contracts emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# viction.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/viction/decoded/logs-decoded

ABI-decoded event logs on Viction — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Viction Chain Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/viction/decoded/overview

Simplifying Viction Chain smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# viction.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/viction/decoded/traces-decoded

ABI-decoded function calls on Viction — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Viction Chain Overview
Source: https://docs.dune.com/data-catalog/evm/viction/overview

Viction blockchain data on Dune

## What is Viction?

Viction is a people-centric blockchain designed to make Web3 accessible and secure for all users. With zero-gas transactions and enhanced security, Viction empowers a wide range of applications, from decentralized finance to social networks and beyond. Viction introduces the **Viction World Wide Chain**, a groundbreaking network of app chains anchored by a common settlement layer, enabling extensive scalability and a seamless user experience.

## Key Features of Viction

Viction’s infrastructure centers around security, scalability, and ease of use, ensuring a smooth experience for both developers and end-users across the Web3 ecosystem.

### **Zero-Gas Transactions**

Viction removes cost barriers for users, enabling frequent and effortless in-chain transactions without the need for gas fees, making it an ideal platform for consumer-facing applications.

### **App Chain Scalability**

The Viction World Wide Chain supports a network of app chains that operate concurrently, anchored to Viction’s main chain. This allows each app chain to scale independently, enhancing overall network capacity while maintaining secure, frictionless interactions across chains.

### **EVM Compatibility**

With support for all EVM-compatible smart contracts, Viction allows Ethereum-based developers to build seamlessly on its platform, leveraging familiar tools like Solidity, Hardhat, and Remix.

## Network Architecture

Viction’s architecture is optimized for high performance, low-latency transactions, and robust security, accommodating a diverse ecosystem of decentralized applications.

* **150 Masternode Network:** Viction operates through a Proof-of-Stake Voting (PoSV) consensus with 150 masternodes, providing stability and incentivizing participation.
* **Interchain Connectivity via WWCP:** The Viction World Wide Chain Protocol (WWCP) facilitates seamless asset and data transfer between app chains, creating a cohesive ecosystem.

## Consensus Mechanism

Viction’s PoSV consensus combines security and scalability, incentivizing active participation from token holders and ensuring an equitable validation process.

* **Double Validation:** This feature enhances security by requiring each block to be validated by two independent masternodes, reducing the risk of forks and other attacks.
* **Fair Voting Mechanism:** All Viction token holders have the power to vote for masternodes, supporting a community-driven governance structure that aligns with Viction’s decentralized mission.

## Security and Reliability

Viction incorporates advanced security measures, including slashing and bailout options, to maintain network reliability and incentivize responsible behavior among validators.

* **Randomization for Security:** Randomized validator selection further secures the network by preventing collusion and increasing resilience to targeted attacks.
* **Validator Slashing and Bailout:** Misbehaving validators face slashing penalties, while a credit system allows recovery from unexpected downtime, promoting stability across the ecosystem.

## Token Economy

The native **VIC** token powers Viction’s economy, supporting staking rewards, governance, and ecosystem incentives.

* **Staking and Rewards:** Validators and delegators receive rewards for participating in block production and governance, encouraging ongoing involvement.
* **Governance Participation:** VIC token holders can delegate their stake to preferred masternode candidates, helping shape the future of the Viction network.

<CardGroup>
  <Card title="Viction Documentation" icon="link" href="https://docs.viction.xyz/">
    Explore the complete documentation for Viction, covering consensus mechanisms, security features, and developer resources.
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Access transaction logs and other activities on Viction, providing transparency into the chain’s operational data.
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on block production and finality, demonstrating Viction's capacity for high-throughput operations.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Transaction data showcasing Viction’s zero-gas approach, enabling low-cost interactions across applications.
  </Card>

  <Card title="Decoded" icon="file" href="./decoded/overview">
    Decoded transaction data, facilitating insights into Viction’s app chain interactions and economic activity.
  </Card>
</CardGroup>


# viction.blocks
Source: https://docs.dune.com/data-catalog/evm/viction/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Viction.

<BlockSnippet />


# viction.creation_traces
Source: https://docs.dune.com/data-catalog/evm/viction/raw/creation-traces

Contract deployment records on Viction — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# viction.logs
Source: https://docs.dune.com/data-catalog/evm/viction/raw/logs

Smart contract event logs on Viction — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# viction.traces
Source: https://docs.dune.com/data-catalog/evm/viction/raw/traces

Internal transaction traces on Viction — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# viction.transactions
Source: https://docs.dune.com/data-catalog/evm/viction/raw/transactions

Every transaction on Viction — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex_aggregator.trades on worldchain
Source: https://docs.dune.com/data-catalog/evm/worldchain/curated-data/dex/dex-aggregator-trades

DEX aggregator swaps on World Chain — trades routed through aggregators like 1inch, Paraswap, and CoW Swap with pricing and routing details.

<DexAggregatorTradesSnippet />


# dex.trades on worldchain
Source: https://docs.dune.com/data-catalog/evm/worldchain/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on worldchain.

<DexTradesSnippet />


# NFT.trades on worldchain
Source: https://docs.dune.com/data-catalog/evm/worldchain/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on worldchain.

<NFTTradesSnippet />


# World Chain Call Tables
Source: https://docs.dune.com/data-catalog/evm/worldchain/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the World Chain network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# worldchain.contracts
Source: https://docs.dune.com/data-catalog/evm/worldchain/decoded/contracts

Verified contract registry on World Chain — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs
Source: https://docs.dune.com/data-catalog/evm/worldchain/decoded/event-logs

Smart Contracts emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# worldchain.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/worldchain/decoded/logs-decoded

ABI-decoded event logs on World Chain — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# World Chain Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/worldchain/decoded/overview

Simplifying World Chain smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# worldchain.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/worldchain/decoded/traces-decoded

ABI-decoded function calls on World Chain — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# World Chain Overview
Source: https://docs.dune.com/data-catalog/evm/worldchain/overview

World Chain data on Dune

World Chain is a blockchain for humans, designed to empower developers with unique primitives and enable never-before-seen applications. By offering free gas fees to all verified humans, native mobile distribution through mini apps, and sybil resistance via World ID, World Chain is set to revolutionize the blockchain landscape for a global audience.

**Human-Centric Primitives:**
World Chain provides a set of powerful tools for developers:

* **Free Gas for Verified Humans:** Eliminating transaction fees for verified users.
* **Native Mobile Mini Apps:** Seamlessly distribute mini apps to all World App users, unlocking new opportunities for global reach and engagement.
* **Sybil Resistance:** Built-in World ID technology ensures that developers can trust the unique identity of their users, reducing fraud and increasing transparency.

**Scalable and Decentralized:**
World Chain is **built on the Superchain**, a horizontally scalable network of OP Chains that share security, governance, and a communication layer. By leveraging the OP Stack, World Chain benefits from decentralized scalability while maintaining ease of integration for developers.

**Mini Apps:**
World Chain supports mini apps, allowing third-party developers to create native-like applications within World App. This opens the door to global payments, sign-in with Ethereum, and other crypto transactions. Developers can access a rapidly growing user network and monetize via WLD and USDC through mini apps.

**Worldcoin and World ID:**

* **Worldcoin Token (WLD):** The first token to be freely distributed globally for both utility and governance, rewarding users just for being verified as unique individuals.
* **World ID:** A privacy-preserving digital identity that proves you are a real and unique person, forming the foundation for sybil-resistant applications and secure digital interactions.

<CardGroup>
  <Card title="World Chain documentation" icon="link" href="https://world-id-docs-git-world-chain-docs-main-worldcoin.vercel.app/world-chain">
    Explore comprehensive documentation of World Chain, detailing its architecture, protocol, and resources for developers.
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Detailed event logs from smart contracts, providing insights into interactions within the World Chain network.
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on blocks, illustrating the operational capacity and activity levels on World Chain.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Extensive transaction data, showcasing the efficiency and execution of operations on World Chain.
  </Card>

  <Card title="decoded" icon="file" href="./decoded/overview">
    Enhanced transaction data decoded for better analysis and understanding of contract executions.
  </Card>
</CardGroup>


# worldchain.blocks
Source: https://docs.dune.com/data-catalog/evm/worldchain/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for World Chain.

<BlockSnippet />


# worldchain.creation_traces
Source: https://docs.dune.com/data-catalog/evm/worldchain/raw/creation-traces

Contract deployment records on World Chain — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# worldchain.logs
Source: https://docs.dune.com/data-catalog/evm/worldchain/raw/logs

Smart contract event logs on World Chain — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# worldchain.traces
Source: https://docs.dune.com/data-catalog/evm/worldchain/raw/traces

Internal transaction traces on World Chain — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# worldchain.transactions
Source: https://docs.dune.com/data-catalog/evm/worldchain/raw/transactions

Every transaction on World Chain — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex.trades on xlayer
Source: https://docs.dune.com/data-catalog/evm/xlayer/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on xlayer.

<DexTradesSnippet />


# X Layer Call Tables
Source: https://docs.dune.com/data-catalog/evm/xlayer/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the X Layer network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# xlayer.contracts
Source: https://docs.dune.com/data-catalog/evm/xlayer/decoded/contracts

Verified contract registry on X Layer — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs
Source: https://docs.dune.com/data-catalog/evm/xlayer/decoded/event-logs

Smart Contracts emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# xlayer.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/xlayer/decoded/logs-decoded

ABI-decoded event logs on X Layer — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# X Layer Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/xlayer/decoded/overview

Simplifying X Layer smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# xlayer.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/xlayer/decoded/traces-decoded

ABI-decoded function calls on X Layer — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# X Layer Overview
Source: https://docs.dune.com/data-catalog/evm/xlayer/overview

X Layer data on Dune

## What is X Layer?

X Layer is an Ethereum Layer 2 (L2) network, built by OKX on an enhanced Optimism Stack, designed to provide developers with a superior environment for scaling applications. It uses an optimistic rollup architecture where transactions are considered valid by default, with a 7-day challenge period for fraud proofs.

## Key Features and Advantages

### Full EVM Equivalence

* Deploy existing Ethereum applications without any code modifications
* Complete compatibility with standard Ethereum development tools
* Seamless migration from Ethereum mainnet

### Exceptional Performance

* Support for up to 5,000 transactions per second (TPS)
* Negligible gas fees for cost-effective transactions
* 1-second block times for fast execution
* Immediate transaction finality on L2 for most operations

### Battle-Tested Security

* Leverages robust optimistic rollup architecture
* Inherits security guarantees of Ethereum
* Cryptographic fraud proofs when needed
* All L2 data published to L1, ensuring trustless and censorship-resistant operation

### Enterprise-Grade Reliability

* Conductor high-availability cluster ensures sequencer redundancy
* 99.9% uptime for production-ready dApps
* Continuous synchronization between L2 and L1

### Network Specifications

* **Technology Stack**: Enhanced OP Stack
* **Gas Token**: OKB
* **Network Type**: EVM-compatible Layer 2
* **Base Chain**: Ethereum
* **Consensus**: Optimistic Rollup with 7-day challenge period

### Architecture Components

* **Virtual Machine**: EVM-equivalent
* **Sequencer**: Trusted (op-node in sequencer mode with op-geth via Engine API)
* **Bridge Service**: Monitors and syncs L1/L2 contract events
* **AggLayer Integration**: ZK proof generation for cross-chain settlement

<CardGroup>
  <Card title="X Layer Documentation" icon="link" href="https://web3.okx.com/xlayer/docs/developer/build-on-xlayer/about-xlayer">
    Official documentation for developers building on X Layer
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Insights into smart contract interactions through event logs
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on blocks processed on X Layer
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Detailed data on transactions
  </Card>

  <Card title="Decoded" icon="file" href="./decoded/overview">
    Decoded transaction information for enhanced analysis
  </Card>
</CardGroup>


# xlayer.blocks
Source: https://docs.dune.com/data-catalog/evm/xlayer/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for X Layer.

<BlockSnippet />


# xlayer.creation_traces
Source: https://docs.dune.com/data-catalog/evm/xlayer/raw/creation-traces

Contract deployment records on X Layer — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# xlayer.logs
Source: https://docs.dune.com/data-catalog/evm/xlayer/raw/logs

Smart contract event logs on X Layer — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# xlayer.traces
Source: https://docs.dune.com/data-catalog/evm/xlayer/raw/traces

Internal transaction traces on X Layer — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# xlayer.transactions
Source: https://docs.dune.com/data-catalog/evm/xlayer/raw/transactions

Every transaction on X Layer — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex_aggregator.trades on zksync
Source: https://docs.dune.com/data-catalog/evm/zksync/curated-data/dex/dex-aggregator-trades

DEX aggregator swaps on zkSync — trades routed through aggregators like 1inch, Paraswap, and CoW Swap with pricing and routing details.

<DexAggregatorTradesSnippet />


# dex.trades on zksync
Source: https://docs.dune.com/data-catalog/evm/zksync/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on zksync.

<DexTradesSnippet />


# NFT.trades on zksync
Source: https://docs.dune.com/data-catalog/evm/zksync/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on zksync.

<NFTTradesSnippet />


# zkSync Call Tables
Source: https://docs.dune.com/data-catalog/evm/zksync/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the zkSync network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# zksync.contracts
Source: https://docs.dune.com/data-catalog/evm/zksync/decoded/contracts

Verified contract registry on zkSync — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs
Source: https://docs.dune.com/data-catalog/evm/zksync/decoded/event-logs

Smart Contracts emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# zksync.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/zksync/decoded/logs-decoded

ABI-decoded event logs on zkSync — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# zkSync Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/zksync/decoded/overview

Simplifying zkSync smart contract analysis through human-readable tables.

<Warning>
  Due to bugs in the zkSync client, some contract creation traces are missing, and data in the code field is incomplete for certain blocks. Consequently, we cannot support factory and bytecode matching for this chain. Once the bugs are addressed, we will work to restore this functionality. We apologize for the inconvenience.
</Warning>

<OverviewDecodedDataApproach />


# zksync.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/zksync/decoded/traces-decoded

ABI-decoded function calls on zkSync — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# zkSync Overview
Source: https://docs.dune.com/data-catalog/evm/zksync/overview

zkSync data on Dune

zkSync is a Layer 2 scaling solution for Ethereum that utilizes zk-Rollups technology to offer low-cost, high-speed transactions with strong security guarantees. By employing zero-knowledge proofs, zkSync ensures data availability and correctness without compromising the underlying security of the Ethereum mainnet.

**Enhanced Scalability and Efficiency:**
zkSync enhances Ethereum's scalability by aggregating multiple transactions into a single rollup block. This process significantly reduces transaction costs and increases processing speed, making it ideal for high-throughput applications.

**Robust Security and Ethereum Compatibility:**
zkSync maintains a high level of security through its use of zero-knowledge proofs, which verify the validity of transactions without revealing any underlying data. Furthermore, zkSync is fully compatible with Ethereum, allowing for seamless migration of existing dApps and smart contracts.

**Developer-Friendly Platform:**
zkSync provides a supportive environment for developers with comprehensive tooling and resources designed to facilitate the development and deployment of Ethereum-compatible applications on its Layer 2 platform.

<CardGroup>
  <Card title="zkSync documentation" icon="link" href="https://docs.zksync.io">
    Access the official documentation for zkSync, offering extensive information on its technology, platform capabilities, and development resources.
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Event logs from smart contracts, providing insights into interactions and activities on the zkSync network.
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Information on blocks processed using zkSync’s technology, reflecting the network's capacity for high transaction throughput.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Detailed transaction data, showcasing the operational efficiency and cost-effectiveness of zkSync’s rollup solution.
  </Card>

  <Card title="decoded" icon="file" href="./decoded/overview">
    Decoded transaction data for easier analysis and better understanding of smart contract executions on zkSync.
  </Card>
</CardGroup>


# zksync.blocks
Source: https://docs.dune.com/data-catalog/evm/zksync/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for zkSync.

<BlockSnippet />


# zksync.creation_traces
Source: https://docs.dune.com/data-catalog/evm/zksync/raw/creation-traces

Contract deployment records on zkSync — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# zksync.logs
Source: https://docs.dune.com/data-catalog/evm/zksync/raw/logs

Smart contract event logs on zkSync — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# zksync.traces
Source: https://docs.dune.com/data-catalog/evm/zksync/raw/traces

Internal transaction traces on zkSync — cross-contract calls, delegate calls, and value transfers with full call stack context.

<Warning>
  You may see duplicate records in the `traces` table for the zkSync chain. This is not a bug, but a result of trace calls appearing twice within the same transaction. These consecutive calls—an outer and an inner call—are identical except for their gas values. They share the same `from`, `to`, `input`, `output`, `success`, and `value` fields.
</Warning>

<TracesSnippet />


# zksync.transactions
Source: https://docs.dune.com/data-catalog/evm/zksync/raw/transactions

Every transaction on zkSync — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# dex_aggregator.trades on zora
Source: https://docs.dune.com/data-catalog/evm/zora/curated-data/dex/dex-aggregator-trades

DEX aggregator swaps on Zora — trades routed through aggregators like 1inch, Paraswap, and CoW Swap with pricing and routing details.

<DexAggregatorTradesSnippet />


# dex.trades on zora
Source: https://docs.dune.com/data-catalog/evm/zora/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on zora.

<DexTradesSnippet />


# NFT.trades on zora
Source: https://docs.dune.com/data-catalog/evm/zora/curated-data/nft/nft-trades

The `nft.trades` table captures detailed data on NFT marketplaces, recording all trade events across various protocols on zora.

<NFTTradesSnippet />


# Zora Call Tables
Source: https://docs.dune.com/data-catalog/evm/zora/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Zora network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# zora.contracts
Source: https://docs.dune.com/data-catalog/evm/zora/decoded/contracts

Verified contract registry on Zora — contract name, namespace, ABI, and deployment metadata.

<ContractsSnippet />


# Event Logs
Source: https://docs.dune.com/data-catalog/evm/zora/decoded/event-logs

Smart Contracts emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# zora.logs_decoded
Source: https://docs.dune.com/data-catalog/evm/zora/decoded/logs-decoded

ABI-decoded event logs on Zora — human-readable event names and parsed parameters from verified contracts.

<LogsDecodedSnippet />


# Zora Decoded Overview
Source: https://docs.dune.com/data-catalog/evm/zora/decoded/overview

Simplifying Zora smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# zora.traces_decoded
Source: https://docs.dune.com/data-catalog/evm/zora/decoded/traces-decoded

ABI-decoded function calls on Zora — parsed function names, inputs, and outputs from verified contracts.

<TracesDecodedSnippet />


# Zora Overview
Source: https://docs.dune.com/data-catalog/evm/zora/overview

Zora data on Dune

<Warning>
  Starting from the 8th of October 2025 Dune is not live ingesting and indexing Zora data. The historical data of the chain will remain available to be used.
</Warning>

Zora is a blockchain platform designed specifically to support digital creators and the broader creative economy. Leveraging the power of decentralized technology, Zora Chain facilitates the minting, buying, and trading of digital assets, including NFTs, with enhanced scalability and reduced transaction costs. Zora is based on the OP stack and uses Ether as its native currency.

**Creative Economy Focused:**
Zora Chain is built to cater to the needs of digital artists, musicians, and other creators, providing them with a blockchain infrastructure that supports direct and fair monetization of their work.

**Low-Cost Transactions:**
By optimizing transaction efficiency, Zora Chain minimizes the costs associated with minting and trading digital assets, making it more accessible for creators and collectors alike.

**Scalability and Performance:**
Designed for high throughput, Zora Chain ensures that the growing demand for NFTs and digital goods doesn't compromise performance, enabling a seamless user experience.

<CardGroup>
  <Card title="Zora documentation" icon="link" href="https://docs.zora.co">
    Explore comprehensive documentation for Zora Chain, including detailed guides on its architecture, features, and how creators can leverage the platform for their digital assets.
  </Card>
</CardGroup>

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="./raw/logs">
    Event logs from smart contracts, offering insights into interactions and activities within the Zora Chain network.
  </Card>

  <Card title="Blocks" icon="cubes" href="./raw/blocks">
    Data on blocks processed on Zora Chain, reflects the network's capacity for handling large volumes of transactions efficiently.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="./raw/transactions">
    Comprehensive transaction data, showcasing the operational efficiency and reduced costs achieved through Zora Chain’s optimized blockchain solutions.
  </Card>

  <Card title="decoded" icon="file" href="./decoded/overview">
    Decoded transaction data for easier analysis and a better understanding of smart contract executions on Zora.
  </Card>
</CardGroup>


# zora.blocks
Source: https://docs.dune.com/data-catalog/evm/zora/raw/blocks

Block headers, timestamps, gas limits, base fees, and validator/miner data for Zora.

<BlockSnippet />


# zora.creation_traces
Source: https://docs.dune.com/data-catalog/evm/zora/raw/creation-traces

Contract deployment records on Zora — deployer address, factory context, and deployed bytecode.

<CreationTracesSnippet />


# zora.logs
Source: https://docs.dune.com/data-catalog/evm/zora/raw/logs

Smart contract event logs on Zora — indexed topics and data fields from token transfers, swaps, and protocol actions.

<LogsSnippet />


# zora.traces
Source: https://docs.dune.com/data-catalog/evm/zora/raw/traces

Internal transaction traces on Zora — cross-contract calls, delegate calls, and value transfers with full call stack context.

<TracesSnippet />


# zora.transactions
Source: https://docs.dune.com/data-catalog/evm/zora/raw/transactions

Every transaction on Zora — from, to, value, gas, calldata, and receipt status.

<TransactionsSnippet />


# flow.cadence_blocks
Source: https://docs.dune.com/data-catalog/flow/cadence/blocks

Flow Cadence block data — block details specific to Flow's Cadence execution environment.

## Table Description

The `flow.cadence_blocks` table contains block-level data from the Flow Cadence blockchain including block headers, timestamps, and network fee information.

## Column Descriptions

| Column              | Type          | Description                                |
| ------------------- | ------------- | ------------------------------------------ |
| block\_date         | date          | The date of the block                      |
| timestamp           | timestamp     | Timestamp when the block was created       |
| block\_hash         | string        | Unique hash identifier for the block       |
| block\_height       | bigint        | The block number/height                    |
| parent\_block\_hash | string        | Hash of the parent block                   |
| slot                | bigint        | Slot number                                |
| difficulty          | decimal(38,9) | Block difficulty                           |
| total\_difficulty   | decimal(38,9) | Cumulative difficulty                      |
| network\_fee\_used  | decimal(38,9) | Network fee consumed in this block         |
| network\_fee\_limit | decimal(38,9) | Maximum network fee limit for the block    |
| chain\_specific     | string        | Chain-specific metadata in JSON format     |
| \_updated\_at       | timestamp     | Timestamp when the record was last updated |
| \_ingested\_at      | timestamp     | Timestamp when the record was ingested     |

## Table Sample

<TableSample />


# flow.cadence_contracts
Source: https://docs.dune.com/data-catalog/flow/cadence/contracts

Flow Cadence contract deployments — contract code and account bindings.

## Table Description

The `flow.cadence_contracts` table contains Cadence smart contract deployment data on the Flow blockchain including contract code and metadata.

## Column Descriptions

| Column            | Type      | Description                                   |
| ----------------- | --------- | --------------------------------------------- |
| block\_date       | date      | The date of the contract deployment           |
| timestamp         | timestamp | Timestamp when the contract was deployed      |
| transaction\_hash | string    | Hash of the deployment transaction            |
| contract\_address | string    | Address where the contract is deployed        |
| valid\_from       | long      | Block height from which the contract is valid |
| code              | binary    | The contract bytecode                         |
| name              | string    | Name of the contract                          |
| chain\_specific   | string    | Chain-specific metadata in JSON format        |
| \_updated\_at     | timestamp | Timestamp when the record was last updated    |
| \_ingested\_at    | timestamp | Timestamp when the record was ingested        |

## Table Sample

<TableSample />


# flow.cadence_events
Source: https://docs.dune.com/data-catalog/flow/cadence/events

Flow Cadence events — structured events emitted by Cadence smart contracts.

## Table Description

The `flow.cadence_events` table contains event logs emitted by Cadence smart contracts on the Flow blockchain.

## Column Descriptions

| Column            | Type           | Description                                     |
| ----------------- | -------------- | ----------------------------------------------- |
| block\_date       | date           | The date of the event                           |
| timestamp         | timestamp      | Timestamp when the event was emitted            |
| block\_height     | bigint         | The block number containing this event          |
| block\_hash       | string         | Hash of the block containing this event         |
| transaction\_hash | string         | Hash of the transaction that emitted this event |
| log\_index        | bigint         | Index of the event within the transaction       |
| topics            | array\<string> | Array of indexed event topics                   |
| data              | string         | Event data payload                              |
| chain\_specific   | string         | Chain-specific metadata in JSON format          |
| \_updated\_at     | timestamp      | Timestamp when the record was last updated      |
| \_ingested\_at    | timestamp      | Timestamp when the record was ingested          |

## Table Sample

<TableSample />


# flow.cadence_native_token_balances
Source: https://docs.dune.com/data-catalog/flow/cadence/native-token-balances

Flow native FLOW token balances — account holdings over time.

## Table Description

The `flow.cadence_native_token_balances` table contains FLOW native token balance snapshots for addresses on the Flow Cadence blockchain.

## Column Descriptions

| Column            | Type          | Description                                        |
| ----------------- | ------------- | -------------------------------------------------- |
| block\_date       | date          | The date of the balance snapshot                   |
| timestamp         | timestamp     | Timestamp of the balance snapshot                  |
| address           | string        | Address holding the FLOW tokens                    |
| amount            | decimal(38,9) | Balance amount in FLOW                             |
| transaction\_hash | string        | Hash of the transaction that affected this balance |
| block\_height     | bigint        | Block height at the time of the snapshot           |
| block\_hash       | string        | Hash of the block at the time of the snapshot      |
| chain\_specific   | string        | Chain-specific metadata in JSON format             |
| \_updated\_at     | timestamp     | Timestamp when the record was last updated         |
| \_ingested\_at    | timestamp     | Timestamp when the record was ingested             |

## Table Sample

<TableSample />


# flow.cadence_participations
Source: https://docs.dune.com/data-catalog/flow/cadence/participations

Flow network participations — staking, delegation, and epoch participation records.

## Table Description

The `flow.cadence_participations` table contains staking and validator participation data on the Flow Cadence blockchain. This table tracks delegator participations in the Flow staking system.

## Column Descriptions

| Column            | Type      | Description                                             |
| ----------------- | --------- | ------------------------------------------------------- |
| block\_date       | date      | The date of the participation record                    |
| timestamp         | timestamp | Timestamp of the participation event                    |
| delegator\_id     | string    | Unique identifier for the delegator                     |
| node\_id          | string    | Identifier of the validator node                        |
| amount            | decimal   | Amount of FLOW tokens staked                            |
| action            | string    | Type of participation action (stake, unstake, withdraw) |
| transaction\_hash | string    | Hash of the transaction                                 |
| chain\_specific   | string    | Chain-specific metadata in JSON format                  |
| \_updated\_at     | timestamp | Timestamp when the record was last updated              |
| \_ingested\_at    | timestamp | Timestamp when the record was ingested                  |

## Table Sample

<TableSample />


# flow.cadence_token_collections
Source: https://docs.dune.com/data-catalog/flow/cadence/token-collections

Flow Cadence NFT collections — collection metadata and token types.

## Table Description

The `flow.cadence_token_collections` table contains token collection metadata for NFT and fungible token contracts on the Flow Cadence blockchain.

## Column Descriptions

| Column            | Type          | Description                                                 |
| ----------------- | ------------- | ----------------------------------------------------------- |
| block\_date       | date          | The date of the collection record                           |
| timestamp         | timestamp     | Timestamp when the collection was created/updated           |
| transaction\_hash | string        | Hash of the transaction that created/updated the collection |
| contract\_address | string        | Address of the token contract                               |
| token\_id         | string        | Identifier for the token collection                         |
| symbol            | string        | Symbol of the token collection                              |
| name              | string        | Name of the token collection                                |
| description       | string        | Description of the collection                               |
| url               | string        | URL to the collection metadata                              |
| decimals          | decimal(38,9) | Number of decimals for fungible tokens                      |
| total\_supply     | decimal(38,9) | Total supply of tokens in the collection                    |
| category          | string        | Category of the token (NFT, FT, etc.)                       |
| chain\_specific   | string        | Chain-specific metadata in JSON format                      |
| \_updated\_at     | timestamp     | Timestamp when the record was last updated                  |
| \_ingested\_at    | timestamp     | Timestamp when the record was ingested                      |

## Table Sample

<TableSample />


# flow.cadence_token_transfers
Source: https://docs.dune.com/data-catalog/flow/cadence/token-transfers

Flow Cadence token transfers — fungible and NFT movement events.

## Table Description

The `flow.cadence_token_transfers` table contains token transfer events on the Flow Cadence blockchain including NFT and fungible token transfers.

## Column Descriptions

| Column            | Type          | Description                                      |
| ----------------- | ------------- | ------------------------------------------------ |
| block\_date       | date          | The date of the transfer                         |
| timestamp         | timestamp     | Timestamp when the transfer occurred             |
| block\_height     | bigint        | The block number containing this transfer        |
| block\_hash       | string        | Hash of the block containing this transfer       |
| transaction\_hash | string        | Hash of the transaction containing this transfer |
| contract\_address | string        | Address of the token contract                    |
| token\_id         | string        | Identifier of the token being transferred        |
| from              | string        | Address of the sender                            |
| to                | string        | Address of the recipient                         |
| amount            | decimal(38,9) | Amount of tokens transferred                     |
| chain\_specific   | string        | Chain-specific metadata in JSON format           |
| \_updated\_at     | timestamp     | Timestamp when the record was last updated       |
| \_ingested\_at    | timestamp     | Timestamp when the record was ingested           |

## Table Sample

<TableSample />


# flow.cadence_tokens
Source: https://docs.dune.com/data-catalog/flow/cadence/tokens

Flow Cadence token metadata — fungible and non-fungible token type definitions.

## Table Description

The `flow.cadence_tokens` table contains token metadata for NFTs and fungible tokens on the Flow Cadence blockchain.

## Column Descriptions

| Column            | Type      | Description                                  |
| ----------------- | --------- | -------------------------------------------- |
| block\_date       | date      | The date of the token record                 |
| timestamp         | timestamp | Timestamp when the token was created/updated |
| token\_id         | string    | Unique identifier for the token              |
| contract\_address | string    | Address of the token contract                |
| name              | string    | Name of the token                            |
| description       | string    | Description of the token                     |
| content\_url      | string    | URL to the token content/media               |
| chain\_specific   | string    | Chain-specific metadata in JSON format       |
| \_updated\_at     | timestamp | Timestamp when the record was last updated   |
| \_ingested\_at    | timestamp | Timestamp when the record was ingested       |

## Table Sample

<TableSample />


# flow.cadence_transaction_receipts
Source: https://docs.dune.com/data-catalog/flow/cadence/transaction-receipts

Flow Cadence transaction receipts — execution results, events, and status.

## Table Description

The `flow.cadence_transaction_receipts` table contains transaction receipt data from the Flow Cadence blockchain including execution status and fee information.

## Column Descriptions

| Column                  | Type          | Description                                   |
| ----------------------- | ------------- | --------------------------------------------- |
| block\_date             | date          | The date of the transaction                   |
| timestamp               | timestamp     | Timestamp when the transaction was executed   |
| block\_height           | bigint        | The block number containing this transaction  |
| block\_hash             | string        | Hash of the block containing this transaction |
| transaction\_hash       | string        | Unique hash identifier for the transaction    |
| success                 | boolean       | Whether the transaction executed successfully |
| status\_message         | string        | Status message or error description           |
| network\_fee\_used      | decimal(38,9) | Actual network fee consumed                   |
| cost\_per\_network\_fee | decimal(38,9) | Cost per unit of network fee                  |
| chain\_specific         | string        | Chain-specific metadata in JSON format        |
| \_updated\_at           | timestamp     | Timestamp when the record was last updated    |
| \_ingested\_at          | timestamp     | Timestamp when the record was ingested        |

## Table Sample

<TableSample />


# flow.cadence_transactions
Source: https://docs.dune.com/data-catalog/flow/cadence/transactions

Flow Cadence transactions — script and transaction interactions with the Cadence runtime.

## Table Description

The `flow.cadence_transactions` table contains transaction data from the Flow Cadence blockchain including sender, receiver, and transaction payload information.

## Column Descriptions

| Column                         | Type          | Description                                   |
| ------------------------------ | ------------- | --------------------------------------------- |
| block\_date                    | date          | The date of the transaction                   |
| timestamp                      | timestamp     | Timestamp when the transaction was executed   |
| block\_height                  | bigint        | The block number containing this transaction  |
| block\_hash                    | string        | Hash of the block containing this transaction |
| transaction\_hash              | string        | Unique hash identifier for the transaction    |
| transaction\_index             | bigint        | Index of the transaction within the block     |
| from                           | string        | Address of the transaction sender             |
| to                             | string        | Address of the transaction recipient          |
| sequence\_number               | bigint        | Sequence number of the transaction            |
| data                           | string        | Transaction payload data                      |
| network\_fee\_limit            | decimal(38,9) | Maximum network fee for this transaction      |
| max\_network\_fee\_unit\_price | decimal(38,9) | Maximum price per unit of network fee         |
| chain\_specific                | string        | Chain-specific metadata in JSON format        |
| \_updated\_at                  | timestamp     | Timestamp when the record was last updated    |
| \_ingested\_at                 | timestamp     | Timestamp when the record was ingested        |

## Table Sample

<TableSample />


# dex.trades on flow
Source: https://docs.dune.com/data-catalog/flow/curated-data/dex/dex-trades

The `dex.trades` table captures detailed data on decentralized exchange (DEX) trades, recording all raw trade events across various protocols on flow.

<DexTradesSnippet />


# Flow EVM Call Tables
Source: https://docs.dune.com/data-catalog/flow/decoded/call-tables

On Dune, we parse all message calls and transactions made to smart contracts on the Flow EVM network in their own tables.

## Overview

On Dune, we parse all message calls and transactions made to smart contracts in their own tables. This allows us to isolate the logic of a specific smart contract and analyze how it interacts with other smart contracts.

The data is stored in the format:

`[projectname_blockchain].[contractName]_call_[functionName]`

This allows us to analyze how a specific function is used in a smart contract, and how often it is called, as well as how it interacts with other smart contracts.

Call tables always originate from the `traces` table, which contains all the transactions and message calls on the Ethereum network. We parse the `data` field of the `traces` table to decode the function call and parameters.

## Decoding

When a transaction is sent to a smart contract on the Ethereum network, it contains a `data` field. This `data` field is the encoded function call and parameters. Dune decodes this data and stores it in the corresponding table.

For example, when a transaction is sent to the [Uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) contract on the Ethereum network, Dune will decode the `data` field and store it in the table:

`uniswap_v3_ethereum.Factory_call_createPool`

<DuneEmbed />

## Multiple Instances

For a contract where multiple instances exist, we will decode all calls to all instances of this smart contract into one table. If there are transactions calling the `swap` function of any instance of the [Uniswap v3 pair](https://etherscan.io/address/0x8f8ef111b67c04eb1641f5ff19ee54cda062f163#writeContract) contract, we will decode this data into the table `uniswap_v3_ethereum.Pair_call_swap`. The `pair` contract is a template contract and there are many instances of it, each with its own address. The column `contract_address` will indicate the address of the instance of the pair contract that was called.

<DuneEmbed />

## Common misconceptions

One thing to keep in mind here is that [web3.js](https://web3js.readthedocs.io), [web3.py](https://web3py.readthedocs.io/en/stable) and all other methods of (locally) calling a `pure`, `read`, or `constant` function do not broadcast or publish anything on the blockchain and are therefore not recorded in Dune.

However, if one of these functions is invoked by another smart contract in the context of a transaction, this will be broadcast on the chain and therefore accessible in Dune.

In short: **State data stored in the memory of a smart contract is not available on Dune!**

A good example of this is the function `decimals` of the [erc20 token contract](https://etherscan.io/token/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984#readContract) `Uni` which is a `constant` state variable that is able to be accessed through an automatically created "[getter function](https://docs.soliditylang.org/en/v0.7.4/contracts.html#getter-functions)". Should a smart contract invoke this function in the context of transaction, this message call will be recorded in the Dune table [`uniswap."UNI_call_decimals"`](https://dune.com/queries/741354).

This is in contrast to anyone calling this function locally using web3.py/web3.js or using the Etherscan frontend to access this state. These local calls are not recorded in Dune.

## Further Reading

<CardGroup>
  <Card title="What is the difference between a transaction and a call?" icon="phone" href="https://ethereum.stackexchange.com/questions/765/what-is-the-difference-between-a-transaction-and-a-call" />

  <Card title="Soliditylang.org documentation" icon="book" href="https://docs.soliditylang.org/en/v0.8.13/contracts.html#function-visibility" />

  <Card title="How Calldata is Encoded" icon="database" href="https://degatchi.com/articles/reading-raw-evm-calldata" />
</CardGroup>


# flow.contracts
Source: https://docs.dune.com/data-catalog/flow/decoded/contracts

Verified contract registry on Flow — contract name, code, and deployment metadata.

<ContractsSnippet />


# flow.event_logs
Source: https://docs.dune.com/data-catalog/flow/decoded/event-logs

Smart contract event logs on Flow — indexed topics and data fields emitted during transaction execution.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the ERC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

## Example

Let's take the [uniswap v3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984#code) as an example and look at the event that gets emitted upon the creation of a new pool. The event is called `PoolCreated` and gets emitted every time somebody successfully deploys a new Uniswap V3 pool by calling the function `createPool`. The event will readily give us information like the tokens in the pool, the fee tier of this pool and the tick spacing. In Etherscan, you can easily look at the event logs of transaction by opening the [logs tab](https://etherscan.io/tx/0xdeb368592f3de0f2840754bce61d2c3f29cdb3407c63c699052e68a854c71eaa#eventlog). In Dune, this particular event will be stored in the table:

`uniswap_v3_ethereum.Factory_evt_PoolCreated`

<DuneEmbed />

## Multiple Instances

If there is multiple instances of a contract we will collect all event logs across all instances of this smart contract in one table. For example, all uniswap v3 pool `swap` events (on ethereum) are stored in the table: `uniswap_v3_ethereum.Pair_evt_Swap`

The column `contract_address` indicates as to which smart contract emitted this event.

<DuneEmbed />

## Further Reading

* [Understanding event logs on the Ethereum blockchain](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378)
* [Everything You Ever Wanted to Know About Events and Logs on Ethereum](https://medium.com/linum-labs/everything-you-ever-wanted-to-know-about-events-and-logs-on-ethereum-fec84ea7d0a5)

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/evm/ethereum/decoded/contracts" />
</CardGroup>


# flow.logs_decoded
Source: https://docs.dune.com/data-catalog/flow/decoded/logs-decoded

ABI-decoded Flow event logs — parsed event names and parameters.

<LogsDecodedSnippet />


# Flow EVM Decoded Overview
Source: https://docs.dune.com/data-catalog/flow/decoded/overview

Simplifying Flow EVM smart contract analysis through human-readable tables.

<OverviewDecodedDataApproach />


# flow.traces_decoded
Source: https://docs.dune.com/data-catalog/flow/decoded/traces-decoded

ABI-decoded Flow function calls — parsed function names and arguments.

<TracesDecodedSnippet />


# Flow Overview
Source: https://docs.dune.com/data-catalog/flow/overview

Flow blockchain data on Dune - EVM and Cadence

## What is Flow?

Flow is a fast, decentralized, and developer-friendly blockchain designed for the next generation of apps, games, and digital assets. Flow features a unique multi-node architecture that enables high throughput while maintaining decentralization and security.

**On Dune, Flow data is available for both execution environments:**

* **Flow EVM** - Ethereum-compatible environment for Solidity developers
* **Flow Cadence** - Flow's native smart contract environment with resource-oriented programming

## Flow EVM vs Cadence: Key Differences

| Aspect                      | Flow EVM                                    | Flow Cadence               |
| --------------------------- | ------------------------------------------- | -------------------------- |
| **Smart Contract Language** | Solidity                                    | Cadence                    |
| **Compatibility**           | Full EVM equivalence                        | Native Flow                |
| **Developer Tooling**       | Ethereum toolchain (Hardhat, Foundry, etc.) | Flow CLI, Cadence tools    |
| **Account Model**           | EOA + Contract accounts                     | Resource-oriented accounts |
| **Gas Token**               | FLOW                                        | FLOW                       |
| **Interoperability**        | Cross-VM bridge to Cadence                  | Cross-VM bridge to EVM     |

Both environments share the same underlying Flow blockchain and use FLOW as the native gas token, enabling seamless cross-VM interactions.

## Flow EVM

Flow EVM is a fast EVM equivalent blockchain with low fees, making it an ideal **Ethereum alternative for apps** that need both performance and affordability. With EVM equivalency, Solidity developers can deploy existing contracts on Flow without rewriting code.

### EVM Key Features

* **EVM Equivalence**: Full compatibility with Ethereum smart contracts and tooling
* **Ultra-Fast Performance**: Transaction throughput peaked to 2M daily transactions
* **Low Gas Fees**: Ultra-low cost gas fees with support for gasless experiences
* **MEV Resilience**: Robust design offering improved market efficiency and fairness
* **Cross-VM Integration**: Seamless token transfers between EVM and Cadence

### EVM Data on Dune

<CardGroup>
  <Card title="Raw Data" icon="database" href="/data-catalog/flow/raw/blocks">
    Access to raw EVM blockchain data including blocks, transactions, logs, and traces
  </Card>

  <Card title="Decoded Data" icon="code" href="/data-catalog/flow/decoded/overview">
    Human-readable EVM contract interactions and events
  </Card>
</CardGroup>

## Flow Cadence

Flow Cadence is Flow's native smart contract environment using the resource-oriented Cadence programming language. It offers unique capabilities for digital ownership, NFTs, and complex on-chain logic.

### Cadence Key Features

* **Resource-Oriented Programming**: First-class digital ownership at the language level
* **Account Linking**: Advanced account abstraction enabling smooth user onboarding
* **Native NFT Support**: Purpose-built for digital collectibles and assets
* **Upgradeable Contracts**: Safe contract upgrade patterns
* **Multi-Role Node Architecture**: Heterogeneous node roles ensuring security

### Cadence Data on Dune

<CardGroup>
  <Card title="Blocks" icon="cube" href="/data-catalog/flow/cadence/blocks">
    Cadence block data including headers and network fees
  </Card>

  <Card title="Transactions" icon="arrow-right-arrow-left" href="/data-catalog/flow/cadence/transactions">
    Cadence transaction data with sender and payload info
  </Card>

  <Card title="Transaction Receipts" icon="receipt" href="/data-catalog/flow/cadence/transaction-receipts">
    Execution status and fee information
  </Card>

  <Card title="Events" icon="bolt" href="/data-catalog/flow/cadence/events">
    Events emitted by Cadence smart contracts
  </Card>

  <Card title="Contracts" icon="file-code" href="/data-catalog/flow/cadence/contracts">
    Cadence contract deployments and code
  </Card>

  <Card title="Token Transfers" icon="coins" href="/data-catalog/flow/cadence/token-transfers">
    NFT and fungible token transfers
  </Card>

  <Card title="Token Collections" icon="layer-group" href="/data-catalog/flow/cadence/token-collections">
    Token collection metadata
  </Card>

  <Card title="Tokens" icon="tag" href="/data-catalog/flow/cadence/tokens">
    Individual token metadata
  </Card>

  <Card title="Native Balances" icon="wallet" href="/data-catalog/flow/cadence/native-token-balances">
    FLOW token balance snapshots
  </Card>
</CardGroup>

## Resources

<CardGroup>
  <Card title="Flow Documentation" icon="link" href="https://developers.flow.com">
    Official Flow developer documentation
  </Card>

  <Card title="Flow EVM Documentation" icon="link" href="https://developers.flow.com/build/evm/about">
    Documentation for building on Flow EVM
  </Card>

  <Card title="Cadence Documentation" icon="link" href="https://cadence-lang.org">
    Cadence programming language documentation
  </Card>
</CardGroup>


# flow.blocks
Source: https://docs.dune.com/data-catalog/flow/raw/blocks

Flow block data — block height, timestamp, and collection guarantees.

<BlockSnippet />


# flow.creation_traces
Source: https://docs.dune.com/data-catalog/flow/raw/creation-traces

Flow contract deployment records — deployer and deployed contract details.

<CreationTracesSnippet />


# flow.logs
Source: https://docs.dune.com/data-catalog/flow/raw/logs

Flow event logs — events emitted during Cadence smart contract execution.

<LogsSnippet />


# flow.traces
Source: https://docs.dune.com/data-catalog/flow/raw/traces

Flow execution traces — internal call data during transaction processing.

<TracesSnippet />


# flow.transactions
Source: https://docs.dune.com/data-catalog/flow/raw/transactions

Flow transaction records — authorizers, payer, gas limit, and execution status.

<TransactionsSnippet />


# Blocks
Source: https://docs.dune.com/data-catalog/fuel/blocks

Fuel blockchain blocks data

# Table Description

This table contains data about blocks in the Fuel blockchain, including block headers, consensus data, and transaction information.

## Column Descriptions

| Column Name                              | Data Type | Description                  |
| ---------------------------------------- | --------- | ---------------------------- |
| **block\_time**                          | bigint    | Block creation timestamp     |
| **block\_date**                          | date      | Block creation date          |
| **height**                               | bigint    | Block height/number          |
| **time**                                 | bigint    | Unix timestamp               |
| **transactions\_count**                  | bigint    | Number of transactions       |
| **transactions\_root**                   | binary    | Merkle root of transactions  |
| **application\_hash**                    | binary    | Application state hash       |
| **consensus\_parameters\_version**       | bigint    | Consensus parameters version |
| **da\_height**                           | bigint    | Data availability height     |
| **event\_inbox\_root**                   | binary    | Event inbox Merkle root      |
| **id**                                   | binary    | Block identifier             |
| **message\_outbox\_root**                | binary    | Message outbox Merkle root   |
| **message\_receipt\_count**              | bigint    | Number of message receipts   |
| **prev\_root**                           | binary    | Previous block root          |
| **state\_transition\_bytecode\_version** | bigint    | State transition version     |
| **version**                              | string    | Block version                |
| **consensus\_type**                      | string    | Consensus mechanism type     |
| **poa\_consensus\_data\_signature**      | binary    | PoA consensus signature      |
| **producer**                             | binary    | Block producer address       |
| **\_updated\_at**                        | timestamp | Last update timestamp        |
| **\_ingested\_at**                       | timestamp | Ingestion timestamp          |

## Table Sample

<TableSample />


# Fuel Data
Source: https://docs.dune.com/data-catalog/fuel/overview

Fuel blockchain data on Dune

## What is Fuel?

Fuel is an operating system purpose built for Ethereum Rollups. It implements improvements suggested to the Ethereum VM (EVM) for many years that couldn't be implemented due to the need to maintain backward compatibility, including parallel transaction execution and multiple native assets.

Fuel delivers unmatched processing capacity through its ability to execute transactions in parallel by using strict state access lists in the form of a UTXO model. With the FuelVM, Fuel full nodes identify the accounts a transaction touches, mapping out dependencies before execution.

## Key Features

* **Parallel Transaction Execution**: Fuel can execute transactions in parallel, significantly increasing throughput
* **UTXO Model**: Uses a strict state access list model for efficient transaction processing
* **Multiple Native Assets**: Supports multiple native assets natively
* **FuelVM**: A purpose-built virtual machine that improves upon the EVM
* **Sway Language**: A domain-specific language based on Rust for smart contract development

## Fuel Data on Dune

Fuel blockchain data is organized into several key tables that capture different aspects of on-chain activity:

<CardGroup>
  <Card title="Blocks" icon="cube" href="/data-catalog/fuel/blocks">
    Core block data including block headers, validators, and block statistics.
  </Card>

  <Card title="Transactions" icon="arrow-right-arrow-left" href="/data-catalog/fuel/transactions">
    Detailed transaction data including computation, actions, and state changes.
  </Card>

  <Card title="Receipts" icon="receipt" href="/data-catalog/fuel/receipts">
    Transaction receipts containing execution results and event logs.
  </Card>
</CardGroup>


# Receipts
Source: https://docs.dune.com/data-catalog/fuel/receipts

Fuel blockchain receipts data

# Table Description

This table contains data about transaction receipts in the Fuel blockchain, including execution results, gas usage, and associated metadata.

## Column Description

| Column Name             | Data Type | Description                |
| ----------------------- | --------- | -------------------------- |
| **block\_time**         | bigint    | Block creation timestamp   |
| **block\_height**       | bigint    | Block height/number        |
| **block\_version**      | string    | Block version              |
| **block\_producer**     | binary    | Block producer address     |
| **transaction\_id**     | binary    | Transaction identifier     |
| **amount**              | bigint    | Token amount               |
| **asset\_id**           | binary    | Asset identifier           |
| **contract\_id**        | binary    | Contract identifier        |
| **data**                | string    | Receipt data               |
| **digest**              | binary    | Receipt hash               |
| **gas**                 | bigint    | Gas limit                  |
| **gas\_used**           | bigint    | Gas consumed               |
| **id**                  | string    | Receipt identifier         |
| **is**                  | bigint    | State indicator            |
| **len**                 | bigint    | Data length                |
| **nonce**               | binary    | Transaction nonce          |
| **param1**              | bigint    | Parameter 1                |
| **param2**              | bigint    | Parameter 2                |
| **ptr**                 | bigint    | Pointer value              |
| **ra**                  | bigint    | Register A                 |
| **rb**                  | bigint    | Register B                 |
| **rc**                  | bigint    | Register C                 |
| **rd**                  | bigint    | Register D                 |
| **reason\_reason**      | int       | Failure reason code        |
| **reason\_instruction** | bigint    | Failed instruction         |
| **receipt\_type**       | string    | Receipt type               |
| **recipient**           | binary    | Recipient address          |
| **result**              | bigint    | Execution result           |
| **sender**              | binary    | Sender address             |
| **sub\_id**             | binary    | Sub-identifier             |
| **to**                  | binary    | Destination address        |
| **to\_address**         | string    | Destination address string |
| **val**                 | bigint    | Value amount               |
| **\_updated\_at**       | timestamp | Last update timestamp      |
| **\_ingested\_at**      | timestamp | Ingestion timestamp        |

## Table Sample

<TableSample />


# Transactions
Source: https://docs.dune.com/data-catalog/fuel/transactions

Fuel blockchain transactions data

# Table Description

This table contains data about transactions in the Fuel blockchain, including transaction details, inputs, outputs, and associated metadata. Fuel transactions can be of different types: Script, Create, Mint, or Upgrade transactions.

## Column Description

| Column Name                    | Data Type     | Description                                          |
| ------------------------------ | ------------- | ---------------------------------------------------- |
| **block\_height**              | bigint        | The height of the block containing this transaction  |
| **block\_time**                | bigint        | The timestamp when the block was created             |
| **block\_id**                  | binary        | The unique identifier of the block                   |
| **block\_version**             | string        | The version of the block                             |
| **block\_producer**            | binary        | The address of the block producer                    |
| **status**                     | string        | The status of the transaction (Success/Failure)      |
| **id**                         | binary        | The unique identifier of the transaction             |
| **type**                       | string        | The type of transaction (Script/Create/Mint/Upgrade) |
| **tx\_pointer\_block\_height** | bigint        | Block height for UTXO validation                     |
| **tx\_pointer\_tx\_index**     | int           | Transaction index for UTXO validation                |
| **tx\_pointer**                | struct        | Reference to previous transaction in UTXO model      |
| **bytecode\_root**             | binary        | Root hash of script bytecode                         |
| **bytecode\_witness\_index**   | bigint        | Index in witnesses array                             |
| **blob\_id**                   | binary        | Identifier for blob transactions                     |
| **maturity**                   | bigint        | Minimum block height for execution                   |
| **mint\_amount**               | bigint        | Amount of tokens to mint                             |
| **mint\_asset\_id**            | binary        | Asset identifier for minting                         |
| **mint\_gas\_price**           | bigint        | Gas price for minting                                |
| **receipts\_root**             | binary        | Merkle root of transaction receipts                  |
| **salt**                       | binary        | Unique value for transaction                         |
| **script\_gas\_limit**         | bigint        | Maximum gas for script execution                     |
| **subsection\_index**          | bigint        | Index in multi-section transaction                   |
| **subsections\_number**        | bigint        | Total sections in transaction                        |
| **input\_asset\_ids**          | array(binary) | Asset IDs used as inputs                             |
| **proof\_set**                 | array(binary) | Zero-knowledge proofs for validation                 |
| **input\_contract**            | struct        | Input contract data (balances, state, UTXO)          |
| **output\_contract**           | struct        | Output contract data (new balances, state)           |
| **policies**                   | struct        | Transaction policies (maturity, fees, limits)        |
| **raw\_payload**               | binary        | Raw transaction data                                 |
| **script**                     | binary        | Compiled script bytecode                             |
| **script\_data**               | binary        | Script input data                                    |
| **storage\_slots**             | array(struct) | Contract storage updates                             |
| **upgrade\_purpose**           | struct        | Contract upgrade details                             |
| **witnesses**                  | array(binary) | Transaction validation data                          |
| **script\_length**             | bigint        | Script bytecode length                               |
| **script\_data\_length**       | bigint        | Script input data length                             |
| **storage\_slots\_count**      | bigint        | Number of storage updates                            |
| **proof\_set\_count**          | bigint        | Number of validation proofs                          |
| **witnesses\_count**           | bigint        | Number of witnesses                                  |
| **inputs\_count**              | bigint        | Number of inputs                                     |
| **outputs\_count**             | bigint        | Number of outputs                                    |
| **is\_create**                 | boolean       | Contract creation flag                               |
| **is\_mint**                   | boolean       | Minting transaction flag                             |
| **is\_script**                 | boolean       | Script transaction flag                              |
| **is\_upgrade**                | boolean       | Contract upgrade flag                                |
| **is\_upload**                 | boolean       | Bytecode upload flag                                 |
| **is\_blob**                   | boolean       | Blob transaction flag                                |
| **\_updated\_at**              | timestamp     | Last update timestamp                                |
| **\_ingested\_at**             | timestamp     | Ingestion timestamp                                  |

## Table Sample

<TableSample />


# Balances
Source: https://docs.dune.com/data-catalog/initia/balances

Initia blockchain account balances data

# Table Description

This table contains data about account balances in the Initia blockchain, including token holdings and balance snapshots.

## Column Descriptions

| Column name          | Data Type                   | Description                                             |
| -------------------- | --------------------------- | ------------------------------------------------------- |
| **block\_date**      | date                        | The date of the block.                                  |
| **block\_height**    | bigint                      | The height of the block where the balance was recorded. |
| **block\_timestamp** | timestamp(3) with time zone | Timestamp when the block was validated.                 |
| **address**          | varchar                     | The account address.                                    |
| **denom**            | varchar                     | The denomination of the token.                          |
| **amount**           | decimal(38, 0)              | The balance amount.                                     |
| **updated\_at**      | timestamp(3) with time zone | Timestamp of when the record was last updated.          |
| **ingested\_at**     | timestamp(3) with time zone | Timestamp of when the record was ingested into Dune.    |

## Table Sample

<TableSample />


# Block Events
Source: https://docs.dune.com/data-catalog/initia/block_events

Initia blockchain block events data

# Table Description

This table contains data about block-level events and attributes in the Initia blockchain, including event types, sources, and associated metadata. The schema is modeled after Cosmos block events.

## Column Descriptions

| Column name          | Data Type                   | Description                                          |
| -------------------- | --------------------------- | ---------------------------------------------------- |
| **block\_date**      | date                        | The date of the block.                               |
| **block\_height**    | bigint                      | The height of the block where the event occurred.    |
| **block\_timestamp** | timestamp(3) with time zone | Timestamp when the block was validated.              |
| **chain\_id**        | varchar                     | The ID of the chain where the block belongs.         |
| **event\_index**     | bigint                      | A unique index for events within the block.          |
| **event\_type**      | varchar                     | The type of event that was triggered.                |
| **event\_source**    | varchar                     | The source of the event.                             |
| **attribute\_key**   | varchar                     | The key of the event attribute.                      |
| **attribute\_value** | varchar                     | The value of the event attribute.                    |
| **attribute\_index** | bigint                      | A unique index for attributes within the event.      |
| **updated\_at**      | timestamp(3) with time zone | Timestamp of when the record was last updated.       |
| **ingested\_at**     | timestamp(3) with time zone | Timestamp of when the record was ingested into Dune. |

## Table Sample

<TableSample />


# Blocks
Source: https://docs.dune.com/data-catalog/initia/blocks

Initia blockchain blocks data

# Table Description

This table contains data about blocks in the Initia blockchain, including block headers, consensus data, and transaction information.

## Column Descriptions

| Column name           | Data Type                   | Description                                                  |
| --------------------- | --------------------------- | ------------------------------------------------------------ |
| **block\_date**       | date                        | The date of the block.                                       |
| **block\_height**     | bigint                      | The height of the block, a unique identifier for each block. |
| **block\_timestamp**  | timestamp(3) with time zone | Timestamp when the block was validated.                      |
| **chain\_id**         | varchar                     | The ID of the chain where the block belongs.                 |
| **proposer\_address** | varchar                     | The address of the validator proposing the block.            |
| **validators\_hash**  | varchar                     | The hash of the validators set for the block.                |
| **updated\_at**       | timestamp(3) with time zone | Timestamp of when the record was last updated.               |
| **ingested\_at**      | timestamp(3) with time zone | Timestamp of when the record was ingested into Dune.         |

## Table Sample

<TableSample />


# Bridge Transfers
Source: https://docs.dune.com/data-catalog/initia/bridge_transfers

Initia blockchain cross-chain bridge transfer data

# Table Description

This table contains data about cross-chain bridge transfers in the Initia blockchain, including transfer details, source and destination chains, and transfer status.

## Column Descriptions

| Column name            | Data Type                   | Description                                          |
| ---------------------- | --------------------------- | ---------------------------------------------------- |
| **block\_date**        | date                        | The date of the block.                               |
| **block\_height**      | bigint                      | The height of the block where the transfer occurred. |
| **block\_timestamp**   | timestamp(3) with time zone | Timestamp when the block was validated.              |
| **tx\_id**             | varchar                     | The unique ID of the transaction.                    |
| **tx\_index**          | bigint                      | The index of the transaction in the block.           |
| **message\_index**     | bigint                      | The index of the message in the transaction.         |
| **event\_index**       | bigint                      | The index of the event in the message.               |
| **action\_index**      | bigint                      | The index of the action in the event.                |
| **sender**             | varchar                     | The address of the sender.                           |
| **receiver**           | varchar                     | The address of the receiver.                         |
| **token\_amount**      | decimal(38, 0)              | The amount of tokens transferred.                    |
| **token\_denom**       | varchar                     | The denomination of the token.                       |
| **src\_domain**        | varchar                     | The source domain of the transfer.                   |
| **dst\_domain**        | varchar                     | The destination domain of the transfer.              |
| **protocol**           | varchar                     | The protocol used for the transfer.                  |
| **protocol\_metadata** | varchar                     | Additional metadata related to the protocol.         |
| **updated\_at**        | timestamp(3) with time zone | Timestamp of when the record was last updated.       |
| **ingested\_at**       | timestamp(3) with time zone | Timestamp of when the record was ingested into Dune. |

## Table Sample

<TableSample />


# Message Events
Source: https://docs.dune.com/data-catalog/initia/message_events

Initia blockchain message events data

# Table Description

This table contains data about message-related events in the Initia blockchain, including message types, attributes, and associated metadata.

## Table Schema

| Column name          | Description                                           | Type                        |
| -------------------- | ----------------------------------------------------- | --------------------------- |
| **block\_date**      | The date of the block.                                | date                        |
| **block\_height**    | The height of the block where the event occurred.     | bigint                      |
| **block\_timestamp** | Timestamp when the block was validated.               | timestamp(3) with time zone |
| **chain\_id**        | The ID of the chain where the block belongs.          | varchar                     |
| **tx\_id**           | The hash of the transaction where the event occurred. | varchar                     |
| **tx\_index**        | The index of the transaction in the block.            | bigint                      |
| **message\_index**   | The index of the message in the transaction.          | bigint                      |
| **event\_index**     | A unique index for events within the message.         | bigint                      |
| **event\_type**      | The type of event that was triggered.                 | varchar                     |
| **attribute\_key**   | The key of the event attribute.                       | varchar                     |
| **attribute\_value** | The value of the event attribute.                     | varchar                     |
| **attribute\_index** | A unique index for attributes within the event.       | bigint                      |
| **updated\_at**      | Timestamp of when the record was last updated.        | timestamp(3) with time zone |
| **ingested\_at**     | Timestamp of when the record was ingested into Dune.  | timestamp(3) with time zone |

## Table Sample

<TableSample />


# Initia Data
Source: https://docs.dune.com/data-catalog/initia/overview

Initia blockchain data on Dune

## What is Initia?

Initia's core philosophy is to make opinionated decisions on the underlying infrastructure such as data availability, interoperability, and oracles. By reducing decision fatigue, the Interwoven Stack empowers developers with the tools to craft application-specific environments while maintaining un-fragmented accessibility to the application ecosystem.

Initia provides a framework that powers all of Initia's rollups through the Interwoven Stack, featuring enshrined liquidity solutions for bootstrapping cross-chain liquidity while maintaining network security. The platform includes InitiaDEX, Minitswap, and a Vested Interest Program (VIP) that aims to foster long-term ecosystem-wide alignment.

## Key Features

* **Interwoven Stack**: Framework that powers all of Initia's rollups, enabling developers to craft application-specific environments
* **Enshrined Liquidity**: Solution for bootstrapping cross-chain liquidity while maintaining network security
* **VIP Program**: Incentive program that aims to foster long-term ecosystem-wide alignment
* **InitiaDEX**: Decentralized exchange built on the Initia network
* **Minitswap**: Swap functionality integrated into the ecosystem
* **Developer-Friendly**: Tools and infrastructure that reduce decision fatigue for developers

## Initia Data on Dune

Initia blockchain data is organized into several key tables that capture different aspects of on-chain activity:

<CardGroup>
  <Card title="Balances" icon="scale-balanced" href="/data-catalog/initia/balances">
    <p>Account balance snapshots and token holdings</p>
  </Card>

  <Card title="Blocks" icon="cube" href="/data-catalog/initia/blocks">
    <p>Contains each validated block in the chain</p>
  </Card>

  <Card title="Block Events" icon="bolt" href="/data-catalog/initia/block_events">
    <p>Contains all block-level events and attributes in the chain, partitioned by event\_index</p>
  </Card>

  <Card title="Bridge Transfers" icon="bridge" href="/data-catalog/initia/bridge_transfers">
    <p>Cross-chain bridge transfer data</p>
  </Card>

  <Card title="Message Events" icon="message" href="/data-catalog/initia/message_events">
    <p>Contains all events and their corresponding attributes partitioned by message\_index</p>
  </Card>

  <Card title="Swaps" icon="arrows-rotate" href="/data-catalog/initia/swaps">
    <p>Token swap and liquidity pool data</p>
  </Card>

  <Card title="Transactions" icon="arrow-right-arrow-left" href="/data-catalog/initia/transactions">
    <p>Contains relevant data associated with each transaction</p>
  </Card>

  <Card title="Transaction Messages" icon="envelope" href="/data-catalog/initia/tx_messages">
    <p>Contains all messages submitted to the blockchain</p>
  </Card>

  <Card title="Validators" icon="shield" href="/data-catalog/initia/validators">
    <p>Maps validator addresses to monikers (human-readable description) and other metadata</p>
  </Card>
</CardGroup>


# Swaps
Source: https://docs.dune.com/data-catalog/initia/swaps

Initia blockchain token swap transactions data

# Table Description

This table contains data about token swap transactions in the Initia blockchain, including swap details, token pairs, and execution status.

## Column Descriptions

| Column name            | Data Type                   | Description                                          |
| ---------------------- | --------------------------- | ---------------------------------------------------- |
| **block\_date**        | date                        | The date of the block.                               |
| **block\_height**      | bigint                      | The height of the block where the swap occurred.     |
| **block\_timestamp**   | timestamp(3) with time zone | Timestamp when the block was validated.              |
| **tx\_id**             | varchar                     | The unique ID of the transaction.                    |
| **tx\_index**          | bigint                      | The index of the transaction in the block.           |
| **message\_index**     | bigint                      | The index of the message in the transaction.         |
| **event\_index**       | bigint                      | The index of the event in the message.               |
| **action\_index**      | bigint                      | The index of the action in the event.                |
| **sender**             | varchar                     | The address of the sender.                           |
| **token\_amount\_in**  | decimal(38, 0)              | The amount of tokens swapped in.                     |
| **token\_denom\_in**   | varchar                     | The denomination of the token swapped in.            |
| **token\_amount\_out** | decimal(38, 0)              | The amount of tokens swapped out.                    |
| **token\_denom\_out**  | varchar                     | The denomination of the token swapped out.           |
| **routes**             | varchar                     | The routes used for the swap.                        |
| **fees**               | varchar                     | The fees associated with the swap.                   |
| **updated\_at**        | timestamp(3) with time zone | Timestamp of when the record was last updated.       |
| **ingested\_at**       | timestamp(3) with time zone | Timestamp of when the record was ingested into Dune. |

## Table Sample

<TableSample />


# Transactions
Source: https://docs.dune.com/data-catalog/initia/transactions

Initia blockchain transactions data

# Table Description

This table contains data about transactions in the Initia blockchain, including transaction details, gas usage, and execution status.

## Column Descriptions

| Column name            | Data Type                   | Description                                             |
| ---------------------- | --------------------------- | ------------------------------------------------------- |
| **block\_height**      | bigint                      | The height of the block where the transaction occurred. |
| **chain\_id**          | varchar                     | The ID of the chain where the transaction occurred.     |
| **tx\_id**             | varchar                     | The unique ID of the transaction.                       |
| **tx\_info**           | varchar                     | Information related to the transaction.                 |
| **tx\_log\_message**   | varchar                     | The log message associated with the transaction.        |
| **memo**               | varchar                     | A memo associated with the transaction.                 |
| **fee**                | varchar                     | The fee associated with the transaction.                |
| **tx\_code**           | bigint                      | The result code of the transaction.                     |
| **tx\_index**          | bigint                      | The index of the transaction within the block.          |
| **gas\_used**          | bigint                      | The amount of gas used by the transaction.              |
| **gas\_wanted**        | bigint                      | The amount of gas requested by the transaction.         |
| **schema\_version**    | bigint                      | The schema version for the transaction data.            |
| **fee\_coins**         | varchar                     | The coins used to pay the transaction fee.              |
| **fee\_granter**       | varchar                     | The address granting the fee for the transaction.       |
| **fee\_payer**         | varchar                     | The address paying the fee for the transaction.         |
| **gas\_limit**         | bigint                      | The gas limit set for the transaction.                  |
| **single\_sign\_mode** | bigint                      | The signing mode for single-signature transactions.     |
| **multi\_sign\_json**  | varchar                     | JSON structure for multi-signature transactions.        |
| **timeout\_height**    | varchar                     | The timeout height set for the transaction.             |
| **updated\_at**        | timestamp(3) with time zone | Timestamp of when the record was last updated.          |
| **ingested\_at**       | timestamp(3) with time zone | Timestamp of when the record was ingested into Dune.    |

## Table Sample

<TableSample />


# Transaction Messages
Source: https://docs.dune.com/data-catalog/initia/tx_messages

Initia blockchain transaction messages data

# Table Description

This table contains data about messages contained within transactions in the Initia blockchain, including message types, content, and associated metadata.

<Tip>
  On execution, transactions from Cosmos emit data in two formats:

  * Messages (`initia.tx_messages`): These provide a high-level, readable summary of actions, such as "send money" or "execute contract." They are easier to understand and track transaction types.
  * Events (`initia.message_events`): These capture detailed, low-level changes at the chain level, including underlying blockchain modifications that may not always be directly related to state changes.
  * Use Messages for a general overview and Events when you need detailed insights. The two tables are complementary.
</Tip>

## Column Descriptions

| Column name          | Data Type                   | Description                                          |
| -------------------- | --------------------------- | ---------------------------------------------------- |
| **block\_date**      | date                        | The date of the block.                               |
| **block\_height**    | bigint                      | The height of the block where the message occurred.  |
| **block\_timestamp** | timestamp(3) with time zone | Timestamp when the block was validated.              |
| **chain\_id**        | varchar                     | The ID of the chain where the message belongs.       |
| **tx\_id**           | varchar                     | The hash of the transaction containing the message.  |
| **tx\_index**        | bigint                      | The index of the transaction in the block.           |
| **message\_index**   | bigint                      | The index of the message in the transaction.         |
| **message\_type**    | varchar                     | The type of message.                                 |
| **message**          | varchar                     | The value/content of the message.                    |
| **schema\_version**  | bigint                      | The version of the schema in provider database.      |
| **updated\_at**      | timestamp(3) with time zone | Timestamp of when the record was last updated.       |
| **ingested\_at**     | timestamp(3) with time zone | Timestamp of when the record was ingested into Dune. |

## Table Sample

<TableSample />


# Validators
Source: https://docs.dune.com/data-catalog/initia/validators

Initia blockchain validators data

# Table Description

This table contains data about validators in the Initia blockchain, including their performance metrics, voting power, and status.

## Column Descriptions

| Column name                       | Data Type                   | Description                                                        |
| --------------------------------- | --------------------------- | ------------------------------------------------------------------ |
| **operator\_address**             | varchar                     | The operator address of the validator.                             |
| **account\_address**              | varchar                     | The account address of the validator.                              |
| **consensus\_pubkey**             | varchar                     | The consensus public key of the validator.                         |
| **jailed**                        | boolean                     | Indicates whether the validator is jailed.                         |
| **status**                        | varchar                     | The status of the validator (e.g., active, inactive).              |
| **tokens**                        | varchar                     | The number of tokens held by the validator.                        |
| **moniker**                       | varchar                     | The moniker or name of the validator.                              |
| **identity**                      | varchar                     | The identity information of the validator.                         |
| **website**                       | varchar                     | The website of the validator.                                      |
| **security\_contact**             | varchar                     | The security contact information for the validator.                |
| **details**                       | varchar                     | Additional details about the validator.                            |
| **unbonding\_height**             | bigint                      | The block height at which the validator started unbonding.         |
| **unbonding\_time**               | varchar                     | The time when the validator will complete unbonding.               |
| **commission\_rate**              | double                      | The commission rate charged by the validator.                      |
| **commission\_max\_rate**         | double                      | The maximum commission rate allowed for the validator.             |
| **commission\_max\_change\_rate** | double                      | The maximum rate at which the validator can change its commission. |
| **commission\_update\_time**      | varchar                     | The time when the validator last updated its commission.           |
| **min\_self\_delegation**         | varchar                     | The minimum self-delegation required for the validator.            |
| **snapshot\_height**              | bigint                      | The block height at which the snapshot was taken.                  |
| **snapshot\_time**                | varchar                     | The time when the snapshot was taken.                              |
| **updated\_at**                   | timestamp(3) with time zone | Timestamp of when the record was last updated.                     |
| **ingested\_at**                  | timestamp(3) with time zone | Timestamp of when the record was ingested into Dune.               |

## Table Sample

<TableSample />


# kalshi.market_report
Source: https://docs.dune.com/data-catalog/kalshi/market_report

Kalshi market metadata — event contract details, categories, settlement rules, and current status.

The `kalshi.market_report` table contains market data and information about event contracts on Kalshi. Each row represents market statistics and metrics for a specific event contract ticker.

## Table Schema

| Column Name    | Data Type | Description                                                              |
| -------------- | --------- | ------------------------------------------------------------------------ |
| block\_volume  | double    | Trading volume for the block period                                      |
| category       | string    | Category of the event contract (e.g., Politics, Economics, Sports, etc.) |
| daily\_volume  | double    | Total trading volume for the day                                         |
| date           | string    | Date of the market report                                                |
| high           | double    | Highest price reached during the reporting period                        |
| low            | double    | Lowest price reached during the reporting period                         |
| open\_interest | double    | Total number of outstanding contracts                                    |
| payout\_type   | string    | Type of payout for the event contract                                    |
| report\_ticker | string    | Unique ticker identifier for the market report                           |
| status         | string    | Current status of the event contract market                              |
| ticker\_name   | string    | Name or description of the event contract ticker                         |
| \_updated\_at  | timestamp | Last update timestamp                                                    |
| \_ingested\_at | timestamp | Ingestion timestamp                                                      |


# Kalshi
Source: https://docs.dune.com/data-catalog/kalshi/overview

Kalshi event contracts data on Dune

Kalshi is the first CFTC regulated exchange dedicated to trading on the outcome of future events. From inflation, to fed rates, to unemployment, to will the government shut down, Kalshi allows people to trade on a broad range of topics. Kalshi has developed a new asset class, event contracts, where you can buy Yes or No positions with respect to whether an event will happen or not. Kalshi's vision is to allow people to capitalize on their opinions, trade in the domain of every day, and hedge risks that relate to them.

## Event Contracts

Kalshi's Event Contracts give people the ability to trade based on their opinions about a specific yes-or-no question. For example, if you have student debt and are worried about relief not passing, you can purchase a contract and get a payout even if it doesn't pass. If you're worried about the economic fallout of the government shutting down, you can place a trade to hedge against it. If you've developed a model on inflation, you can profit from that and maybe even offset your rising costs.

Event Contracts have an interesting side effect - the price that a given event contract trades at is actually the market's assessment of the probability that the event will happen. Kalshi's inflation and federal rate forecasts have been more accurate than economists, pundits, and traditional news outlets over the past year.

Kalshi offers Event Contracts on a wide range of topics, including economics, culture, weather, scientific advancements, and traditional financial markets such as commodities, forex, S\&P, and NASDAQ indices.

## Key Features

* **CFTC Regulated**: Kalshi is regulated by the Commodity Futures Trading Commission (CFTC) as a Designated Contract Market (DCM)
* **Event-Based Trading**: Trade on the outcome of future events with Yes or No positions
* **Broad Market Coverage**: Event contracts on economics, politics, sports, culture, crypto, climate, health, and more
* **Market Probability Assessment**: Event contract prices reflect the market's assessment of event probability
* **Risk Hedging**: Ability to hedge against everyday risks and economic events
* **Election Trading**: First fully regulated platform in over a century to offer legal election trading in the United States

## Company History

Kalshi was founded in 2018 by Tarek Mansour and Luana Lopes Lara, who met while studying at the Massachusetts Institute of Technology (MIT). During their early careers at financial institutions like Goldman Sachs, Citadel, and Bridgewater, Tarek and Luana observed that many financial decisions were driven by predictions about future events. However, they noticed a gap in the market: there was no straightforward way for people to trade directly on event outcomes.

In 2019, Kalshi was accepted into Y Combinator's Winter batch, where the team further developed the platform. In 2020, Kalshi made history by becoming the first fully regulated financial exchange in the U.S. specifically for event contracts, officially designated as a Designated Contract Market (DCM) by the CFTC.

In 2024, Kalshi achieved a historic milestone by becoming the first fully regulated platform in over a century to offer legal election trading in the United States, following a federal appeals court ruling that upheld Kalshi's right to list contracts on political outcomes.

## Kalshi Data on Dune

<CardGroup>
  <Card title="Market Report" icon="database" href="/data-catalog/kalshi/market_report">
    Contains market data and information about event contracts
  </Card>

  <Card title="Trade Report" icon="database" href="/data-catalog/kalshi/trade_report">
    Contains trade execution data and transaction information
  </Card>
</CardGroup>

<CardGroup>
  <Card title="Kalshi Website" icon="link" href="https://kalshi.com/about">
    Learn more about Kalshi, event contracts, and the platform
  </Card>
</CardGroup>


# kalshi.trade_report
Source: https://docs.dune.com/data-catalog/kalshi/trade_report

Kalshi trade data — individual trades on event contracts with price, size, and execution details.

The `kalshi.trade_report` table contains trade execution data and transaction information for event contracts on Kalshi. Each row represents a trade execution for a specific event contract ticker.

## Table Schema

| Column Name       | Data Type | Description                                      |
| ----------------- | --------- | ------------------------------------------------ |
| contracts\_traded | double    | Number of contracts traded in the transaction    |
| date              | string    | Date of the trade report                         |
| price             | double    | Price at which the contracts were traded         |
| report\_ticker    | string    | Unique ticker identifier for the trade report    |
| ticker\_name      | string    | Name or description of the event contract ticker |
| \_updated\_at     | timestamp | Last update timestamp                            |
| \_ingested\_at    | timestamp | Ingestion timestamp                              |


# layerzero.messages
Source: https://docs.dune.com/data-catalog/layerzero/messages

LayerZero cross-chain messages — message payloads, endpoints, and routing data.

The `layerzero.messages` table contains all cross-chain messages sent through the LayerZero protocol. Each message represents a cross-chain communication event between source and destination chains.

## Table Schema

| Column Name                | Data Type     | Description                                   |
| -------------------------- | ------------- | --------------------------------------------- |
| timestampUpdated           | timestamp     | Timestamp of the last update                  |
| primary\_key               | string        | Unique identifier for the message             |
| transfer\_foreign\_key     | string        | Foreign key reference to the transfer         |
| tx\_hash\_source           | string        | Transaction hash on the source chain          |
| tx\_hash\_destination      | string        | Transaction hash on the destination chain     |
| ts\_source                 | timestamp     | Timestamp of the message on source chain      |
| ts\_destination            | timestamp     | Timestamp of the message on destination chain |
| block\_number\_source      | decimal(38,0) | Block number on the source chain              |
| block\_number\_destination | decimal(38,0) | Block number on the destination chain         |
| addr\_from                 | string        | Address of the message sender                 |
| usd\_dvn\_fee              | double        | USD value of the DVN fee                      |
| usd\_executor\_fee         | double        | USD value of the executor fee                 |
| usd\_value                 | double        | Total USD value of the message                |
| source\_contract           | string        | Contract address on the source chain          |
| source\_chain              | string        | Source chain identifier                       |
| source\_chain\_key         | string        | Source chain key                              |
| source\_layer              | string        | Source chain layer                            |
| destination\_contract      | string        | Contract address on the destination chain     |
| destination\_chain         | string        | Destination chain identifier                  |
| destination\_chain\_key    | string        | Destination chain key                         |
| destination\_layer         | string        | Destination chain layer                       |
| project                    | string        | Project identifier                            |
| state                      | string        | Current state of the message                  |
| layerzero\_version         | string        | Version of LayerZero protocol used            |
| uln\_version               | string        | Version of ULN used                           |
| \_updated\_at              | timestamp     | Last update timestamp                         |
| \_ingested\_at             | timestamp     | Ingestion timestamp                           |

## Sample Query

```sql theme={null}
-- Get the total number of messages and total value transferred per chain pair
SELECT 
    source_chain,
    destination_chain,
    COUNT(*) as message_count,
    SUM(usd_value) as total_value_usd
FROM layerzero.messages
WHERE ts_source >= NOW() - INTERVAL '7' DAY
GROUP BY source_chain, destination_chain
ORDER BY total_value_usd DESC
LIMIT 10;
```


# LayerZero
Source: https://docs.dune.com/data-catalog/layerzero/overview

LayerZero crosschain data on Dune

LayerZero is a cross-chain messaging protocol that enables the transfer of messages and assets between different blockchain networks. It provides a secure and efficient way for applications to communicate and transfer value across chains.

## Key Features

* **Omnichain Interoperability**: Enables seamless communication between different blockchain networks
* **Security**: Uses a decentralized network of oracles and validators
* **Efficiency**: Optimized for gas efficiency and fast message delivery
* **Developer-Friendly**: Simple integration with existing applications
* **Wide Chain Support**: Compatible with major EVM and non-EVM chains

## LayerZero Data on Dune

<CardGroup>
  <Card title="Messages" icon="database" href="/data-catalog/layerzero/messages">
    Contains all cross-chain messages sent through the LayerZero protocol
  </Card>

  <Card title="Transfers" icon="database" href="/data-catalog/layerzero/transfers">
    Contains all cross-chain transfers executed through the LayerZero protocol
  </Card>
</CardGroup>

<CardGroup>
  <Card title="LayerZero Documentation" icon="link" href="https://docs.layerzero.network/v2">
    The official documentation for LayerZero, providing detailed information on the protocol, architecture, and developer resources
  </Card>
</CardGroup>


# layerzero.transfers
Source: https://docs.dune.com/data-catalog/layerzero/transfers

LayerZero cross-chain token transfers — bridged assets with source/destination chain details.

The `layerzero.transfers` table contains all cross-chain transfers executed through the LayerZero protocol. Each transfer represents a value transfer event between source and destination chains.

## Table Schema

| Column Name            | Data Type | Description                                     |
| ---------------------- | --------- | ----------------------------------------------- |
| timestampUpdated       | timestamp | Timestamp of the last update                    |
| primary\_key           | string    | Unique identifier for the transfer              |
| messages\_foreign\_key | string    | Foreign key reference to the associated message |
| addr\_to               | string    | Recipient address                               |
| type\_transfer         | string    | Type of transfer                                |
| symbol                 | string    | Token symbol                                    |
| token                  | string    | Token address                                   |
| usd\_value             | double    | USD value of the transfer                       |
| \_updated\_at          | timestamp | Last update timestamp                           |
| \_ingested\_at         | timestamp | Ingestion timestamp                             |

## Sample Query

```sql theme={null}
-- Get the top tokens by volume transferred in the last 24 hours
SELECT 
    symbol,
    COUNT(*) as transfer_count,
    SUM(usd_value) as total_volume_usd
FROM layerzero.transfers
WHERE timestampUpdated >= NOW() - INTERVAL '24' HOUR
GROUP BY symbol
ORDER BY total_volume_usd DESC
LIMIT 10;
```


# near.actions
Source: https://docs.dune.com/data-catalog/near/actions

NEAR Protocol actions — function calls, transfers, and account operations.

## Table Description

The `near.actions` table contains comprehensive data related to transactions on the NEAR blockchain, including transaction metadata like `block_date` and `tx_hash`, execution statuses, receipts, and detailed action information when applicable.

In NEAR, a transaction can consist of one or more actions, signed by the sender's account and executed by the network. These actions may involve token transfers, smart contract invocations, staking, and more.

NEAR employs a unique transaction lifecycle where transactions are validated on the sender's shard, converted into receipts, and processed on the receiver's shard. This approach ensures efficient handling of cross-shard communication and data flow.

To gain a clearer understanding of how NEAR data flows, watch our [NEAR Data Flow video tutorial](/resources/learning/video-tutorials#near-data-flow) or visit the [NEAR Data Flow documentation](https://docs.near.org/concepts/data-flow/near-data-flow).

## Column Descriptions

| Column                                                 | Description                                                                                  | Type                        |
| ------------------------------------------------------ | -------------------------------------------------------------------------------------------- | --------------------------- |
| block\_date                                            | The date of the block when the action occurred.                                              | date                        |
| block\_height                                          | The height of the block in which the action was executed.                                    | bigint                      |
| block\_time                                            | The timestamp of when the block containing the action was produced.                          | timestamp(3) with time zone |
| block\_hash                                            | The unique hash of the block containing the action.                                          | varchar                     |
| chunk\_hash                                            | The hash of the chunk within the block where the action is recorded.                         | varchar                     |
| shard\_id                                              | The shard ID in which the action was executed, relating to NEAR’s sharded architecture.      | bigint                      |
| index\_in\_action\_receipt                             | The index of the action within its corresponding receipt, indicating ordering of the action. | integer                     |
| receipt\_id                                            | The unique identifier of the receipt associated with this action.                            | varchar                     |
| gas\_price                                             | The gas price paid for executing the action, in yoctoNEAR (1 NEAR = 10^24 yoctoNEAR).        | bigint                      |
| receipt\_predecessor\_account\_id                      | The account that sent the receipt containing the action.                                     | varchar                     |
| receipt\_receiver\_account\_id                         | The account that receives the action.                                                        | varchar                     |
| receipt\_conversion\_gas\_burnt                        | The amount of gas burnt during the conversion of the receipt.                                | bigint                      |
| receipt\_conversion\_tokens\_burnt                     | The amount of gas burnt during the conversion of the receipt, divided by 10^8.               | uint256                     |
| tx\_hash                                               | The unique hash identifying the transaction containing the action.                           | varchar                     |
| tx\_from                                               | The account that initiated the transaction.                                                  | varchar                     |
| tx\_to                                                 | The account that is the recipient of the transaction.                                        | varchar                     |
| tx\_signer\_public\_key                                | The public key of the account that signed the transaction.                                   | varchar                     |
| tx\_nonce                                              | The nonce used by the account to ensure the transaction is unique.                           | bigint                      |
| tx\_signature                                          | The cryptographic signature that verifies the authenticity of the transaction.               | varchar                     |
| tx\_status                                             | The status of the transaction, indicating success or failure.                                | varchar                     |
| is\_delegate\_action                                   | Boolean flag indicating whether the action is a delegated action.                            | boolean                     |
| execution\_gas\_burnt                                  | The amount of gas burnt during the execution of the action.                                  | bigint                      |
| execution\_tokens\_burnt                               | The amount of raw NEAR token burnt during the execution of the action.                       | uint256                     |
| execution\_status                                      | The status of the execution of the action.                                                   | varchar                     |
| execution\_outcome\_receipt\_ids                       | Array of receipt IDs created as a result of the execution.                                   | array(varchar)              |
| action\_kind                                           | The type of action, such as FUNCTION\_CALL, DELEGATE\_ACTION, TRANSFER, STAKE, etc.          | varchar                     |
| processed\_time                                        | The timestamp of when the action was processed by Dune.                                      | timestamp(3) with time zone |
| action\_function\_call\_args\_parsed                   | Parsed (decoded) arguments of the function call action.                                      | varchar                     |
| action\_function\_call\_call\_gas                      | The amount of gas attached to the function call action.                                      | bigint                      |
| action\_function\_call\_call\_deposit                  | The amount of NEAR tokens attached to the function call action.                              | varchar                     |
| action\_function\_call\_call\_args\_base64             | Base64 encoded arguments of the function call action.                                        | varchar                     |
| action\_function\_call\_call\_method\_name             | The name of the method being called in the function call action.                             | varchar                     |
| action\_delegate\_signature                            | Signature of the delegation action.                                                          | varchar                     |
| action\_delegate\_delegate\_action\_actions            | List of actions being delegated to another account.                                          | array(row("functioncall"))  |
| action\_delegate\_delegate\_action\_max\_block\_height | The maximum block height at which the delegated action can be executed.                      | varchar                     |
| action\_delegate\_delegate\_action\_nonce              | Nonce of the delegated action for uniqueness.                                                | varchar                     |
| action\_delegate\_delegate\_action\_public\_key        | Public key of the delegate executing the action.                                             | varchar                     |
| action\_delegate\_delegate\_action\_receiver\_id       | Account receiving the delegated action.                                                      | varchar                     |
| action\_delegate\_delegate\_action\_sender\_id         | Account sending the delegated action.                                                        | varchar                     |
| action\_delete\_account\_beneficiary\_id               | Account of the beneficiary receiving remaining balance upon account deletion.                | varchar                     |
| action\_delete\_key\_public\_key                       | Public key being deleted from the account.                                                   | varchar                     |
| action\_add\_key\_public\_key                          | Public key being added to the account.                                                       | varchar                     |
| action\_add\_key\_access\_key\_nonce                   | Nonce of the access key being added.                                                         | varchar                     |
| action\_add\_key\_access\_key\_permission              | Permissions granted to the newly added access key.                                           | varchar                     |
| action\_stake\_public\_key                             | Public key used for staking by the account.                                                  | varchar                     |
| action\_stake\_stake                                   | Amount of NEAR tokens staked by the account.                                                 | varchar                     |
| action\_transfer\_deposit                              | Amount of NEAR tokens being transferred between accounts.                                    | varchar                     |
| action\_deploy\_contract\_code\_sha256                 | SHA256 hash of the code being deployed in the contract.                                      | varchar                     |
| updated\_at                                            | Timestamp of when the record was last updated.                                               | timestamp(3) with time zone |
| ingested\_at                                           | Timestamp of when the record was ingested into Dune.                                         | timestamp(3) with time zone |

## Table Sample

<TableSample />

## Data Manipulation Tips

The `actions` data in NEAR can be complicated and nested, causing it hard to analyze sometimes. So here we give two examples on how to work array and json data to make it easier to analyze.

### Explode array of rows into separate rows with defined fields

When the action type is "DELEGATE\_ACTION", the `action_delegate_delegate_action_actions` becomes an array of size n with rows of fields. We can utilize `CROSS JOIN UNNEST` to first explode the array, then use `.` directly to access the fields in the row.

Reference query [can be found here](https://dune.com/queries/4078275?sidebar=none).

```sql theme={null}
with exploded as (
    select block_date
        , block_height as block_height_executed
        , tx_hash
        , receipt_id -- receipt for this action (there are many actions included in one txn)
        , execution_status
        
        , cardinality(action_delegate_delegate_action_actions) as delegated_action_size -- how many function calls are being delegated
        
        , action_delegate_delegate_action_sender_id as action_from 
        , action_delegate_delegate_action_receiver_id as action_to 
        
    
        -- Explode the array into rows
        , actions.value as action_data
        , actions.index as delegated_action_index
        , action_delegate_delegate_action_actions as raw_delegated_actions -- raw nested list of delegated actions
        
    /* explode by doing cross join unnest here*/    
    from near.actions CROSS JOIN UNNEST(action_delegate_delegate_action_actions) WITH ORDINALITY as actions(value, index)
    where action_kind = 'DELEGATE_ACTION'
        and cardinality(action_delegate_delegate_action_actions) >= 2
        and receipt_id = '6DB2AzkLXzoU9CMj9GKSZi7y8dGxVrqrbtBsfpLVQCQ8'
        and block_date = date('2024-09-17')
        and block_height = 128251854
)

select block_date
    , block_height_executed
    , tx_hash
    , receipt_id 
    , execution_status
    , delegated_action_size -- how many function calls are being delegated
    
    , action_from 
    , action_to 
    
    -- , typeof(action_data) -- row(args varchar, deposit varchar, gas bigint, method_name varchar)
    
    /* below is how you can access the delegated function call info */
    , action_data.args as function_call_args
    , action_data.deposit as function_call_deposit
    , action_data.gas as function_call_gas
    , action_data.method_name as function_call_method_name
    , delegated_action_index
    
    , raw_delegated_actions -- raw nested list of delegated actions
from exploded 

```

### Extract fields from JSON string

When the action type is "FUNCTION\_CALL", the `action_function_call_args_parsed` becomes a JSON string. We can utilize `json_extract` with `$.<field_name>` syntax to extract the fields from the JSON string.

Reference query [can be found here](https://dune.com/queries/4078309?sidebar=none).

```sql theme={null}
select block_date
    , block_height as block_height_executed
    , tx_hash
    , receipt_id -- receipt for this action (there are many actions included in one txn)
    , execution_status
    
    , receipt_predecessor_account_id as action_from
    , receipt_receiver_account_id as action_to
    
    -- , typeof(args_parsed) as data_type 
    /* This is how you can get fields within each parsed function call args 
        - first examine the fields in the args_parsed for the tye of method `call_method_name`
        - then parse accordingly
    */
    , json_extract(args_parsed, '$.receiver_id') AS receiver_id
    , json_extract(args_parsed, '$.amount') AS amount
    , json_extract(args_parsed, '$.memo') AS memo
    
    , call_method_name as call_method_name
    , args_parsed as raw_call_args
    , call_gas as call_gas
    , call_deposit as call_deposit
    , call_args_base64
    
    , *
from near.function_call -- near.actions
where 1=1
    and block_date = date('2023-09-15')
    and call_method_name = 'ft_transfer'
limit 10
```


# near.balances
Source: https://docs.dune.com/data-catalog/near/balances

NEAR account balances — native NEAR token holdings by account.

## Table description

The `near.balances` table tracks account balance details on NEAR, including the liquid balance, staked amounts, and rewards for both main and lockup accounts.

## Column Descriptions

| Column                        | Description                                                         | Type                        |
| ----------------------------- | ------------------------------------------------------------------- | --------------------------- |
| epoch\_date                   | The date of the epoch when the balance was recorded.                | date                        |
| epoch\_block\_height          | The block height of the epoch when the balance was recorded.        | bigint                      |
| account\_id                   | The account whose balance is being tracked.                         | varchar                     |
| liquid                        | Amount of liquid NEAR tokens in the account.                        | double                      |
| storage\_usage                | The amount of storage usage associated with the account.            | bigint                      |
| unstaked\_not\_liquid         | The amount of unstaked but not liquid NEAR tokens in the account.   | double                      |
| staked                        | The amount of staked NEAR tokens in the account.                    | double                      |
| reward                        | Reward tokens accumulated by the account from staking.              | double                      |
| lockup\_account\_id           | The ID of the lockup account associated with the account.           | varchar                     |
| lockup\_liquid                | Amount of liquid NEAR tokens in the lockup account.                 | double                      |
| lockup\_unstaked\_not\_liquid | The amount of unstaked but not liquid tokens in the lockup account. | double                      |
| lockup\_staked                | The amount of staked NEAR tokens in the lockup account.             | double                      |
| lockup\_reward                | Reward tokens accumulated in the lockup account from staking.       | double                      |
| processed\_time               | The time when the balance was processed.                            | date                        |
| updated\_at                   | The time when this balance record was last updated.                 | timestamp(3) with time zone |
| ingested\_at                  | The time when this balance record was ingested into Dune.           | timestamp(3) with time zone |

## Table Sample

<TableSample />


# near.block_chunks
Source: https://docs.dune.com/data-catalog/near/block_chunks

NEAR block chunks — block data with chunk-level transaction groupings.

## Table description

The `near.block_chunks` table contains block chunk data on NEAR. Chunk of a block is a part of a block from a shard. The collection of chunks of the block forms the NEAR Protocol block.

## Column Descriptions

| Column                     | Description                                            | Type                        |
| -------------------------- | ------------------------------------------------------ | --------------------------- |
| date                       | The date of the block where the chunk is included.     | date                        |
| height                     | The block height at which the chunk was produced.      | bigint                      |
| time                       | The timestamp of when the chunk was produced.          | timestamp(3) with time zone |
| hash                       | The hash of the chunk.                                 | varchar                     |
| prev\_hash                 | The hash of the previous chunk in the chain.           | varchar                     |
| total\_supply              |                                                        | uint256                     |
| gas\_price                 | Gas price paid for executing the chunk.                | bigint                      |
| author\_account\_id        | The account that produced the chunk.                   | varchar                     |
| epoch\_id                  | The ID of the epoch in which the chunk was produced.   | varchar                     |
| shard\_id                  | The shard ID that contains the chunk.                  | bigint                      |
| chunk\_hash                | Hash of the chunk.                                     | varchar                     |
| chunk\_signature           | The cryptographic signature validating the chunk.      | varchar                     |
| chunk\_gas\_limit          | Maximum gas limit for this chunk.                      | bigint                      |
| chunk\_gas\_used           | Gas actually used in the chunk.                        | bigint                      |
| chunk\_author\_account\_id | The account that produced this chunk.                  | varchar                     |
| processed\_time            | Timestamp when the chunk was processed into Dune.      | timestamp(3) with time zone |
| updated\_at                | Timestamp when this chunk was last updated.            | timestamp(3) with time zone |
| ingested\_at               | Timestamp when this chunk data was ingested into Dune. | timestamp(3) with time zone |

## Table Sample

<TableSample />


# near.circulating_supply
Source: https://docs.dune.com/data-catalog/near/circulating_supply

NEAR circulating supply snapshots — total and circulating NEAR over time.

## Table description

The `near.circulating_supply` table holds daily circulating and total supply of tokens in NEAR.

## Column Descriptions

| Column                         | Description                                                  | Type                        |
| ------------------------------ | ------------------------------------------------------------ | --------------------------- |
| block\_date                    | The date of the block when the supply was recorded.          | date                        |
| computed\_at\_block\_timestamp | Timestamp of the block when the supply was computed.         | timestamp(3) with time zone |
| computed\_at\_block\_hash      | Hash of the block at the time of supply computation.         | varchar                     |
| computed\_at\_block\_height    | Block height at which the supply was computed.               | bigint                      |
| circulating\_tokens\_supply    | The circulating supply of tokens at the time of computation. | double                      |
| total\_tokens\_supply          | The total supply of tokens at the time of computation.       | double                      |
| processed\_time                | The timestamp when the supply data was processed.            | timestamp(3) with time zone |
| updated\_at                    | Timestamp of the last update to this record.                 | timestamp(3) with time zone |
| ingested\_at                   | Timestamp when this data was ingested into Dune.             | timestamp(3) with time zone |

## Table Sample

<TableSample />


# near.ft_transfers
Source: https://docs.dune.com/data-catalog/near/ft_transfers

NEAR fungible token transfers — NEP-141 token movements.

## Table description

The `near.ft_transfers` table tracks all Fungible Token (FT) transfers in NEAR.

## Column Descriptions

| Column                | Description                                                        | Type                        |
| --------------------- | ------------------------------------------------------------------ | --------------------------- |
| block\_date           | The date when the FT transfer occurred.                            | date                        |
| block\_height         | The block height at the time of the FT transfer.                   | bigint                      |
| block\_time           | Timestamp when the block containing the FT transfer was produced.  | timestamp(3) with time zone |
| block\_hash           | The unique hash of the block containing the FT transfer.           | varchar                     |
| chunk\_hash           | The hash of the chunk within the block containing the FT transfer. | varchar                     |
| shard\_id             | Shard ID where the FT transfer was executed.                       | bigint                      |
| standard              | The FT standard associated with the transfer (e.g., "nep141").     | varchar                     |
| token\_id             | ID of the Fungible Token involved in the transfer (e.g., "near").  | varchar                     |
| receipt\_id           | The receipt ID associated with the FT transfer.                    | varchar                     |
| contract\_account\_id | The contract account handling the FT transfer.                     | varchar                     |
| cause                 | The function name invoked to cause the FT transfer.                | varchar                     |
| status                | The status of the FT transfer (e.g., "SUCCESS\_VALUE").            | varchar                     |
| event\_memo           | Memo attached to the FT transfer event.                            | varchar                     |
| event\_index          | Event index of the FT transfer event.                              | uint256                     |
| affected\_account\_id | The account affected by the FT transfer, i.e. the "to" account.    | varchar                     |
| involved\_account\_id | The account involved in the FT transfer, i.e. the "from" account.  | varchar                     |
| delta\_amount         | The amount of FT tokens transferred.                               | decimal(38,0)               |
| processed\_time       | Timestamp when the FT transfer data was processed.                 | timestamp(3) with time zone |
| updated\_at           | Timestamp when the FT transfer record was last updated.            | timestamp(3) with time zone |
| ingested\_at          | Timestamp when the FT transfer data was ingested into Dune.        | timestamp(3) with time zone |

## Table Sample

<TableSample />


# near.function_call
Source: https://docs.dune.com/data-catalog/near/function_call

NEAR function call actions — contract method invocations with arguments.

## Table description

The `near.function_call` table contains flattened out details for records in the `actions` table of the `FUNCTION_CALL` type.

## Column Descriptions

| Column                             | Description                                                               | Type                        |
| ---------------------------------- | ------------------------------------------------------------------------- | --------------------------- |
| block\_date                        | The date of the block where the function call occurred.                   | date                        |
| block\_time                        | The time when the block containing the function call was produced.        | timestamp(3) with time zone |
| block\_height                      | The block height at the time of the function call.                        | bigint                      |
| block\_hash                        | The unique hash of the block containing the function call.                | varchar                     |
| chunk\_hash                        | The hash of the chunk where the function call is recorded.                | varchar                     |
| shard\_id                          | Shard ID where the function call was executed.                            | bigint                      |
| tx\_hash                           | The transaction hash containing the function call.                        | varchar                     |
| tx\_from                           | The account that initiated the function call.                             | varchar                     |
| tx\_to                             | The account receiving the function call.                                  | varchar                     |
| tx\_status                         | Status of the function call (success or failure).                         | varchar                     |
| call\_method\_name                 | The method being called in the function call.                             | varchar                     |
| args\_parsed                       | Parsed (decoded) arguments for the function call.                         | varchar                     |
| call\_gas                          | Gas attached to the function call.                                        | bigint                      |
| call\_deposit                      | Amount of NEAR tokens attached to the function call.                      | varchar                     |
| call\_args\_base64                 | Base64 encoded arguments of the function call.                            | varchar                     |
| index\_in\_action\_receipt         | The index of the function call within the receipt.                        | integer                     |
| receipt\_id                        | The receipt ID associated with the function call.                         | varchar                     |
| gas\_price                         | The gas price paid for executing the function call.                       | bigint                      |
| receipt\_predecessor\_account\_id  | The ID of the predecessor account for the receipt.                        | varchar                     |
| receipt\_receiver\_account\_id     | The ID of the receiver account for the receipt.                           | varchar                     |
| receipt\_conversion\_gas\_burnt    | The gas burnt during the conversion of the receipt.                       | bigint                      |
| receipt\_conversion\_tokens\_burnt | The amount of raw NEAR burnt during the conversion of the receipt.        | uint256                     |
| execution\_gas\_burnt              | Amount of gas burnt during the execution of the function call.            | bigint                      |
| execution\_tokens\_burnt           | Amount of raw NEAR token burnt during the execution of the function call. | uint256                     |
| execution\_status                  | The status of the execution outcome of the function call.                 | varchar                     |
| execution\_outcome\_receipt\_ids   | Array of receipt IDs created as a result of the function call.            | array(varchar)              |
| updated\_at                        | The time when this function call record was last updated.                 | timestamp(3) with time zone |
| ingested\_at                       | The time when this function call data was ingested into Dune.             | timestamp(3) with time zone |
| processed\_time                    | The time when the function call was processed.                            | timestamp(3) with time zone |

## Table Sample

<TableSample />

## Data Manipulation Tips

The `actions` data in NEAR can be complicated and nested, causing it hard to analyze sometimes. So here we give two examples on how to work array and json data to make it easier to analyze.

### Explode array of rows into separate rows with defined fields

When the action type is "DELEGATE\_ACTION", the `action_delegate_delegate_action_actions` becomes an array of size n with rows of fields. We can utilize `CROSS JOIN UNNEST` to first explode the array, then use `.` directly to access the fields in the row.

Reference query [can be found here](https://dune.com/queries/4078275?sidebar=none).

```sql theme={null}
with exploded as (
    select block_date
        , block_height as block_height_executed
        , tx_hash
        , receipt_id -- receipt for this action (there are many actions included in one txn)
        , execution_status
        
        , cardinality(action_delegate_delegate_action_actions) as delegated_action_size -- how many function calls are being delegated
        
        , action_delegate_delegate_action_sender_id as action_from 
        , action_delegate_delegate_action_receiver_id as action_to 
        
    
        -- Explode the array into rows
        , actions.value as action_data
        , actions.index as delegated_action_index
        , action_delegate_delegate_action_actions as raw_delegated_actions -- raw nested list of delegated actions
        
    /* explode by doing cross join unnest here*/    
    from near.actions CROSS JOIN UNNEST(action_delegate_delegate_action_actions) WITH ORDINALITY as actions(value, index)
    where action_kind = 'DELEGATE_ACTION'
        and cardinality(action_delegate_delegate_action_actions) >= 2
        and receipt_id = '6DB2AzkLXzoU9CMj9GKSZi7y8dGxVrqrbtBsfpLVQCQ8'
        and block_date = date('2024-09-17')
        and block_height = 128251854
)

select block_date
    , block_height_executed
    , tx_hash
    , receipt_id 
    , execution_status
    , delegated_action_size -- how many function calls are being delegated
    
    , action_from 
    , action_to 
    
    -- , typeof(action_data) -- row(args varchar, deposit varchar, gas bigint, method_name varchar)
    
    /* below is how you can access the delegated function call info */
    , action_data.args as function_call_args
    , action_data.deposit as function_call_deposit
    , action_data.gas as function_call_gas
    , action_data.method_name as function_call_method_name
    , delegated_action_index
    
    , raw_delegated_actions -- raw nested list of delegated actions
from exploded 

```

### Extract fields from JSON string

When the action type is "FUNCTION\_CALL", the `action_function_call_args_parsed` becomes a JSON string. We can utilize `json_extract` with `$.<field_name>` syntax to extract the fields from the JSON string.

Reference query [can be found here](https://dune.com/queries/4078309?sidebar=none).

```sql theme={null}
select block_date
    , block_height as block_height_executed
    , tx_hash
    , receipt_id -- receipt for this action (there are many actions included in one txn)
    , execution_status
    
    , receipt_predecessor_account_id as action_from
    , receipt_receiver_account_id as action_to
    
    -- , typeof(args_parsed) as data_type 
    /* This is how you can get fields within each parsed function call args 
        - first examine the fields in the args_parsed for the tye of method `call_method_name`
        - then parse accordingly
    */
    , json_extract(args_parsed, '$.receiver_id') AS receiver_id
    , json_extract(args_parsed, '$.amount') AS amount
    , json_extract(args_parsed, '$.memo') AS memo
    
    , call_method_name as call_method_name
    , args_parsed as raw_call_args
    , call_gas as call_gas
    , call_deposit as call_deposit
    , call_args_base64
    
    , *
from near.function_call -- near.actions
where 1=1
    and block_date = date('2023-09-15')
    and call_method_name = 'ft_transfer'
limit 10
```


# near.logs
Source: https://docs.dune.com/data-catalog/near/logs

NEAR execution logs — log output from smart contract execution.

## Table description

The `near.logs` table captures the output generated during the execution of smart contracts. They record key events and actions, such as token transfers or function calls, and are used for tracking, debugging, and monitoring contract activity. Logs help developers understand what happened during a transaction, making it easier to analyze and troubleshoot smart contract behavior.

## Column Descriptions

| Column                              | Description                                                               | Type                        |
| ----------------------------------- | ------------------------------------------------------------------------- | --------------------------- |
| block\_date                         | The date of the block where the log entry was generated.                  | date                        |
| block\_height                       | The block height at which the log entry was generated.                    | bigint                      |
| block\_time                         | The time when the block containing the log entry was produced.            | timestamp(3) with time zone |
| execution\_status                   | The status of the execution outcome associated with the log.              | varchar                     |
| executor\_account\_id               | The account that executed the transaction resulting in the log.           | varchar                     |
| receipt\_id                         | The receipt ID associated with the log.                                   | varchar                     |
| index\_in\_execution\_outcome\_logs | Index of the log entry within the execution outcome, indicating ordering. | integer                     |
| log                                 | The actual log message from the execution outcome.                        | varchar                     |
| event                               | Event description generated during execution.                             | varchar                     |
| processed\_time                     | The time when the log data was processed.                                 | timestamp(3) with time zone |
| updated\_at                         | The time when the log record was last updated.                            | timestamp(3) with time zone |
| ingested\_at                        | The time when the log data was ingested.                                  | timestamp(3) with time zone |

## Table Sample

<TableSample />


# near.nft_transfers
Source: https://docs.dune.com/data-catalog/near/nft_transfers

NEAR NFT transfers — NEP-171 non-fungible token movements.

## Table description

The `near.nft_transfers` table tracks all Non-Fungible Token (NFT) transfers in NEAR.

## Column Descriptions

| Column                  | Description                                                                      | Type                        |
| ----------------------- | -------------------------------------------------------------------------------- | --------------------------- |
| block\_date             | The date when the NFT transfer occurred.                                         | date                        |
| block\_height           | The block height at the time of the NFT transfer.                                | bigint                      |
| block\_time             | Timestamp when the block containing the NFT transfer was produced.               | timestamp(3) with time zone |
| block\_hash             | The unique hash of the block containing the NFT transfer.                        | varchar                     |
| chunk\_hash             | The hash of the chunk within the block containing the NFT transfer.              | varchar                     |
| shard\_id               | Shard ID where the NFT transfer was executed.                                    | bigint                      |
| standard                | The NFT standard associated with the transfer (e.g., "nep171").                  | varchar                     |
| token\_id               | ID of the Non-Fungible Token being transferred.                                  | varchar                     |
| receipt\_id             | The receipt ID associated with the NFT transfer.                                 | varchar                     |
| contract\_account\_id   | The contract account handling the NFT transfer.                                  | varchar                     |
| cause                   | The function name invoked to cause the NFT transfer.                             | varchar                     |
| status                  | The status of the NFT transfer (e.g., "SUCCESS\_VALUE", "SUCCESS\_RECEIPT\_ID"). | varchar                     |
| event\_memo             | Memo attached to the NFT transfer event.                                         | varchar                     |
| event\_index            | Event index of the NFT transfer event.                                           | uint256                     |
| old\_owner\_account\_id | Old owner account of the NFT, i.e. the "from" account.                           | varchar                     |
| new\_owner\_account\_id | New owner account of the NFT, i.e. the "to" account.                             | varchar                     |
| authorized\_account\_id | Account authorized to perform the NFT transfer.                                  | varchar                     |
| processed\_time         | Timestamp when the NFT transfer data was processed.                              | timestamp(3) with time zone |
| updated\_at             | Timestamp when the NFT transfer record was last updated.                         | timestamp(3) with time zone |
| ingested\_at            | Timestamp when the NFT transfer data was ingested into Dune.                     | timestamp(3) with time zone |

## Table Sample

<TableSample />


# NEAR Data
Source: https://docs.dune.com/data-catalog/near/overview

NEAR blockchain data on Dune

## What is NEAR?

NEAR is a public, sharded, proof-of-stake blockchain designed to provide scalability, security, and user-friendliness for decentralized applications (dApps). With its unique account model, sharding mechanism, and developer-friendly environment, NEAR enables fast transactions at low costs while maintaining decentralization. It shares design goals with Ethereum 2.0 but includes optimizations for ease of use and performance.

NEAR’s sharding system, Nightshade, enables horizontal scaling, meaning the network’s capacity grows as the number of validators and nodes increases. This architecture, combined with a focus on developer tools and user experience, makes NEAR an ideal platform for building scalable Web3 applications.

## Key Concepts of NEAR

NEAR’s infrastructure is built on several key components that ensure its scalability, performance, and ease of use. These components work together to enable developers to build on-chain applications while providing a smooth experience for users.

### **Sharding with Nightshade**

Nightshade is NEAR’s solution to scaling the blockchain by splitting the network into multiple shards, each processing its own set of transactions. This sharding allows the blockchain to handle more transactions as the network grows, enabling high throughput and low-latency finality.

### **Proof-of-Stake Consensus**

NEAR uses a proof-of-stake consensus mechanism. Validators are chosen through an auction process based on the amount of NEAR tokens they stake. This system incentivizes honest behavior while ensuring decentralization, as anyone can become a validator if they meet the staking requirements.

### **NEAR Accounts and Access Keys**

NEAR introduces a human-readable [account system (e.g., `alice.near`)](https://docs.near.org/concepts/protocol/account-id) that simplifies interaction with the blockchain. Each account can have [multiple keys with different levels of access (Full-Access and Function-Call Keys)](https://docs.near.org/concepts/protocol/access-keys), allowing for more granular permission controls and better user experience. This flexibility makes it easier for developers to manage dApp permissions and onboard users.

### **Gas (Execution Fees)**

Gas is an essential part of NEAR's network, used to cover the cost of transactions and prevent network abuse. Each transaction or action executed on the NEAR blockchain requires gas, which is measured in gas units. The cost is based on network demand, and gas fees are paid in NEAR tokens. To learn more, [visit here.](https://docs.near.org/concepts/protocol/gas#gas-units--gas-price)

### **Transaction Lifecycle & Data Flow 🌊**

NEAR employs a unique transaction lifecycle where transactions are first validated on the sender’s shard, turned into receipts, and then processed on the receiver’s shard. This process ensures efficient transaction routing, even in cross-shard communication. After transaction execution, any remaining gas is refunded to the sender, ensuring efficient use of resources.

To understand how NEAR data flows, watch our [NEAR Data Flow video tutorial](/resources/learning/video-tutorials#near-data-flow) or visit the [NEAR documentation](https://docs.near.org/concepts/data-flow/near-data-flow).

### **Anatomy of a Transaction 🔎**

A transaction in NEAR consists of one or more actions that are signed by the sender’s account and executed by the network. These actions could include transferring tokens, invoking smart contracts, or staking.

#### Key Components of a Transaction

* **Signer**: The account that signs the transaction.
* **Receiver**: The account that will execute the actions.
* **Actions**: Operations like `FunctionCall`, `Transfer`, `DeployContract`, etc. A transaction can include multiple actions, but all are executed on the same receiver.
* **PublicKey**: The public key used to sign the transaction (so the network can verify the signature).
* **Nonce**: A number that is incremented for each transaction sent by the Signer.
* **BlockHash**: The hash of a recent block, to limit the time-validity of the transaction.

#### Types of Actions

* **FunctionCall**: Invoke a function on a contract (optionally attaching NEAR to the call).
* **Transfer**: Move NEAR tokens between accounts.
* **DeployContract**: Deploy a new contract to an account.
* **CreateAccount**: Create a new sub-account under an existing account.
* **DeleteAccount**: Remove an account and transfer its remaining balance to a beneficiary.
* **AddKey / DeleteKey**: Add or remove public keys associated with an account.
* **Stake**: Stake NEAR tokens to become a validator or delegate stake to one.
* **DelegateActions**: Execute a meta-transaction on behalf of another account.

<CardGroup>
  <Card title="NEAR documentation" icon="link" href="https://docs.near.org/">
    Explore comprehensive documentation on NEAR, detailing its architecture, protocol, and resources for developers.
  </Card>
</CardGroup>

## NEAR Data on Dune

NEAR blockchain data is partitioned and categorized to provide developers and users with an easily accessible dataset to interact with and analyze the network’s on-chain activity. The primary data tables in Dune for NEAR include the following:

<CardGroup>
  <Card title="Actions" icon="message-arrow-up" href="/data-catalog/near/actions">
    Records actions such as transfers, contract deployments, and function calls performed within the NEAR network.
  </Card>

  <Card title="Block Chunks" icon="cube" href="/data-catalog/near/block_chunks">
    Stores chunk-level data, with each block consisting of multiple chunks from different shards.
  </Card>

  <Card title="Circulating Supply" icon="money-bill" href="/data-catalog/near/circulating_supply">
    Table holding daily circulating and total supply of tokens in NEAR.
  </Card>

  <Card title="FT Transfers" icon="swap" href="/data-catalog/near/ft_transfers">
    Tracks fungible token (FT) transfers across the NEAR network.
  </Card>

  <Card title="Function Calls" icon="file" href="/data-catalog/near/function_call">
    Contains flattened out actions of the  `function_call` type.
  </Card>

  <Card title="NFT Transfers" icon="right-left-large" href="/data-catalog/near/nft_transfers">
    Captures non-fungible token (NFT) transfers, including token ID and sender/receiver details.
  </Card>

  <Card title="Balances" icon="notebook" href="/data-catalog/near/balances">
    Stores account balance data, including liquid, staked, and locked balances.
  </Card>

  <Card title="Logs" icon="bolt" href="/data-catalog/near/logs">
    This table captures the output generated during the execution of smart contracts.
  </Card>
</CardGroup>


# Block Events
Source: https://docs.dune.com/data-catalog/noble/block_events

Noble blockchain block events data

# Table Description

This table contains data about block-level events and attributes in the Noble blockchain, including event types, sources, and associated metadata. The schema is modeled after Sei's Cosmos block events but adapted for Noble's context.

## Column Descriptions

| Column name          | Data Type                   | Description                                          |
| -------------------- | --------------------------- | ---------------------------------------------------- |
| **block\_date**      | date                        | The date of the block.                               |
| **block\_height**    | bigint                      | The height of the block where the event occurred.    |
| **block\_timestamp** | timestamp(3) with time zone | Timestamp when the block was validated.              |
| **chain\_id**        | varchar                     | The ID of the chain where the block belongs.         |
| **event\_index**     | bigint                      | A unique index for events within the block.          |
| **event\_type**      | varchar                     | The type of event that was triggered.                |
| **event\_source**    | varchar                     | The source of the event.                             |
| **attribute\_key**   | varchar                     | The key of the event attribute.                      |
| **attribute\_value** | varchar                     | The value of the event attribute.                    |
| **attribute\_index** | bigint                      | A unique index for attributes within the event.      |
| **updated\_at**      | timestamp(3) with time zone | Timestamp of when the record was last updated.       |
| **ingested\_at**     | timestamp(3) with time zone | Timestamp of when the record was ingested into Dune. |

## Table Sample

<TableSample />


# Blocks
Source: https://docs.dune.com/data-catalog/noble/blocks

Noble blockchain blocks data

# Table Description

This table contains data about blocks in the Noble blockchain, including block headers, consensus data, and transaction information.

## Column Descriptions

| Column name           | Data Type                   | Description                                                  |
| --------------------- | --------------------------- | ------------------------------------------------------------ |
| **block\_date**       | date                        | The date of the block.                                       |
| **block\_height**     | bigint                      | The height of the block, a unique identifier for each block. |
| **block\_timestamp**  | timestamp(3) with time zone | Timestamp when the block was validated.                      |
| **chain\_id**         | varchar                     | The ID of the chain where the block belongs.                 |
| **proposer\_address** | varchar                     | The address of the validator proposing the block.            |
| **validators\_hash**  | varchar                     | The hash of the validators set for the block.                |
| **updated\_at**       | timestamp(3) with time zone | Timestamp of when the record was last updated.               |
| **ingested\_at**      | timestamp(3) with time zone | Timestamp of when the record was ingested into Dune.         |

## Table Sample

<TableSample />


# Bridge Transfers
Source: https://docs.dune.com/data-catalog/noble/bridge_transfers

Noble blockchain cross-chain bridge transfer data

# Table Description

This table contains data about cross-chain bridge transfers in the Noble blockchain, including transfer details, source and destination chains, and transfer status.

## Column Descriptions

| Column name            | Data Type                   | Description                                          |
| ---------------------- | --------------------------- | ---------------------------------------------------- |
| **block\_date**        | date                        | The date of the block.                               |
| **block\_height**      | bigint                      | The height of the block where the transfer occurred. |
| **block\_timestamp**   | timestamp(3) with time zone | Timestamp when the block was validated.              |
| **tx\_id**             | varchar                     | The unique ID of the transaction.                    |
| **tx\_index**          | bigint                      | The index of the transaction in the block.           |
| **message\_index**     | bigint                      | The index of the message in the transaction.         |
| **event\_index**       | bigint                      | The index of the event in the message.               |
| **action\_index**      | bigint                      | The index of the action in the event.                |
| **sender**             | varchar                     | The address of the sender.                           |
| **receiver**           | varchar                     | The address of the receiver.                         |
| **token\_amount**      | decimal(38, 0)              | The amount of tokens transferred.                    |
| **token\_denom**       | varchar                     | The denomination of the token.                       |
| **src\_domain**        | varchar                     | The source domain of the transfer.                   |
| **dst\_domain**        | varchar                     | The destination domain of the transfer.              |
| **protocol**           | varchar                     | The protocol used for the transfer.                  |
| **protocol\_metadata** | varchar                     | Additional metadata related to the protocol.         |
| **updated\_at**        | timestamp(3) with time zone | Timestamp of when the record was last updated.       |
| **ingested\_at**       | timestamp(3) with time zone | Timestamp of when the record was ingested into Dune. |

## Table Sample

<TableSample />


# CCTP Transactions
Source: https://docs.dune.com/data-catalog/noble/cctp_transactions

Noble blockchain Cross-Chain Transfer Protocol transactions data

# Table Description

This table contains data about Cross-Chain Transfer Protocol (CCTP) transactions in the Noble blockchain, including token transfers, source and destination chains, and transfer status.

## Column Descriptions

| Column name            | Data Type                   | Description                                             |
| ---------------------- | --------------------------- | ------------------------------------------------------- |
| **block\_date**        | date                        | The date of the block.                                  |
| **block\_height**      | bigint                      | The height of the block where the transaction occurred. |
| **block\_timestamp**   | timestamp(3) with time zone | Timestamp when the block was validated.                 |
| **tx\_id**             | varchar                     | The unique ID of the transaction.                       |
| **tx\_index**          | bigint                      | The index of the transaction in the block.              |
| **message\_index**     | bigint                      | The index of the message in the transaction.            |
| **event\_index**       | bigint                      | The index of the event in the message.                  |
| **action\_index**      | bigint                      | The index of the action in the event.                   |
| **sender**             | varchar                     | The address of the sender.                              |
| **receiver**           | varchar                     | The address of the receiver.                            |
| **token\_amount**      | decimal(38, 0)              | The amount of tokens transferred.                       |
| **token\_denom**       | varchar                     | The denomination of the token.                          |
| **src\_domain**        | varchar                     | The source domain of the transaction.                   |
| **dst\_domain**        | varchar                     | The destination domain of the transaction.              |
| **authorized\_caller** | varchar                     | The address of the authorized caller.                   |
| **contract**           | varchar                     | The contract address involved in the transaction.       |
| **nonce**              | varchar                     | The nonce associated with the transaction.              |
| **updated\_at**        | timestamp(3) with time zone | Timestamp of when the record was last updated.          |
| **ingested\_at**       | timestamp(3) with time zone | Timestamp of when the record was ingested into Dune.    |

## Table Sample

<TableSample />


# Message Events
Source: https://docs.dune.com/data-catalog/noble/message_events

Noble blockchain message events data

# Table Description

This table contains data about message-related events in the Noble blockchain, including message types, attributes, and associated metadata.

## Table Schema

| Column name          | Description                                           | Type                        |
| -------------------- | ----------------------------------------------------- | --------------------------- |
| **block\_date**      | The date of the block.                                | date                        |
| **block\_height**    | The height of the block where the event occurred.     | bigint                      |
| **block\_timestamp** | Timestamp when the block was validated.               | timestamp(3) with time zone |
| **chain\_id**        | The ID of the chain where the block belongs.          | varchar                     |
| **tx\_id**           | The hash of the transaction where the event occurred. | varchar                     |
| **tx\_index**        | The index of the transaction in the block.            | bigint                      |
| **message\_index**   | The index of the message in the transaction.          | bigint                      |
| **event\_index**     | A unique index for events within the message.         | bigint                      |
| **event\_type**      | The type of event that was triggered.                 | varchar                     |
| **attribute\_key**   | The key of the event attribute.                       | varchar                     |
| **attribute\_value** | The value of the event attribute.                     | varchar                     |
| **attribute\_index** | A unique index for attributes within the event.       | bigint                      |
| **updated\_at**      | Timestamp of when the record was last updated.        | timestamp(3) with time zone |
| **ingested\_at**     | Timestamp of when the record was ingested into Dune.  | timestamp(3) with time zone |

## Table Sample

<TableSample />


# Noble Data
Source: https://docs.dune.com/data-catalog/noble/overview

Noble blockchain data on Dune

## What is Noble?

Noble is a Cosmos application-specific blockchain purpose-built for native asset issuance. It brings the efficiency and interoperability of native assets to the wider Cosmos ecosystem, starting with USDC. Noble's vision is to be the world's premier issuance hub for digital assets that connect to other blockchains seamlessly.

## Key Features

* **Native Asset Issuance**: Purpose-built for efficient and secure token issuance
* **Cosmos Integration**: Built on Cosmos-SDK for seamless interoperability
* **Smart Contract Capabilities**: Industry-standard asset issuance functionality
* **IBC Compatibility**: Permissionless connection to other Cosmos chains
* **Proof of Authority**: Currently uses a trusted validator set with economic security

## Noble Data on Dune

Noble blockchain data is organized into several key tables that capture different aspects of on-chain activity:

<CardGroup>
  <Card title="Blocks" icon="cube" href="/data-catalog/noble/blocks">
    <p>Contains each validated block in the chain</p>
  </Card>

  <Card title="Block Events" icon="bolt" href="/data-catalog/noble/block_events">
    <p>Contains all block-level events and attributes in the chain, partitioned by event\_index</p>
  </Card>

  <Card title="Bridge Transfers" icon="bridge" href="/data-catalog/noble/bridge_transfers">
    <p>Cross-chain bridge transfer data</p>
  </Card>

  <Card title="CCTP Transactions" icon="bridge" href="/data-catalog/noble/cctp_transactions">
    <p>Cross-Chain Transfer Protocol transactions</p>
  </Card>

  <Card title="Message Events" icon="message" href="/data-catalog/noble/message_events">
    <p>Contains all events and their corresponding attributes partitioned by message\_index</p>
  </Card>

  <Card title="Swaps" icon="arrows-rotate" href="/data-catalog/noble/swaps">
    <p>Token swap and liquidity pool data</p>
  </Card>

  <Card title="Transactions" icon="arrow-right-arrow-left" href="/data-catalog/noble/transactions">
    <p>Contains relevant data associated with each transaction</p>
  </Card>

  <Card title="Transaction Messages" icon="envelope" href="/data-catalog/noble/tx_messages">
    <p>Contains all messages submitted to the blockchain</p>
  </Card>

  <Card title="Validators" icon="shield" href="/data-catalog/noble/validators">
    <p>Maps validator addresses to monikers (human-readable description) and other metadata</p>
  </Card>
</CardGroup>


# Swaps
Source: https://docs.dune.com/data-catalog/noble/swaps

Noble blockchain token swap transactions data

# Table Description

This table contains data about token swap transactions in the Noble blockchain, including swap details, token pairs, and execution status.

## Column Descriptions

| Column name            | Data Type                   | Description                                          |
| ---------------------- | --------------------------- | ---------------------------------------------------- |
| **block\_date**        | date                        | The date of the block.                               |
| **block\_height**      | bigint                      | The height of the block where the swap occurred.     |
| **block\_timestamp**   | timestamp(3) with time zone | Timestamp when the block was validated.              |
| **tx\_id**             | varchar                     | The unique ID of the transaction.                    |
| **tx\_index**          | bigint                      | The index of the transaction in the block.           |
| **message\_index**     | bigint                      | The index of the message in the transaction.         |
| **event\_index**       | bigint                      | The index of the event in the message.               |
| **action\_index**      | bigint                      | The index of the action in the event.                |
| **sender**             | varchar                     | The address of the sender.                           |
| **token\_amount\_in**  | decimal(38, 0)              | The amount of tokens swapped in.                     |
| **token\_denom\_in**   | varchar                     | The denomination of the token swapped in.            |
| **token\_amount\_out** | decimal(38, 0)              | The amount of tokens swapped out.                    |
| **token\_denom\_out**  | varchar                     | The denomination of the token swapped out.           |
| **routes**             | varchar                     | The routes used for the swap.                        |
| **fees**               | varchar                     | The fees associated with the swap.                   |
| **updated\_at**        | timestamp(3) with time zone | Timestamp of when the record was last updated.       |
| **ingested\_at**       | timestamp(3) with time zone | Timestamp of when the record was ingested into Dune. |

## Table Sample

<TableSample />


# Transactions
Source: https://docs.dune.com/data-catalog/noble/transactions

Noble blockchain transactions data

# Table Description

This table contains data about transactions in the Noble blockchain, including transaction details, gas usage, and execution status.

## Column Descriptions

| Column name            | Data Type                   | Description                                             |
| ---------------------- | --------------------------- | ------------------------------------------------------- |
| **block\_height**      | bigint                      | The height of the block where the transaction occurred. |
| **chain\_id**          | varchar                     | The ID of the chain where the transaction occurred.     |
| **tx\_id**             | varchar                     | The unique ID of the transaction.                       |
| **tx\_info**           | varchar                     | Information related to the transaction.                 |
| **tx\_log\_message**   | varchar                     | The log message associated with the transaction.        |
| **memo**               | varchar                     | A memo associated with the transaction.                 |
| **fee**                | varchar                     | The fee associated with the transaction.                |
| **tx\_code**           | bigint                      | The result code of the transaction.                     |
| **tx\_index**          | bigint                      | The index of the transaction within the block.          |
| **gas\_used**          | bigint                      | The amount of gas used by the transaction.              |
| **gas\_wanted**        | bigint                      | The amount of gas requested by the transaction.         |
| **schema\_version**    | bigint                      | The schema version for the transaction data.            |
| **fee\_coins**         | varchar                     | The coins used to pay the transaction fee.              |
| **fee\_granter**       | varchar                     | The address granting the fee for the transaction.       |
| **fee\_payer**         | varchar                     | The address paying the fee for the transaction.         |
| **gas\_limit**         | bigint                      | The gas limit set for the transaction.                  |
| **single\_sign\_mode** | bigint                      | The signing mode for single-signature transactions.     |
| **multi\_sign\_json**  | varchar                     | JSON structure for multi-signature transactions.        |
| **timeout\_height**    | varchar                     | The timeout height set for the transaction.             |
| **updated\_at**        | timestamp(3) with time zone | Timestamp of when the record was last updated.          |
| **ingested\_at**       | timestamp(3) with time zone | Timestamp of when the record was ingested into Dune.    |

## Table Sample

<TableSample />


# Transaction Messages
Source: https://docs.dune.com/data-catalog/noble/tx_messages

Noble blockchain transaction messages data

# Table Description

This table contains data about messages contained within transactions in the Noble blockchain, including message types, content, and associated metadata.

<Tip>
  On execution, transactions from Cosmos emit data in two formats:

  * Messages (`noble.tx_messages`): These provide a high-level, readable summary of actions, such as "send money" or "execute contract." They are easier to understand and track transaction types.
  * Events (`noble.message_events`): These capture detailed, low-level changes at the chain level, including underlying blockchain modifications that may not always be directly related to state changes.
  * Use Messages for a general overview and Events when you need detailed insights. The two tables are complementary.
</Tip>

## Column Descriptions

| Column name          | Data Type                   | Description                                          |
| -------------------- | --------------------------- | ---------------------------------------------------- |
| **block\_date**      | date                        | The date of the block.                               |
| **block\_height**    | bigint                      | The height of the block where the message occurred.  |
| **block\_timestamp** | timestamp(3) with time zone | Timestamp when the block was validated.              |
| **chain\_id**        | varchar                     | The ID of the chain where the message belongs.       |
| **tx\_id**           | varchar                     | The hash of the transaction containing the message.  |
| **tx\_index**        | bigint                      | The index of the transaction in the block.           |
| **message\_index**   | bigint                      | The index of the message in the transaction.         |
| **message\_type**    | varchar                     | The type of message.                                 |
| **message**          | varchar                     | The value/content of the message.                    |
| **schema\_version**  | bigint                      | The version of the schema in provider database.      |
| **updated\_at**      | timestamp(3) with time zone | Timestamp of when the record was last updated.       |
| **ingested\_at**     | timestamp(3) with time zone | Timestamp of when the record was ingested into Dune. |

## Table Sample

<TableSample />


# Validators
Source: https://docs.dune.com/data-catalog/noble/validators

Noble blockchain validators data

# Table Description

This table contains data about validators in the Noble blockchain, including their performance metrics, voting power, and status.

## Column Descriptions

| Column name                       | Data Type                   | Description                                                        |
| --------------------------------- | --------------------------- | ------------------------------------------------------------------ |
| **operator\_address**             | varchar                     | The operator address of the validator.                             |
| **account\_address**              | varchar                     | The account address of the validator.                              |
| **consensus\_pubkey**             | varchar                     | The consensus public key of the validator.                         |
| **jailed**                        | boolean                     | Indicates whether the validator is jailed.                         |
| **status**                        | varchar                     | The status of the validator (e.g., active, inactive).              |
| **tokens**                        | varchar                     | The number of tokens held by the validator.                        |
| **moniker**                       | varchar                     | The moniker or name of the validator.                              |
| **identity**                      | varchar                     | The identity information of the validator.                         |
| **website**                       | varchar                     | The website of the validator.                                      |
| **security\_contact**             | varchar                     | The security contact information for the validator.                |
| **details**                       | varchar                     | Additional details about the validator.                            |
| **unbonding\_height**             | bigint                      | The block height at which the validator started unbonding.         |
| **unbonding\_time**               | varchar                     | The time when the validator will complete unbonding.               |
| **commission\_rate**              | double                      | The commission rate charged by the validator.                      |
| **commission\_max\_rate**         | double                      | The maximum commission rate allowed for the validator.             |
| **commission\_max\_change\_rate** | double                      | The maximum rate at which the validator can change its commission. |
| **commission\_update\_time**      | varchar                     | The time when the validator last updated its commission.           |
| **min\_self\_delegation**         | varchar                     | The minimum self-delegation required for the validator.            |
| **snapshot\_height**              | bigint                      | The block height at which the snapshot was taken.                  |
| **snapshot\_time**                | varchar                     | The time when the snapshot was taken.                              |
| **updated\_at**                   | timestamp(3) with time zone | Timestamp of when the record was last updated.                     |
| **ingested\_at**                  | timestamp(3) with time zone | Timestamp of when the record was ingested into Dune.               |

## Table Sample

<TableSample />


# Data Catalog
Source: https://docs.dune.com/data-catalog/overview

Explore Dune's comprehensive blockchain data catalog — raw, decoded, and curated datasets across 100+ blockchains, accessible via the web app, API, and Datashare.

## Everything Onchain, One Platform

Raw, decoded, and curated datasets across 100+ blockchains — all queryable from a single platform. Whether you're building analytics, powering applications, or feeding data pipelines, every dataset is accessible through the [Data Hub](https://dune.com), [Data API](/api-reference/overview/introduction), or [Datashare](/datashare/datashare).

<Info>
  **Access options:** [Data Hub](https://dune.com) · [Data API](/api-reference/overview/introduction) · [Datashare](/datashare/datashare)
</Info>

***

## How Our Data Is Organized

Dune's data catalog has three layers, each building on the one below:

| Layer       | What It Contains                                                      | Best For                                                              |
| ----------- | --------------------------------------------------------------------- | --------------------------------------------------------------------- |
| **Raw**     | Block, transaction, log, and trace data indexed directly from nodes   | Full chain history, custom analysis, building your own models         |
| **Decoded** | Smart contract events and function calls parsed using verified ABIs   | Protocol-specific analysis, contract interactions, event monitoring   |
| **Curated** | Cleaned, normalized datasets built and maintained by Dune's data team | Cross-chain analytics, market intelligence, production data pipelines |

Most enterprise use cases start with **curated data** — pre-built, validated datasets that work across chains without writing complex raw queries.

***

## Curated Datasets

Curated datasets are where Dune adds the most value. Built and maintained by Dune's data team, each dataset normalizes data from hundreds of protocols across dozens of chains into a single, consistent schema.

| Category                        | Dataset            | Description                                                            | Coverage                                   | Docs                                                        |
| ------------------------------- | ------------------ | ---------------------------------------------------------------------- | ------------------------------------------ | ----------------------------------------------------------- |
| **Trading & Markets**           | DEX Trades         | Trade execution data across decentralized exchanges                    | 50 EVM chains, Solana                      | [View →](/data-catalog/curated/dex-trades/overview)         |
|                                 | NFT Trades         | NFT marketplace trades, mints, and metadata                            | 12 chains (EVM + Solana)                   | [View →](/data-catalog/curated/nft-trades/overview)         |
|                                 | Prediction Markets | Polymarket and Kalshi market activity, positions, and pricing          | Polygon, Off-chain                         | [View →](/data-catalog/curated/prediction-markets/overview) |
| **Assets & Pricing**            | Token Transfers    | Fungible token transfer events across EVM and non-EVM ecosystems       | All EVM, Solana, Aptos, Stellar, Sui, XRPL | [View →](/data-catalog/curated/token-transfers/overview)    |
|                                 | Balances           | Current and historical token balances by address                       | 10+ EVM chains, Solana                     | [View →](/data-catalog/curated/balances/overview)           |
|                                 | Prices             | Token pricing at minute, hourly, and daily granularity                 | 70+ chains                                 | [View →](/data-catalog/curated/prices/overview)             |
|                                 | Token Metadata     | Token names, symbols, decimals, and contract addresses                 | All EVM, Solana                            | [View →](/data-catalog/curated/token-metadata/overview)     |
|                                 | Stablecoins        | Stablecoin transfers, balances, and activity classification            | 37 EVM, Solana, Tron                       | [View →](/data-catalog/curated/stablecoins/overview)        |
| **DeFi & Cross-Chain**          | CEX Flows          | Token flows to/from centralized exchanges with entity identification   | 29 chains                                  | [View →](/data-catalog/curated/cex-flows/overview)          |
|                                 | Bridges            | Cross-chain token transfers — deposits, withdrawals, and flows         | 41 EVM chains                              | [View →](/data-catalog/curated/bridges/overview)            |
|                                 | Lending            | Supply, borrow, flash loans, and liquidations across lending protocols | 15 EVM chains                              | [View →](/data-catalog/curated/lending/overview)            |
|                                 | Staking            | Ethereum beacon chain deposits, withdrawals, and entity identification | Ethereum                                   | [View →](/data-catalog/curated/staking/overview)            |
| **Identity, Costs & Utilities** | Labels             | Address attribution — exchanges, protocols, DAOs, entities             | Cross-chain                                | [View →](/data-catalog/curated/labels/overview)             |
|                                 | Gas & Fees         | Transaction-level fee data with L2 fee breakdowns                      | 55 EVM chains, Solana                      | [View →](/data-catalog/curated/gas-fees/overview)           |
|                                 | Rollup Economics   | L2 rollup profitability — revenue vs L1 posting costs                  | 10-25 rollups                              | [View →](/data-catalog/curated/rollup-economics/overview)   |
|                                 | Utilities          | Time-series scaffolding tables (days, hours, minutes)                  | Universal                                  | [View →](/data-catalog/curated/utilities/overview)          |

<Tip>
  Each dataset page includes example SQL queries for common workflows — from compliance monitoring and portfolio valuation to protocol benchmarking and market intelligence.
</Tip>

***

## Blockchain Coverage

Dune indexes raw, decoded, and curated data across 100+ blockchains. The table below shows exactly what's available for each chain, derived from documented data catalog pages.

| VM            | Chain         | Raw | Decoded | DEX | Transfers | Balances | Prices | CEX | NFT | Labels | Bridges | Gas | Stablecoins |
| ------------- | ------------- | :-: | :-----: | :-: | :-------: | :------: | :----: | :-: | :-: | :----: | :-----: | :-: | :---------: |
| **SVM**       | Solana        |  ✅  |  ✅ IDL  |  ✅  |     ✅     |     ✅    |    ✅   |  ✅  |  ✅  |    ✅   |    ❌    |  ✅  |      ✅      |
| **EVM**       | Abstract      |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ❌  |  ✅  |    ✅   |    ✅    |  ✅  |      ✅      |
| **EVM**       | ApeChain      |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ❌  |  ✅  |    ✅   |    ✅    |  ✅  |      ❌      |
| **EVM**       | Arbitrum      |  ✅  |    ✅    |  ✅  |     ✅     |     ✅    |    ✅   |  ✅  |  ✅  |    ✅   |    ✅    |  ✅  |      ✅      |
| **EVM**       | Arbitrum Nova |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ✅  |  ✅  |    ✅   |    ✅    |  ✅  |      ❌      |
| **EVM**       | Avalanche     |  ✅  |    ✅    |  ✅  |     ✅     |     ✅    |    ✅   |  ✅  |  ✅  |    ✅   |    ✅    |  ✅  |      ✅      |
| **EVM**       | B3            |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ❌  |  ✅  |    ✅   |    ❌    |  ✅  |      ❌      |
| **EVM**       | Base          |  ✅  |    ✅    |  ✅  |     ✅     |     ✅    |    ✅   |  ✅  |  ✅  |    ✅   |    ✅    |  ✅  |      ✅      |
| **EVM**       | Beacon        |  ✅  |    ❌    |  ❌  |     ❌     |     ❌    |    ❌   |  ❌  |  ❌  |    ❌   |    ❌    |  ❌  |      ❌      |
| **EVM**       | Berachain     |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ✅  |  ✅  |    ✅   |    ✅    |  ✅  |      ✅      |
| **EVM**       | Blast         |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ❌  |  ✅  |    ✅   |    ✅    |  ✅  |      ✅      |
| **EVM**       | BNB           |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ✅  |  ✅  |    ✅   |    ✅    |  ✅  |      ✅      |
| **EVM**       | BOB           |  ✅  |    ❌    |  ❌  |     ✅     |     ❌    |    ✅   |  ❌  |  ❌  |    ✅   |    ✅    |  ✅  |      ❌      |
| **EVM**       | Boba          |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ❌  |  ✅  |    ✅   |    ✅    |  ✅  |      ❌      |
| **EVM**       | Celo          |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ✅  |  ✅  |    ✅   |    ✅    |  ✅  |      ✅      |
| **EVM**       | Corn          |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ❌  |  ✅  |    ✅   |    ✅    |  ✅  |      ❌      |
| **EVM**       | Degen         |  ✅  |    ❌    |  ❌  |     ✅     |     ❌    |    ✅   |  ❌  |  ❌  |    ✅   |    ❌    |  ✅  |      ❌      |
| **EVM**       | Ethereum      |  ✅  |    ✅    |  ✅  |     ✅     |     ✅    |    ✅   |  ✅  |  ✅  |    ✅   |    ✅    |  ✅  |      ✅      |
| **EVM**       | Fantom        |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ✅  |  ✅  |    ✅   |    ✅    |  ✅  |      ✅      |
| **EVM**       | Flare         |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ❌  |  ✅  |    ✅   |    ✅    |  ✅  |      ❌      |
| **EVM**       | Gnosis        |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ✅  |  ✅  |    ✅   |    ✅    |  ✅  |      ✅      |
| **EVM**       | Hemi          |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ❌  |  ❌  |    ✅   |    ❌    |  ✅  |      ❌      |
| **EVM**       | Henesys       |  ✅  |    ✅    |  ❌  |     ✅     |     ❌    |    ✅   |  ❌  |  ❌  |    ✅   |    ❌    |  ✅  |      ❌      |
| **EVM**       | HyperEVM      |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ❌  |  ❌  |    ✅   |    ✅    |  ✅  |      ❌      |
| **EVM**       | Ink           |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ✅  |  ✅  |    ✅   |    ✅    |  ✅  |      ✅      |
| **EVM**       | KAIA          |  ✅  |    ✅    |  ✅  |     ✅     |     ✅    |    ✅   |  ✅  |  ✅  |    ✅   |    ✅    |  ✅  |      ❌      |
| **EVM**       | Katana        |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ✅  |  ❌  |    ✅   |    ✅    |  ✅  |      ❌      |
| **EVM**       | Lens          |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ❌  |  ✅  |    ✅   |    ✅    |  ✅  |      ❌      |
| **EVM**       | Linea         |  ✅  |    ✅    |  ✅  |     ✅     |     ✅    |    ✅   |  ✅  |  ✅  |    ✅   |    ✅    |  ✅  |      ✅      |
| **EVM**       | Mantle        |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ✅  |  ✅  |    ✅   |    ✅    |  ✅  |      ✅      |
| **EVM**       | MegaETH       |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ❌  |  ❌  |    ✅   |    ❌    |  ✅  |      ❌      |
| **EVM**       | Mezo          |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ❌  |  ❌  |    ✅   |    ❌    |  ✅  |      ❌      |
| **EVM**       | Monad         |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ❌  |  ❌  |    ✅   |    ❌    |  ✅  |      ❌      |
| **EVM**       | Monad Testnet |  ✅  |    ✅    |  ❌  |     ✅     |     ❌    |    ✅   |  ❌  |  ❌  |    ✅   |    ❌    |  ❌  |      ❌      |
| **EVM**       | opBNB         |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ✅  |  ✅  |    ✅   |    ✅    |  ✅  |      ❌      |
| **EVM**       | Optimism      |  ✅  |    ✅    |  ✅  |     ✅     |     ✅    |    ✅   |  ✅  |  ✅  |    ✅   |    ✅    |  ✅  |      ✅      |
| **EVM**       | Peaq EVM      |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ❌  |  ❌  |    ✅   |    ❌    |  ✅  |      ❌      |
| **EVM**       | Plasma        |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ❌  |  ❌  |    ✅   |    ✅    |  ✅  |      ❌      |
| **EVM**       | Plume         |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ❌  |  ❌  |    ✅   |    ✅    |  ✅  |      ❌      |
| **EVM**       | Polygon       |  ✅  |    ✅    |  ✅  |     ✅     |     ✅    |    ✅   |  ✅  |  ✅  |    ✅   |    ✅    |  ✅  |      ✅      |
| **EVM**       | Polygon zkEVM |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ✅  |  ✅  |    ✅   |    ✅    |  ✅  |      ❌      |
| **EVM**       | RISE          |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ❌  |  ✅  |    ❌   |    ❌    |  ✅  |      ❌      |
| **EVM**       | Ronin         |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ❌  |  ✅  |    ✅   |    ✅    |  ✅  |      ❌      |
| **EVM**       | Scroll        |  ✅  |    ✅    |  ✅  |     ✅     |     ✅    |    ✅   |  ✅  |  ✅  |    ✅   |    ✅    |  ✅  |      ✅      |
| **EVM**       | Sei           |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ✅  |  ✅  |    ✅   |    ✅    |  ✅  |      ❌      |
| **EVM**       | Sepolia       |  ✅  |    ✅    |  ❌  |     ❌     |     ❌    |    ❌   |  ❌  |  ❌  |    ❌   |    ❌    |  ❌  |      ❌      |
| **EVM**       | Shape         |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ❌  |  ✅  |    ✅   |    ❌    |  ✅  |      ❌      |
| **EVM**       | Sonic         |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ❌  |  ✅  |    ✅   |    ✅    |  ✅  |      ❌      |
| **EVM**       | Somnia        |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ❌  |  ❌  |    ✅   |    ❌    |  ✅  |      ❌      |
| **EVM**       | Sophon        |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ❌  |  ✅  |    ✅   |    ✅    |  ✅  |      ❌      |
| **EVM**       | Story         |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ❌  |  ❌  |    ✅   |    ✅    |  ✅  |      ❌      |
| **EVM**       | Superseed     |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ❌  |  ❌  |    ✅   |    ❌    |  ✅  |      ❌      |
| **EVM**       | Tac           |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ❌  |  ❌  |    ✅   |    ❌    |  ✅  |      ❌      |
| **EVM**       | Taiko         |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ❌  |  ❌  |    ✅   |    ✅    |  ✅  |      ❌      |
| **EVM**       | Tezos EVM     |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ❌  |  ✅  |    ❌   |    ❌    |  ✅  |      ❌      |
| **EVM**       | Tron          |  ✅  |    ✅    |  ❌  |     ✅     |     ❌    |    ✅   |  ✅  |  ❌  |    ✅   |    ❌    |  ✅  |      ✅      |
| **EVM**       | Unichain      |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ✅  |  ✅  |    ✅   |    ✅    |  ✅  |      ✅      |
| **EVM**       | Viction       |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ❌  |  ✅  |    ✅   |    ❌    |  ❌  |      ❌      |
| **EVM**       | World Chain   |  ✅  |    ✅    |  ✅  |     ✅     |     ✅    |    ✅   |  ✅  |  ✅  |    ✅   |    ✅    |  ✅  |      ✅      |
| **EVM**       | X Layer       |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ❌  |  ❌  |    ✅   |    ❌    |  ✅  |      ❌      |
| **EVM**       | zkSync        |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ✅  |  ✅  |    ✅   |    ✅    |  ✅  |      ✅      |
| **EVM**       | Zora          |  ✅  |    ✅    |  ✅  |     ✅     |     ❌    |    ✅   |  ✅  |  ✅  |    ✅   |    ✅    |  ✅  |      ❌      |
| **Move**      | Aptos         |  ✅  |    ❌    |  ❌  |     ✅     |     ❌    |    ✅   |  ✅  |  ❌  |    ✅   |    ❌    |  ❌  |      ❌      |
| **Move**      | Sui           |  ✅  |    ❌    |  ❌  |     ✅     |     ❌    |    ✅   |  ✅  |  ❌  |    ❌   |    ❌    |  ❌  |      ❌      |
| **Bitcoin**   | Bitcoin       |  ✅  |    ❌    |  ❌  |     ❌     |     ❌    |    ✅   |  ✅  |  ❌  |    ✅   |    ❌    |  ❌  |      ❌      |
| **Substrate** | Polkadot      |  ✅  |    ❌    |  ❌  |     ✅     |     ✅    |    ❌   |  ❌  |  ❌  |    ❌   |    ❌    |  ❌  |      ❌      |
| **Substrate** | Peaq          |  ✅  |    ❌    |  ❌  |     ✅     |     ✅    |    ❌   |  ❌  |  ❌  |    ❌   |    ❌    |  ❌  |      ❌      |
| **StarkVM**   | Starknet      |  ✅  |    ❌    |  ❌  |     ❌     |     ❌    |    ✅   |  ❌  |  ❌  |    ❌   |    ❌    |  ❌  |      ❌      |
| **Other**     | Echelon       |  ✅  |    ❌    |  ❌  |     ❌     |     ❌    |    ❌   |  ❌  |  ❌  |    ❌   |    ❌    |  ❌  |      ❌      |
| **Other**     | Flow          |  ✅  |    ✅    |  ✅  |     ❌     |     ❌    |    ❌   |  ❌  |  ❌  |    ❌   |    ❌    |  ❌  |      ❌      |
| **Other**     | Fuel          |  ✅  |    ❌    |  ❌  |     ❌     |     ❌    |    ❌   |  ❌  |  ❌  |    ❌   |    ❌    |  ❌  |      ❌      |
| **Other**     | Initia        |  ✅  |    ❌    |  ❌  |     ❌     |     ❌    |    ❌   |  ❌  |  ❌  |    ❌   |    ❌    |  ❌  |      ❌      |
| **Other**     | NEAR          |  ✅  |    ❌    |  ❌  |     ✅     |     ✅    |    ❌   |  ❌  |  ✅  |    ❌   |    ❌    |  ❌  |      ❌      |
| **Other**     | Noble         |  ✅  |    ❌    |  ❌  |     ❌     |     ❌    |    ❌   |  ❌  |  ❌  |    ❌   |    ❌    |  ❌  |      ❌      |
| **Other**     | Stellar       |  ✅  |    ❌    |  ✅  |     ✅     |     ❌    |    ✅   |  ❌  |  ❌  |    ❌   |    ❌    |  ❌  |      ❌      |
| **Other**     | THORChain     |  ✅  |    ❌    |  ❌  |     ❌     |     ❌    |    ❌   |  ❌  |  ❌  |    ❌   |    ❌    |  ❌  |      ❌      |
| **Other**     | TON           |  ✅  |    ❌    |  ✅  |     ✅     |     ❌    |    ✅   |  ❌  |  ✅  |    ❌   |    ❌    |  ❌  |      ❌      |
| **Other**     | XRPL          |  ✅  |    ❌    |  ❌  |     ✅     |     ❌    |    ✅   |  ❌  |  ❌  |    ❌   |    ❌    |  ❌  |      ❌      |
| **Other**     | Yominet       |  ✅  |    ❌    |  ❌  |     ❌     |     ❌    |    ❌   |  ❌  |  ❌  |    ❌   |    ❌    |  ❌  |      ❌      |

<Info>
  **Need a chain that's not listed?** We're always expanding coverage. [Talk to our team →](https://dune.com/enterprise)
</Info>

### Hyperliquid

Hyperliquid is a high-performance L1 built for onchain order book trading. Dune currently provides **market data** — real-time and historical order book, funding rates, and trading activity via `hyperliquid.market_data`.

Additional Hyperliquid L1 data is coming soon.

<CardGroup>
  <Card title="Hyperliquid Market Data" icon="chart-line" href="/data-catalog/community/hyperliquid/overview">
    Explore available Hyperliquid tables — order book snapshots, funding rates, and trade history.
  </Card>

  <Card title="Get Early Access" icon="rocket" href="https://dune.com/enterprise">
    Need more Hyperliquid data? Talk to our team about early access.
  </Card>
</CardGroup>

### Protocols

Protocol-level datasets provide specialized data beyond standard blockchain indexing:

| Protocol      | Description                                                      | Docs                                       |
| ------------- | ---------------------------------------------------------------- | ------------------------------------------ |
| **Kalshi**    | Prediction market data — event contracts, trades, and settlement | [View →](/data-catalog/kalshi/overview)    |
| **LayerZero** | Cross-chain messaging and bridging data                          | [View →](/data-catalog/layerzero/overview) |
| **Succinct**  | ZK proof generation and verification data                        | [View →](/data-catalog/succinct/overview)  |

***

## Custom & Raw Access

For teams that need to go beyond curated datasets — build your own models, query raw blockchain data, or bring your own data into Dune:

<CardGroup>
  <Card title="Raw Tables" icon="layer-group" href="/data-catalog/evm/ethereum/overview">
    Block, transaction, log, and trace data indexed directly from nodes across all supported chains — [EVM](/data-catalog/evm/ethereum/overview) and [Solana](/data-catalog/solana/overview).
  </Card>

  <Card title="Decoded Tables" icon="file-code" href="/data-catalog/evm/ethereum/decoded/overview">
    Smart contract events and function calls parsed using verified ABIs or IDLs — [EVM](/data-catalog/evm/ethereum/decoded/overview) and [Solana IDL](/data-catalog/solana/idl-tables).
  </Card>

  <Card title="Transform with dbt" icon="arrows-rotate" href="/api-reference/connectors/dbt/overview">
    Run production-grade dbt projects directly on Dune — build, test, and deploy transformation pipelines with full incremental model support.
  </Card>

  <Card title="Bring Your Data" icon="upload" href="/web-app/upload-data">
    Upload CSVs, connect external data sources, or push data via API to join with onchain data.
  </Card>
</CardGroup>

***

## Partner Data

Dune provides off-chain and specialized datasets from partner data providers that are critical to onchain analysis:

| Partner       | Description                                                           | Docs                                                 |
| ------------- | --------------------------------------------------------------------- | ---------------------------------------------------- |
| **Flashbots** | MEV bundle data, searcher activity, and block builder analytics       | [View →](/data-catalog/community/flashbots/overview) |
| **Farcaster** | Social graph data — casts, reactions, profiles, and channels          | [View →](/data-catalog/community/farcaster/overview) |
| **Lens**      | Decentralized social media — publications, profiles, and interactions | [View →](/data-catalog/community/lens/overview)      |
| **Reservoir** | NFT market data — orders, sales, and collection metadata              | [View →](/data-catalog/community/reservoir/overview) |
| **Snapshot**  | Governance data — proposals, votes, and DAO activity                  | [View →](/data-catalog/community/snapshot/overview)  |

***

## Dune Index

Standardized onchain metrics for benchmarking blockchain activity:

| Metric               | Description                                  | Docs                                             |
| -------------------- | -------------------------------------------- | ------------------------------------------------ |
| **Transaction Fees** | Gas fee trends and comparisons across chains | [View →](/data-catalog/dune-index/gas-fees)      |
| **Net Transfers**    | Token flow analysis across networks          | [View →](/data-catalog/dune-index/net-transfers) |
| **Transactions**     | Transaction volume and activity metrics      | [View →](/data-catalog/dune-index/transactions)  |

***

## Why Teams Choose Dune's Data

<CardGroup>
  <Card title="Enterprise-Grade Pipelines" icon="code">
    All curated datasets are built using industry-standard data engineering tooling — the same practices used by enterprise data teams worldwide.
  </Card>

  <Card title="Continuous Quality Checks" icon="shield-check">
    Automated data quality verification at every pipeline stage, from ingestion to curated output. [Learn more →](/data-catalog/data-quality)
  </Card>

  <Card title="Cross-Chain by Default" icon="arrows-cross">
    Every curated dataset spans dozens of chains with consistent schemas. No stitching required.
  </Card>

  <Card title="Transparent Methodology" icon="book-open">
    Every curated dataset documents how it's built, what design decisions were made, and what limitations exist.
  </Card>
</CardGroup>

***

## Data Trust & Freshness

Every dataset in the catalog is backed by Dune's [data quality framework](/data-catalog/data-quality) — continuous automated checks at every pipeline stage. Raw data typically arrives within minutes of on-chain finality. Curated datasets refresh hourly.

For real-time status, see [Data Freshness](/data-catalog/data-freshness) and [Status Page](https://status.dune.com/).

***

## Get Started

<CardGroup>
  <Card title="Query in the Data Hub" icon="chart-mixed" href="https://dune.com">
    Write SQL against any dataset in the catalog — no infrastructure needed.
  </Card>

  <Card title="Access via API" icon="code" href="/api-reference/overview/introduction">
    Programmatic access to query results, real-time data, and execution endpoints.
  </Card>

  <Card title="Datashare" icon="database" href="/datashare/datashare">
    Direct access to Dune's full data warehouse in your own Snowflake, BigQuery, or Databricks environment.
  </Card>

  <Card title="Enterprise" icon="building" href="https://dune.com/enterprise">
    Custom SLAs, dedicated support, and priority data requests.
  </Card>
</CardGroup>


# peaq.balances
Source: https://docs.dune.com/data-catalog/peaq/balances

Peaq account balances.

## Table description

The `peaq.balances` table tracks account balance snapshots on the Peaq network, capturing the state of user assets at specific timestamps. This table is partitioned by `year`, `month`, and `day` for efficient querying.

Each record includes balance information in both processed (double) and raw (string) formats, allowing for precise balance tracking. The table tracks multiple balance types including free balances, reserved balances, and various frozen balance states (misc\_frozen and frozen).

Accounts are identified using SS58 addresses (`address_ss58`) and public keys (`address_pubkey`), supporting both human-readable and binary address formats. The table also includes chain and asset metadata such as `symbol`, `chain_name`, `asset`, and `para_id` for multi-chain support.

## Column Descriptions

| **Column**            | **Description**                                                                   | **Type**  |
| --------------------- | --------------------------------------------------------------------------------- | --------- |
| **year**              | The year when the balance snapshot was taken, used for partitioning.              | int       |
| **month**             | The month when the balance snapshot was taken, used for partitioning.             | int       |
| **day**               | The day when the balance snapshot was taken, used for partitioning.               | int       |
| **ts**                | The timestamp when the balance snapshot was taken.                                | timestamp |
| **symbol**            | The symbol of the asset (e.g., "PEAQ").                                           | string    |
| **address\_ss58**     | The SS58-encoded address of the account in human-readable format.                 | string    |
| **address\_pubkey**   | The public key of the account in binary format.                                   | binary    |
| **id**                | The unique identifier for the balance record.                                     | string    |
| **chain\_name**       | The name of the chain where the balance exists.                                   | string    |
| **asset**             | The asset identifier or symbol.                                                   | string    |
| **para\_id**          | The parachain ID associated with the balance, if applicable.                      | long      |
| **free**              | The free balance available to the account, in processed format.                   | double    |
| **reserved**          | The reserved balance that is locked but still owned by the account.               | double    |
| **misc\_frozen**      | The miscellaneous frozen balance that cannot be used for certain operations.      | double    |
| **frozen**            | The total frozen balance that cannot be used.                                     | double    |
| **nonce**             | The account nonce, representing the number of transactions from this account.     | long      |
| **free\_raw**         | The free balance in raw string format, preserving full precision.                 | string    |
| **reserved\_raw**     | The reserved balance in raw string format, preserving full precision.             | string    |
| **misc\_frozen\_raw** | The miscellaneous frozen balance in raw string format, preserving full precision. | string    |
| **frozen\_raw**       | The frozen balance in raw string format, preserving full precision.               | string    |
| **flags\_raw**        | The raw flags associated with the account balance state.                          | string    |
| **\_updated\_at**     | The time when the balance record was last updated.                                | timestamp |
| **\_ingested\_at**    | The time when the balance data was ingested into the system.                      | timestamp |

## Table Sample

<TableSample />


# peaq.evm_blocks
Source: https://docs.dune.com/data-catalog/peaq/blocks

Peaq EVM-compatible block data.

## Table description

The `peaq.evm_blocks` table stores basic information about Peaq blocks, with one record per block, including the block hash and statistics on the number of extrinsics, events, and transfers contained in each block. This table is partitioned by `year`, `month`, and `day` for efficient querying.

Each block record includes metadata such as block number, specification version, relay chain block number, block hashes (hash, parent hash, state root, extrinsics root), block author information, and counts of various operations (extrinsics, events, transfers, traces).

## Column Descriptions

| **Column**               | **Description**                                                                    | **Type**  |
| ------------------------ | ---------------------------------------------------------------------------------- | --------- |
| **year**                 | The year when the block was created, used for partitioning.                        | int       |
| **month**                | The month when the block was created, used for partitioning.                       | int       |
| **day**                  | The day when the block was created, used for partitioning.                         | int       |
| **block\_time**          | The timestamp when the block was created.                                          | timestamp |
| **number**               | The block number (sequence number) of the block.                                   | long      |
| **spec\_version**        | The specification version of the runtime when this block was created.              | long      |
| **relay\_block\_number** | The block number of the relay chain block associated with this block.              | long      |
| **hash**                 | The hash of the current block, in binary format.                                   | binary    |
| **parent\_hash**         | The hash of the parent block, in binary format.                                    | binary    |
| **state\_root**          | The Merkle root of the state trie after applying all transactions in this block.   | binary    |
| **extrinsics\_root**     | The Merkle root of the extrinsics included in this block.                          | binary    |
| **author\_ss58**         | The SS58-encoded address of the block author (validator) in human-readable format. | string    |
| **author\_pub\_key**     | The public key of the block author (validator) in binary format.                   | binary    |
| **relay\_state\_root**   | The state root of the relay chain associated with this block.                      | binary    |
| **extrinsic\_count**     | The number of extrinsics (transactions) included in this block.                    | long      |
| **event\_count**         | The number of events emitted in this block.                                        | long      |
| **transfer\_count**      | The number of transfers executed in this block.                                    | long      |
| **trace\_count**         | The number of traces generated in this block.                                      | long      |
| **\_updated\_at**        | The time when the block record was last updated.                                   | timestamp |
| **\_ingested\_at**       | The time when the block data was ingested into the system.                         | timestamp |

## Table Sample

<TableSample />


# peaq.calls
Source: https://docs.dune.com/data-catalog/peaq/calls

Peaq dispatch calls — pallet function calls within extrinsics.

## Table description

Compared to the `extrinsics` table, which only has a top-level call, the `calls` table represents *internal* calls, including recursive internal calls of `proxy` and `utility` (batch) pallets, and provides detailed call arguments at each level of the call tree.

The `peaq.calls` table is partitioned by `year`, `month`, `call_section`, and `call_method` for efficient querying. Common queries on the `calls` table will typically filter on `block_time`, `call_section` and `call_method` and extract JSON encoded information from `call_args` or `call_args_def`.

Each call record includes information about the pallet section and method being called, the extrinsic it belongs to, call hierarchy (root/leaf), fee and weight information, signer details, and call arguments in both raw and decoded formats.

## Column Descriptions

| **Column**             | **Description**                                                                              | **Type**  |
| ---------------------- | -------------------------------------------------------------------------------------------- | --------- |
| **year**               | The year when the call was executed, used for partitioning.                                  | int       |
| **month**              | The month when the call was executed, used for partitioning.                                 | int       |
| **call\_section**      | The pallet section (module) where the call originates (e.g., "balances", "system").          | string    |
| **call\_method**       | The method name within the pallet section being called.                                      | string    |
| **block\_number**      | The block number where this call was executed.                                               | bigint    |
| **block\_time**        | The timestamp when the block containing this call was created.                               | timestamp |
| **extrinsic\_id**      | The unique identifier of the extrinsic that contains this call.                              | string    |
| **relay\_chain**       | The name of the relay chain associated with this call.                                       | string    |
| **para\_id**           | The parachain ID associated with this call, if applicable.                                   | long      |
| **id**                 | The unique identifier for the call record.                                                   | string    |
| **block\_hash**        | The hash of the block containing this call, in binary format.                                | binary    |
| **extrinsic\_hash**    | The hash of the extrinsic containing this call, in binary format.                            | binary    |
| **extrinsic\_section** | The pallet section of the top-level extrinsic.                                               | string    |
| **extrinsic\_method**  | The method name of the top-level extrinsic.                                                  | string    |
| **call\_id**           | The unique identifier for this specific call within the call tree.                           | string    |
| **call\_index**        | The index of this call within the call hierarchy, in binary format.                          | binary    |
| **call\_args**         | The raw call arguments in JSON format.                                                       | string    |
| **call\_args\_def**    | The decoded call arguments definition with type information.                                 | string    |
| **root**               | Indicates whether this is a root-level call (top of the call tree).                          | boolean   |
| **leaf**               | Indicates whether this is a leaf-level call (bottom of the call tree).                       | boolean   |
| **fee**                | The fee charged for executing this call, in processed format.                                | double    |
| **weight**             | The computational weight consumed by this call.                                              | long      |
| **signed**             | Indicates whether the extrinsic containing this call was signed.                             | boolean   |
| **signer\_ss58**       | The SS58-encoded address of the account that signed the extrinsic, in human-readable format. | string    |
| **signer\_pub\_key**   | The public key of the account that signed the extrinsic, in binary format.                   | binary    |
| **lifetime**           | The lifetime or validity period of the call, if applicable.                                  | string    |
| **\_updated\_at**      | The time when the call record was last updated.                                              | timestamp |
| **\_ingested\_at**     | The time when the call data was ingested into the system.                                    | timestamp |

## Table Sample

<TableSample />


# peaq.events
Source: https://docs.dune.com/data-catalog/peaq/events

Peaq runtime events — pallet-level events emitted during execution.

## Table description

The `peaq.events` table holds all events that occur on the Peaq chain, including their pallet `section` and `method`, as well as the decoded data involved in the event. This table is partitioned by `year`, `month`, `section`, and `method` for efficient querying.

Events are emitted by the runtime and pallets to signal state changes, transaction results, and other important occurrences on the chain. Each event record includes the pallet section and method that emitted it, the block and extrinsic it belongs to, and event data in both raw and decoded formats.

Common queries on the `events` table will typically filter on `block_time`, `section` and `method` and extract JSON encoded information from `data` or `data_decoded`.

## Column Descriptions

| **Column**          | **Description**                                                                  | **Type**  |
| ------------------- | -------------------------------------------------------------------------------- | --------- |
| **year**            | The year when the event was emitted, used for partitioning.                      | int       |
| **month**           | The month when the event was emitted, used for partitioning.                     | int       |
| **section**         | The pallet section (module) that emitted the event (e.g., "balances", "system"). | string    |
| **method**          | The method name within the pallet section that identifies the event type.        | string    |
| **block\_time**     | The timestamp when the block containing this event was created.                  | timestamp |
| **block\_number**   | The block number where this event was emitted.                                   | bigint    |
| **extrinsic\_id**   | The unique identifier of the extrinsic that triggered this event.                | string    |
| **event\_id**       | The unique identifier for the event record.                                      | string    |
| **data**            | The raw event data in JSON format.                                               | string    |
| **extrinsic\_hash** | The hash of the extrinsic that triggered this event, in binary format.           | binary    |
| **block\_hash**     | The hash of the block containing this event, in binary format.                   | binary    |
| **data\_decoded**   | The decoded event data with type information and human-readable values.          | string    |
| **\_updated\_at**   | The time when the event record was last updated.                                 | timestamp |
| **\_ingested\_at**  | The time when the event data was ingested into the system.                       | timestamp |

## Table Sample

<TableSample />


# peaq.extrinsics
Source: https://docs.dune.com/data-catalog/peaq/extrinsics

Peaq extrinsics — signed and unsigned transactions.

## Table description

Extrinsics (aka "transactions") normally contain a signature, some data to describe if the extrinsic has passed some validity checks and a reference to the pallet and call that it is intended for. Extrinsics may be signed or unsigned. Some extrinsics have a complex structure, e.g. when using proxy or utility pallets, resulting in the top-level call initiating other calls involving other pallets.

The `peaq.extrinsics` table is partitioned by `year`, `month`, `section`, and `method` for efficient querying. Common queries on the `extrinsics` table will typically filter on `block_time`, `section` and `method` and extract JSON encoded information from `params`. In many cases, an initial query on the `extrinsics` table is best developed on the calls table instead to properly capture how users often use proxy and utility constructs to interact with the Peaq chain.

Each extrinsic record includes the top-level call information (section and method), block and hash information, signer details, fee and weight, execution status, and call parameters.

## Column Descriptions

| **Column**           | **Description**                                                                              | **Type**  |
| -------------------- | -------------------------------------------------------------------------------------------- | --------- |
| **year**             | The year when the extrinsic was executed, used for partitioning.                             | int       |
| **month**            | The month when the extrinsic was executed, used for partitioning.                            | int       |
| **section**          | The pallet section (module) of the top-level call (e.g., "balances", "system").              | string    |
| **method**           | The method name of the top-level call within the pallet section.                             | string    |
| **block\_time**      | The timestamp when the block containing this extrinsic was created.                          | timestamp |
| **block\_number**    | The block number where this extrinsic was executed.                                          | long      |
| **extrinsic\_id**    | The unique identifier for the extrinsic record.                                              | string    |
| **hash**             | The hash of the extrinsic, in binary format.                                                 | binary    |
| **block\_hash**      | The hash of the block containing this extrinsic, in binary format.                           | binary    |
| **lifetime**         | The lifetime or validity period of the extrinsic, if applicable.                             | string    |
| **params**           | The call parameters in JSON format, containing the arguments passed to the call.             | string    |
| **fee**              | The fee charged for executing this extrinsic, in processed format.                           | double    |
| **weight**           | The computational weight consumed by this extrinsic.                                         | long      |
| **signed**           | Indicates whether the extrinsic was signed by an account.                                    | boolean   |
| **signer\_ss58**     | The SS58-encoded address of the account that signed the extrinsic, in human-readable format. | string    |
| **signer\_pub\_key** | The public key of the account that signed the extrinsic, in binary format.                   | binary    |
| **status**           | Indicates whether the extrinsic execution was successful.                                    | boolean   |
| **\_updated\_at**    | The time when the extrinsic record was last updated.                                         | timestamp |
| **\_ingested\_at**   | The time when the extrinsic data was ingested into the system.                               | timestamp |

## Table Sample

<TableSample />


# Peaq Overview
Source: https://docs.dune.com/data-catalog/peaq/overview

Peaq blockchain data on Dune

## What is Peaq?

Peaq is a layer-1 blockchain purpose-built and optimized to power the Machine Economy. The platform enables:

<CardGroup>
  <Card title="DePINs" icon="network-wired">
    Decentralized Physical Infrastructure Networks
  </Card>

  <Card title="DePAI" icon="chart-network">
    Decentralized Physical AI
  </Card>

  <Card title="Machine DeFi" icon="coin">
    Decentralized Finance based on machines' on-chain economic value and activity
  </Card>

  <Card title="Machine RWAs" icon="robot">
    Tokenized machines bringing real-world economic value on-chain
  </Card>
</CardGroup>

By leveraging parallelized block production, asynchronous backing, and agile core time, peaq currently handles up to 10,000 transactions per second (TPS). It is set to scale beyond 100,000 TPS after future upgrades, all while maintaining a minimum transaction cost of approximately \$0.00025. peaq leverages the world's environmentally-friendliest blockchain architecture and leverages one of the highest Nakamoto Coefficients in the industry to ensure censorship resistance.

peaq offers a comprehensive suite of ready-to-use Modular DePIN and DePAI Functions, granting builders and machines essential core functionalities to leverage for seamless deployment. These include self-sovereign machine IDs, role-based access control, data verification, universal machine time, seamless machine payment processing, data storage, data indexing, AI agents, and more. All functions are accessible via the peaq SDK, allowing developers to deploy them with just \~15 lines of code.

## Peaq Data on Dune

Peaq blockchain data is organized into several key tables that capture different aspects of on-chain activity:

<CardGroup>
  <Card title="Blocks" icon="cube" href="/data-catalog/peaq/blocks">
    Core block data including block headers, validators, and block statistics.
  </Card>

  <Card title="Extrinsics" icon="sitemap" href="/data-catalog/peaq/extrinsics">
    Detailed transaction data, encompassing both signed and unsigned operations, directly invoking pallet functions.
  </Card>

  <Card title="Events" icon="bolt" href="/data-catalog/peaq/events">
    All events emitted by the runtime, including system events, and events from all pallets.
  </Card>

  <Card title="Calls" icon="arrow-right" href="/data-catalog/peaq/calls">
    Comprehensive info on function calls, expanding top-level extrinsics with internal calls.
  </Card>

  <Card title="Transfers" icon="arrow-up-from-bracket" href="/data-catalog/peaq/transfers">
    Complete ledger of asset transfers across the network, capturing the movement of tokens between accounts.
  </Card>

  <Card title="Balances" icon="wallet" href="/data-catalog/peaq/balances">
    Daily snapshots capturing the state of user assets, reflecting the end-of-day balances.
  </Card>
</CardGroup>

<CardGroup>
  <Card title="Peaq Documentation" icon="link" href="https://docs.peaq.xyz/build/introduction">
    Official documentation for developers building on Peaq
  </Card>
</CardGroup>


# peaq.transfers
Source: https://docs.dune.com/data-catalog/peaq/transfers

Peaq native token transfers.

## Table description

The `peaq.transfers` table stores complete ledger of asset transfers across the Peaq network, capturing the movement of tokens between accounts. This table is partitioned by `year`, `month`, and `day` for efficient querying.

Each transfer record includes information about the sender and recipient (in both SS58 and public key formats), the asset being transferred, the amount in both processed (double) and raw (decimal) formats, and the event and extrinsic that triggered the transfer.

## Column Descriptions

| **Column**          | **Description**                                                              | **Type**      |
| ------------------- | ---------------------------------------------------------------------------- | ------------- |
| **year**            | The year when the transfer occurred, used for partitioning.                  | int           |
| **month**           | The month when the transfer occurred, used for partitioning.                 | int           |
| **day**             | The day when the transfer occurred, used for partitioning.                   | int           |
| **block\_time**     | The timestamp when the block containing this transfer was created.           | timestamp     |
| **block\_number**   | The block number where this transfer occurred.                               | long          |
| **event\_id**       | The unique identifier of the event that represents this transfer.            | string        |
| **extrinsic\_id**   | The unique identifier of the extrinsic that triggered this transfer.         | string        |
| **section**         | The pallet section (module) that emitted the transfer event.                 | string        |
| **method**          | The method name within the pallet section that identifies the transfer type. | string        |
| **extrinsic\_hash** | The hash of the extrinsic that triggered this transfer, in binary format.    | binary        |
| **block\_hash**     | The hash of the block containing this transfer, in binary format.            | binary        |
| **from\_ss58**      | The SS58-encoded address of the sender account, in human-readable format.    | string        |
| **from\_pub\_key**  | The public key of the sender account, in binary format.                      | binary        |
| **to\_ss58**        | The SS58-encoded address of the recipient account, in human-readable format. | string        |
| **to\_pub\_key**    | The public key of the recipient account, in binary format.                   | binary        |
| **asset**           | The asset identifier or address being transferred.                           | string        |
| **symbol**          | The symbol of the asset being transferred (e.g., "PEAQ").                    | string        |
| **decimals**        | The number of decimal places for the asset.                                  | long          |
| **amount**          | The transfer amount in processed format (double).                            | double        |
| **raw\_amount**     | The transfer amount in raw format, preserving full precision (decimal 38,9). | decimal(38,9) |
| **\_updated\_at**   | The time when the transfer record was last updated.                          | timestamp     |
| **\_ingested\_at**  | The time when the transfer data was ingested into the system.                | timestamp     |

## Table Sample

<TableSample />


# solana.account_activity
Source: https://docs.dune.com/data-catalog/solana/account-activity

Track every SOL and SPL token balance change per account per transaction — essential for wallet activity monitoring, treasury tracking, compliance auditing, and building real-time portfolio analytics on Solana.

## Table description

The `solana.account_activity` table contains information from the transactions table focused on account usage. Each row contains all information about an account's usage in a transaction.

## Table Schema

| Column                 | Type             | Description                                                                  |
| ---------------------- | ---------------- | ---------------------------------------------------------------------------- |
| `block_date`           | `DATE`           | The date of the block this account activity occurred in                      |
| `block_slot`           | `BIGINT`         | The slot number of the block containing this activity                        |
| `block_time`           | `TIMESTAMP`      | The timestamp of the block this activity belongs to                          |
| `address`              | `VARCHAR`        | The Solana account address involved in the transaction                       |
| `tx_index`             | `INTEGER`        | The index position of the transaction within the block                       |
| `token_mint_address`   | `VARCHAR`        | The mint address of the SPL token involved, null for native SOL transfers    |
| `tx_id`                | `VARCHAR`        | The unique transaction signature/ID                                          |
| `block_hash`           | `VARCHAR`        | The hash of the block containing this transaction                            |
| `tx_success`           | `BOOLEAN`        | Whether the transaction completed successfully                               |
| `signed`               | `BOOLEAN`        | Whether this account signed the transaction                                  |
| `writable`             | `BOOLEAN`        | Whether this account had write access in the transaction                     |
| `pre_balance`          | `BIGINT`         | The account's SOL balance (in lamports) before the transaction               |
| `post_balance`         | `BIGINT`         | The account's SOL balance (in lamports) after the transaction                |
| `balance_change`       | `BIGINT`         | The net change in SOL balance (in lamports) from this transaction            |
| `pre_token_balance`    | `DECIMAL(38,18)` | The account's SPL token balance before the transaction (decimal-adjusted)    |
| `post_token_balance`   | `DECIMAL(38,18)` | The account's SPL token balance after the transaction (decimal-adjusted)     |
| `token_balance_change` | `DECIMAL(38,17)` | The net change in SPL token balance from this transaction (decimal-adjusted) |
| `token_balance_owner`  | `VARCHAR`        | The owner address of the token account                                       |

## Table Sample

<TableSample />


# solana.blocks
Source: https://docs.dune.com/data-catalog/solana/blocks

Solana block-level data including slot numbers, leader identity, rewards, and transaction counts. Blocks contain transactions which contain instructions that alter the state of the Solana blockchain. Use this data for network throughput analysis, validator performance benchmarking, and infrastructure monitoring.

## Table description

The `solana.blocks` table contains the block data within Solana's blockchain. It can be used to identify block activity and transaction changes over time.

## Table Schema

| Column                             | Type        | Description                                                                  |
| ---------------------------------- | ----------- | ---------------------------------------------------------------------------- |
| `slot`                             | `BIGINT`    | The slot number of the block, used as the primary block identifier on Solana |
| `height`                           | `BIGINT`    | The block height (number of blocks since genesis)                            |
| `time`                             | `TIMESTAMP` | The timestamp when the block was produced                                    |
| `date`                             | `DATE`      | The date the block was produced                                              |
| `hash`                             | `VARCHAR`   | The unique hash of the block                                                 |
| `total_transactions`               | `INTEGER`   | Total number of transactions included in the block (vote + non-vote)         |
| `successful_transactions`          | `INTEGER`   | Number of transactions that completed successfully                           |
| `failed_transactions`              | `INTEGER`   | Number of transactions that failed                                           |
| `total_vote_transactions`          | `INTEGER`   | Total number of validator vote transactions in the block                     |
| `total_non_vote_transactions`      | `INTEGER`   | Total number of non-vote (user) transactions in the block                    |
| `successful_vote_transactions`     | `INTEGER`   | Number of vote transactions that succeeded                                   |
| `successful_non_vote_transactions` | `INTEGER`   | Number of non-vote transactions that succeeded                               |
| `failed_vote_transactions`         | `INTEGER`   | Number of vote transactions that failed                                      |
| `failed_non_vote_transactions`     | `INTEGER`   | Number of non-vote transactions that failed                                  |
| `parent_slot`                      | `BIGINT`    | The slot number of the parent block                                          |
| `previous_block_hash`              | `VARCHAR`   | The hash of the parent block                                                 |
| `num_reward_partitions`            | `BIGINT`    | The number of reward partitions in this block                                |

## Table Sample

<TableSample />


# Solana Decoded Tables
Source: https://docs.dune.com/data-catalog/solana/idl-tables

Decoded Solana program data using Interface Description Language (IDL) definitions — human-readable instruction and event data for DeFi protocols, NFT marketplaces, and any Solana program. The fastest path from raw bytes to actionable analytics.

<Note>
  **IDL Submissions**

  You can submit any program for decoding that has a public IDL or GitHub repo (Anchor, native, and system are supported), for example [Jupiter on Solscan](https://solscan.io/account/JUP4Fb2cqiRUcaTHdrPC8h2gNsA2ETXiPDD33WcGuJB#anchorProgramIDL). Use [dune.com/contracts/new](https://dune.com/contracts/new) and select Solana, or see [Solana program decoding submissions](/web-app/decoding/solana-decoding-submissions) for the full flow and IDL requirements.
</Note>

Decoded tables inherit all of the columns from [`instruction_calls`](/data-catalog/solana/instruction-calls), so you can refer there for most of the types. We only add columns for each argument in the function call `data` and each account that was required to be in `account_arguments`. **These only decode from instructions, and not inner instructions.**

## Example IDL Decoded Walkthrough

Using an IDL, we decode the function data arguments and the required account arguments. Let's look at an example using Whirlpool - normally you can find the IDL [on Solscan](https://solscan.io/account/whirLbMiicVdio4qvUfM5KAg6Ct8VwpYzGff3uctyCc#anchorProgramIDL), but this time we had to dig [into the project repo](https://github.com/orca-so/whirlpools/blob/main/sdk/src/artifacts/whirlpool.json). IDLs are like ABIs on Ethereum, except they are created from the [Anchor lang](https://www.anchor-lang.com/) project instead of natively from every program.

[Here's a transaction](https://solscan.io/tx/TGDKvM2E8mWYcsG2JBnb9axFcyEcKqs7yZLyayCmrV8p8SSdA8r9SLEC7EHQ4mcXQXpczEyaCBXvnmEi9yoKVJ9) of a pool (a trading pair) being initialized.

You can see that the instruction data is decoded in "Bumps", "TickSpacing", and "InitialSqrtPrice" on the explorer. We have the same thing in a SQL table! You can also see all the account names are labelled clearly as well with an `account_` prefix. Raw table inherited columns like `tx_id`, `block_time`, `tx_index` get a `call_` prefix.

The main thing to note is that we've exploded outer and inner instructions, where the index will match what you see on explorers. This example call is at the outer instruction level, so the inner instruction index is null. For Whirlpool swaps, often times it will happen in inner\_instructions so then the top level outer instruction is inherited into the `call_outer_instruction_index` and the inner index is `call_inner_instruction_index` (same idea with the `call_outer_executing_account` and `call_inner_executing_account`)

<div>
  <DuneEmbed />
</div>

Try it out for yourself in [this query](https://dune.com/queries/2352049/) below:

```sql theme={null}
SELECT * FROM whirlpool_solana.whirlpool_call_initializePool
WHERE call_tx_id = 'TGDKvM2E8mWYcsG2JBnb9axFcyEcKqs7yZLyayCmrV8p8SSdA8r9SLEC7EHQ4mcXQXpczEyaCBXvnmEi9yoKVJ9'
```

The table name follows the pattern:\
`<namespace>_solana.<programName>_call_<instructionName>`

We already have many of the top projects decoded, so go explore!


# solana.instruction_calls
Source: https://docs.dune.com/data-catalog/solana/instruction-calls

Every program instruction executed on Solana with decoded arguments, inner instruction traces, and execution context. Critical for protocol analytics, smart contract auditing, cross-program invocation analysis, and DeFi flow tracing.

## Table description

The `solana.instruction_calls` table is an unnested table of [`solana.transactions`](/data-catalog/solana/transactions). There can be multiple instructions in a transaction, so having an exploded view here will make it a little easier to work with the data. **This table mainly exists as the base for [Solana decoded tables](/data-catalog/solana/idl-tables), which you should be using instead.**

## Table Schema

| Column                    | Type                                                                                                         | Description                                                                              |
| ------------------------- | ------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------- |
| `block_slot`              | `BIGINT`                                                                                                     | The slot number of the block containing this instruction                                 |
| `block_date`              | `DATE`                                                                                                       | The date of the block this instruction was executed in                                   |
| `block_time`              | `TIMESTAMP`                                                                                                  | The timestamp of the block this instruction was executed in                              |
| `block_hash`              | `VARCHAR`                                                                                                    | The hash of the block containing this instruction                                        |
| `tx_index`                | `INTEGER`                                                                                                    | The index position of the parent transaction within the block                            |
| `inner_instruction_index` | `INTEGER`                                                                                                    | The index of this instruction among inner instructions (null for top-level instructions) |
| `outer_instruction_index` | `INTEGER`                                                                                                    | The index of the top-level instruction this belongs to                                   |
| `inner_executing_account` | `VARCHAR`                                                                                                    | The program account executing this inner instruction (null for top-level instructions)   |
| `outer_executing_account` | `VARCHAR`                                                                                                    | The program account executing the top-level instruction                                  |
| `executing_account`       | `VARCHAR`                                                                                                    | The program account that executed this specific instruction                              |
| `is_inner`                | `BOOLEAN`                                                                                                    | Whether this is an inner (CPI) instruction rather than a top-level instruction           |
| `stack_height`            | `BIGINT`                                                                                                     | The call stack depth of this instruction (1 for top-level, 2+ for inner)                 |
| `data`                    | `VARBINARY`                                                                                                  | The raw instruction data passed to the program                                           |
| `account_arguments`       | `ARRAY(VARCHAR)`                                                                                             | The list of account addresses passed as arguments to this instruction                    |
| `inner_instructions`      | `ARRAY(ROW(data VARCHAR, executing_account VARCHAR, account_arguments ARRAY(VARCHAR), stack_height BIGINT))` | Nested inner instructions triggered by this instruction via CPI                          |
| `tx_id`                   | `VARCHAR`                                                                                                    | The unique transaction signature/ID                                                      |
| `tx_signer`               | `VARCHAR`                                                                                                    | The address of the fee-paying signer of the transaction                                  |
| `tx_success`              | `BOOLEAN`                                                                                                    | Whether the parent transaction completed successfully                                    |
| `log_messages`            | `ARRAY(VARCHAR)`                                                                                             | Program log messages emitted during this instruction's execution                         |

## Table Sample

<TableSample />


# Solana Overview
Source: https://docs.dune.com/data-catalog/solana/overview

Solana raw and decoded data on Dune — transactions, blocks, instructions, account activity, rewards, and vote data for trading, compliance, wallet engineering, and research.

Dune indexes the full Solana blockchain — every transaction, block, instruction call, and account balance change. As a non-EVM chain, Solana's [account-based architecture](https://solana.com/docs/core/accounts) produces data that looks fundamentally different from Ethereum. Programs, accounts, and instructions replace contracts, addresses, and function calls.

Raw data tables give you direct access to transactions, pre/post-balances, and instruction data. For most analytical workflows, however, you'll get faster results and cleaner queries using [decoded data](/data-catalog/solana/idl-tables) from IDL decoding — Solana's equivalent of ABI decoding on EVM chains.

### Available Tables

<CardGroup>
  <Card title="Account Activity" icon="user-check" href="/data-catalog/solana/account-activity">
    Pre/post-balance changes for every account touched in a transaction — track wallet activity, treasury flows, and balance movements
  </Card>

  <Card title="Blocks" icon="cubes" href="/data-catalog/solana/blocks">
    Slot-level block data including leader identity, rewards, and timing — analyze network throughput and validator performance
  </Card>

  <Card title="IDL Tables (Decoded)" icon="code" href="/data-catalog/solana/idl-tables">
    Human-readable decoded program data from IDL definitions — the fastest path to protocol-specific analytics
  </Card>

  <Card title="Instruction Calls" icon="terminal" href="/data-catalog/solana/instruction-calls">
    Every program instruction with decoded arguments and inner calls — trace program execution and cross-program invocations
  </Card>

  <Card title="Rewards" icon="gift" href="/data-catalog/solana/rewards">
    Validator and staker reward distributions — calculate APY, track staking returns, and analyze validator economics
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="/data-catalog/solana/transactions">
    Complete transaction records with signatures, signers, fees, and execution status — the foundation for on-chain analysis
  </Card>

  <Card title="Vote Transactions" icon="check-to-slot" href="/data-catalog/solana/vote-transactions">
    Validator consensus votes — monitor network health, validator participation, and consensus patterns
  </Card>
</CardGroup>

***

## Resources

<CardGroup>
  <Card title="Full Solana Data Guide" icon="map" href="https://read.cryptodatabytes.com/p/starter-guide-to-solana-data-analysis">
    In-depth walkthrough for getting started with Solana data analysis on Dune, covering raw tables, decoded data, and common query patterns.
  </Card>
</CardGroup>


# solana.rewards
Source: https://docs.dune.com/data-catalog/solana/rewards

Validator and staker reward distributions on Solana — staking rewards, voting rewards, and fee distributions. Use this data for APY calculations, validator economics research, staking yield analysis, and custodial reporting.

## Table description

The `solana.rewards` table contains data about rewards paid out on Solana. One block may contain zero or more rewards, and each row corresponds to one reward.

## Table Schema

| Column         | Type        | Description                                                                                |
| -------------- | ----------- | ------------------------------------------------------------------------------------------ |
| `block_slot`   | `BIGINT`    | The slot number of the block in which this reward was distributed                          |
| `block_time`   | `TIMESTAMP` | The timestamp of the block containing this reward                                          |
| `block_hash`   | `VARCHAR`   | The hash of the block containing this reward                                               |
| `reward_type`  | `VARCHAR`   | The type of reward (e.g., 'Fee', 'Rent', 'Staking', 'Voting')                              |
| `lamports`     | `BIGINT`    | The reward amount in lamports (1 SOL = 1,000,000,000 lamports)                             |
| `pre_balance`  | `BIGINT`    | The recipient's balance in lamports before the reward was applied                          |
| `post_balance` | `BIGINT`    | The recipient's balance in lamports after the reward was applied                           |
| `commission`   | `BIGINT`    | The validator commission percentage at the time of the reward (for staking/voting rewards) |
| `recipient`    | `VARCHAR`   | The account address that received the reward                                               |
| `block_date`   | `DATE`      | The date of the block in which this reward was distributed                                 |

## Table Sample

<TableSample />


# solana.transactions
Source: https://docs.dune.com/data-catalog/solana/transactions

Complete Solana transaction records with signatures, signers, fees, compute units, and execution status. The foundational table for on-chain analysis — from trading flow attribution and fee optimization to compliance monitoring and application usage tracking.

## Table description

The `solana.transactions` table contains the transaction data within Solana's blockchain. Most of the relevant data related to account, protocol, and program activity is available in this table.

This table excludes all voting transactions, which are available in the `solana.vote_transactions` table.

## Table Schema

| Column                       | Type                                                                                                                                                                                                                   | Description                                                                                       |
| ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- |
| `block_slot`                 | `BIGINT`                                                                                                                                                                                                               | The slot number of the block containing this transaction                                          |
| `block_height`               | `BIGINT`                                                                                                                                                                                                               | The block height at which this transaction was processed                                          |
| `block_time`                 | `TIMESTAMP`                                                                                                                                                                                                            | The timestamp of the block this transaction belongs to                                            |
| `block_date`                 | `DATE`                                                                                                                                                                                                                 | The date of the block this transaction belongs to                                                 |
| `index`                      | `INTEGER`                                                                                                                                                                                                              | The index position of this transaction within the block                                           |
| `fee`                        | `BIGINT`                                                                                                                                                                                                               | The transaction fee paid in lamports                                                              |
| `compute_units_consumed`     | `BIGINT`                                                                                                                                                                                                               | The number of compute units consumed by this transaction                                          |
| `cost_units`                 | `BIGINT`                                                                                                                                                                                                               | The cost units charged for this transaction                                                       |
| `version`                    | `VARCHAR`                                                                                                                                                                                                              | The transaction version ('legacy' or '0' for versioned transactions)                              |
| `required_signatures`        | `INTEGER`                                                                                                                                                                                                              | The number of signatures required for this transaction                                            |
| `readonly_signed_accounts`   | `INTEGER`                                                                                                                                                                                                              | The number of read-only accounts that are also signers                                            |
| `readonly_unsigned_accounts` | `INTEGER`                                                                                                                                                                                                              | The number of read-only accounts that are not signers                                             |
| `block_hash`                 | `VARCHAR`                                                                                                                                                                                                              | The hash of the block containing this transaction                                                 |
| `id`                         | `VARCHAR`                                                                                                                                                                                                              | The unique transaction ID (same as signature)                                                     |
| `signature`                  | `VARCHAR`                                                                                                                                                                                                              | The first signature of the transaction, used as the transaction identifier                        |
| `success`                    | `BOOLEAN`                                                                                                                                                                                                              | Whether the transaction completed successfully                                                    |
| `error`                      | `VARCHAR`                                                                                                                                                                                                              | The error message if the transaction failed, null otherwise                                       |
| `recent_block_hash`          | `VARCHAR`                                                                                                                                                                                                              | The recent blockhash used for transaction validity and replay prevention                          |
| `instructions`               | `ARRAY(ROW(data VARCHAR, executing_account VARCHAR, account_arguments ARRAY(VARCHAR), inner_instructions ARRAY(ROW(data VARCHAR, executing_account VARCHAR, account_arguments ARRAY(VARCHAR), stack_height BIGINT))))` | The list of instructions executed in this transaction, including nested inner instructions        |
| `account_keys`               | `ARRAY(VARCHAR)`                                                                                                                                                                                                       | All account addresses referenced in this transaction                                              |
| `log_messages`               | `ARRAY(VARCHAR)`                                                                                                                                                                                                       | Program log messages emitted during transaction execution                                         |
| `pre_balances`               | `ARRAY(BIGINT)`                                                                                                                                                                                                        | SOL balances (in lamports) of all accounts before the transaction, ordered by account\_keys index |
| `post_balances`              | `ARRAY(BIGINT)`                                                                                                                                                                                                        | SOL balances (in lamports) of all accounts after the transaction, ordered by account\_keys index  |
| `pre_token_balances`         | `ARRAY(ROW(account VARCHAR, mint VARCHAR, owner VARCHAR, amount DECIMAL(38,18)))`                                                                                                                                      | SPL token balances of accounts before the transaction                                             |
| `post_token_balances`        | `ARRAY(ROW(account VARCHAR, mint VARCHAR, owner VARCHAR, amount DECIMAL(38,18)))`                                                                                                                                      | SPL token balances of accounts after the transaction                                              |
| `signatures`                 | `ARRAY(VARCHAR)`                                                                                                                                                                                                       | All signatures attached to this transaction                                                       |
| `signer`                     | `VARCHAR`                                                                                                                                                                                                              | The primary signer (fee payer) of the transaction                                                 |
| `signers`                    | `ARRAY(VARCHAR)`                                                                                                                                                                                                       | All accounts that signed this transaction                                                         |
| `return_data_program_id`     | `VARCHAR`                                                                                                                                                                                                              | The program ID that produced the return data, if any                                              |
| `return_data`                | `ARRAY(VARCHAR)`                                                                                                                                                                                                       | The data returned by the program after execution, if any                                          |
| `address_table_lookups`      | `ARRAY(ROW(accountKey VARCHAR, readonlyIndexes ARRAY(BIGINT), writableIndexes ARRAY(BIGINT)))`                                                                                                                         | Address lookup table references used for versioned transactions                                   |
| `loaded_addresses`           | `ROW(readonly ARRAY(VARCHAR), writable ARRAY(VARCHAR))`                                                                                                                                                                | Addresses loaded from address lookup tables, split into readonly and writable sets                |

## Table Sample

<TableSample />


# solana.vote_transactions
Source: https://docs.dune.com/data-catalog/solana/vote-transactions

Solana validator consensus vote transactions — track validator participation, voting patterns, and network health. Essential for staking providers, validator operators, and researchers analyzing Solana's consensus mechanism.

## Table description

The `solana.vote_transactions` table contains the full set of vote transactions that are submitted by validators to vote on a block. It can be joined with the non-vote transactions table above to get a full breakdown of all transactions. It has the same schema as the main transactions table.

## Table Schema

| Column                       | Type                                                                                                                                                                                                                   | Description                                                                                            |
| ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
| `block_slot`                 | `BIGINT`                                                                                                                                                                                                               | The slot number of the block containing this vote transaction                                          |
| `block_height`               | `BIGINT`                                                                                                                                                                                                               | The block height at which this vote transaction was processed                                          |
| `block_time`                 | `TIMESTAMP`                                                                                                                                                                                                            | The timestamp of the block this vote transaction belongs to                                            |
| `block_date`                 | `DATE`                                                                                                                                                                                                                 | The date of the block this vote transaction belongs to                                                 |
| `index`                      | `INTEGER`                                                                                                                                                                                                              | The index position of this vote transaction within the block                                           |
| `fee`                        | `BIGINT`                                                                                                                                                                                                               | The transaction fee paid in lamports                                                                   |
| `compute_units_consumed`     | `BIGINT`                                                                                                                                                                                                               | The number of compute units consumed by this vote transaction                                          |
| `cost_units`                 | `BIGINT`                                                                                                                                                                                                               | The cost units charged for this vote transaction                                                       |
| `version`                    | `VARCHAR`                                                                                                                                                                                                              | The transaction version ('legacy' or '0' for versioned transactions)                                   |
| `required_signatures`        | `INTEGER`                                                                                                                                                                                                              | The number of signatures required for this vote transaction                                            |
| `readonly_signed_accounts`   | `INTEGER`                                                                                                                                                                                                              | The number of read-only accounts that are also signers                                                 |
| `readonly_unsigned_accounts` | `INTEGER`                                                                                                                                                                                                              | The number of read-only accounts that are not signers                                                  |
| `block_hash`                 | `VARCHAR`                                                                                                                                                                                                              | The hash of the block containing this vote transaction                                                 |
| `id`                         | `VARCHAR`                                                                                                                                                                                                              | The unique transaction ID (same as signature)                                                          |
| `signature`                  | `VARCHAR`                                                                                                                                                                                                              | The first signature of the transaction, used as the transaction identifier                             |
| `success`                    | `BOOLEAN`                                                                                                                                                                                                              | Whether the vote transaction completed successfully                                                    |
| `error`                      | `VARCHAR`                                                                                                                                                                                                              | The error message if the vote transaction failed, null otherwise                                       |
| `recent_block_hash`          | `VARCHAR`                                                                                                                                                                                                              | The recent blockhash used for transaction validity and replay prevention                               |
| `instructions`               | `ARRAY(ROW(data VARCHAR, executing_account VARCHAR, account_arguments ARRAY(VARCHAR), inner_instructions ARRAY(ROW(data VARCHAR, executing_account VARCHAR, account_arguments ARRAY(VARCHAR), stack_height BIGINT))))` | The list of instructions executed in this vote transaction, including nested inner instructions        |
| `account_keys`               | `ARRAY(VARCHAR)`                                                                                                                                                                                                       | All account addresses referenced in this vote transaction                                              |
| `log_messages`               | `ARRAY(VARCHAR)`                                                                                                                                                                                                       | Program log messages emitted during vote transaction execution                                         |
| `pre_balances`               | `ARRAY(BIGINT)`                                                                                                                                                                                                        | SOL balances (in lamports) of all accounts before the vote transaction, ordered by account\_keys index |
| `post_balances`              | `ARRAY(BIGINT)`                                                                                                                                                                                                        | SOL balances (in lamports) of all accounts after the vote transaction, ordered by account\_keys index  |
| `pre_token_balances`         | `ARRAY(ROW(account VARCHAR, mint VARCHAR, owner VARCHAR, amount DECIMAL(38,18)))`                                                                                                                                      | SPL token balances of accounts before the vote transaction                                             |
| `post_token_balances`        | `ARRAY(ROW(account VARCHAR, mint VARCHAR, owner VARCHAR, amount DECIMAL(38,18)))`                                                                                                                                      | SPL token balances of accounts after the vote transaction                                              |
| `signatures`                 | `ARRAY(VARCHAR)`                                                                                                                                                                                                       | All signatures attached to this vote transaction                                                       |
| `signer`                     | `VARCHAR`                                                                                                                                                                                                              | The primary signer (fee payer) of the vote transaction                                                 |
| `signers`                    | `ARRAY(VARCHAR)`                                                                                                                                                                                                       | All accounts that signed this vote transaction                                                         |
| `return_data_program_id`     | `VARCHAR`                                                                                                                                                                                                              | The program ID that produced the return data, if any                                                   |
| `return_data`                | `ARRAY(VARCHAR)`                                                                                                                                                                                                       | The data returned by the program after execution, if any                                               |
| `address_table_lookups`      | `ARRAY(ROW(accountKey VARCHAR, readonlyIndexes ARRAY(BIGINT), writableIndexes ARRAY(BIGINT)))`                                                                                                                         | Address lookup table references used for versioned vote transactions                                   |
| `loaded_addresses`           | `ROW(readonly ARRAY(VARCHAR), writable ARRAY(VARCHAR))`                                                                                                                                                                | Addresses loaded from address lookup tables, split into readonly and writable sets                     |

## Table Sample

<TableSample />


# starknet.blocks
Source: https://docs.dune.com/data-catalog/starknet/blocks

StarkNet block data — block numbers, timestamps, sequencer identity, and state roots.

## Table description

The `starknet.blocks` table represents the blocks in the Starknet blockchain. A block is a collection of transactions, and is identified by a unique block identifier. Each block contains a timestamp and a reference to the previous block hash, forming a chain of blocks. The block structure is crucial for the blockchain's integrity and security, ensuring a verifiable and tamper-evident ledger.

## Table Schema

| Column                     | Type        | Description                                                                           |
| -------------------------- | ----------- | ------------------------------------------------------------------------------------- |
| `date`                     | `DATE`      | The date of the block (UTC)                                                           |
| `number`                   | `BIGINT`    | The sequential block number                                                           |
| `time`                     | `TIMESTAMP` | The timestamp when the block was produced                                             |
| `l1_da_mode`               | `VARCHAR`   | Layer 1 data availability mode (`BLOB` or `CALLDATA`). Introduced in Starknet v0.13.1 |
| `l1_data_gas_price_in_fri` | `UINT256`   | L1 data gas price denominated in fri (STRK), used for v3+ transactions                |
| `l1_data_gas_price_in_wei` | `UINT256`   | L1 data gas price denominated in wei (ETH), used for pre-v3 transactions              |
| `l1_gas_price_in_fri`      | `UINT256`   | L1 gas price denominated in fri (STRK), used for v3+ transactions                     |
| `l1_gas_price_in_wei`      | `UINT256`   | L1 gas price denominated in wei (ETH), used for pre-v3 transactions                   |
| `l2_gas_price_in_fri`      | `UINT256`   | L2 gas price denominated in fri (STRK), used for v3+ transactions                     |
| `l2_gas_price_in_wei`      | `UINT256`   | L2 gas price denominated in wei (ETH), used for pre-v3 transactions                   |
| `starknet_version`         | `VARCHAR`   | The Starknet protocol version used for this block                                     |
| `tx_count`                 | `INTEGER`   | Number of transactions included in this block                                         |
| `hash`                     | `VARBINARY` | Unique hash identifying this block                                                    |
| `new_root`                 | `VARBINARY` | The new global state root after applying this block                                   |
| `parent_hash`              | `VARBINARY` | Hash of the preceding block                                                           |
| `sequencer_address`        | `VARBINARY` | Address of the sequencer that produced this block                                     |
| `state_diff`               | `VARCHAR`   | JSON-encoded state changes resulting from this block                                  |

<Note>
  * Prior to [v3 transactions upgrade](https://www.starknet.io/developers/roadmap/v3-transactions/), fees are denominated in `wei` as users pay gas with ETH. For transactions v3 and later, fees are denominated in `fri` as users pay gas with STRK. Hence here you can see two gas types of gas fields, one for `wei` and one for `fri`.
  * Starting with Starknet v0.13.1, Starknet distinguishes between blocks whose state diffs are sent to L1 as calldata and blocks whose state diffs are sent to L1 as blobs. The `l1_da_mode` property in the Starknet block header contains this information. Values possible are `BLOB` or `CALLDATA`.
  * Visit this [Starknet doc on block structure](https://docs.starknet.io/architecture-and-concepts/network-architecture/block-structure/) to learn more.
</Note>

## Table Sample

<TableSample />


# starknet.calls
Source: https://docs.dune.com/data-catalog/starknet/calls

StarkNet internal calls — function call traces within StarkNet transaction execution.

## Table description

The `starknet.calls` table documents the execution trace of the transaction designated by the input hash.

## Table Schema

| Column                                                 | Type                                                                                                 | Description                                                                                    |
| ------------------------------------------------------ | ---------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
| `block_date`                                           | `DATE`                                                                                               | The date of the block containing this call (UTC)                                               |
| `block_time`                                           | `TIMESTAMP`                                                                                          | The timestamp of the block containing this call                                                |
| `block_number`                                         | `BIGINT`                                                                                             | The sequential number of the block containing this call                                        |
| `block_l1_da_mode`                                     | `VARCHAR`                                                                                            | Layer 1 data availability mode (`BLOB` or `CALLDATA`)                                          |
| `block_l1_data_gas_price_in_fri`                       | `UINT256`                                                                                            | L1 data gas price in fri (STRK) for the block                                                  |
| `block_l1_data_gas_price_in_wei`                       | `UINT256`                                                                                            | L1 data gas price in wei (ETH) for the block                                                   |
| `block_l1_gas_price_in_fri`                            | `UINT256`                                                                                            | L1 gas price in fri (STRK) for the block                                                       |
| `block_l1_gas_price_in_wei`                            | `UINT256`                                                                                            | L1 gas price in wei (ETH) for the block                                                        |
| `block_l2_gas_price_in_fri`                            | `UINT256`                                                                                            | L2 gas price in fri (STRK) for the block                                                       |
| `block_l2_gas_price_in_wei`                            | `UINT256`                                                                                            | L2 gas price in wei (ETH) for the block                                                        |
| `block_starknet_version`                               | `VARCHAR`                                                                                            | The Starknet protocol version of the block                                                     |
| `transaction_index`                                    | `INTEGER`                                                                                            | Position of the parent transaction within the block                                            |
| `transaction_type`                                     | `VARCHAR`                                                                                            | Type of the parent transaction (`INVOKE`, `L1_HANDLER`, `DECLARE`, `DEPLOY_ACCOUNT`, `DEPLOY`) |
| `call_type`                                            | `VARCHAR`                                                                                            | Type of function call (`CALL`, `LIBRARY_CALL`, or `DELEGATE`)                                  |
| `context`                                              | `VARCHAR`                                                                                            | Execution context of the call                                                                  |
| `entry_point_type`                                     | `VARCHAR`                                                                                            | Type of entry point invoked (`EXTERNAL`, `L1_HANDLER`, `CONSTRUCTOR`)                          |
| `execution_resources_bitwise_builtin_applications`     | `INTEGER`                                                                                            | Number of bitwise builtin applications consumed                                                |
| `execution_resources_data_availability_l1_gas`         | `UINT256`                                                                                            | L1 gas consumed for data availability                                                          |
| `execution_resources_data_availability_l1_data_gas`    | `UINT256`                                                                                            | L1 data gas consumed for data availability                                                     |
| `execution_resources_data_availability_l2_gas`         | `UINT256`                                                                                            | L2 gas consumed for data availability                                                          |
| `execution_resources_ec_op_builtin_applications`       | `INTEGER`                                                                                            | Number of elliptic curve operation builtin applications consumed                               |
| `execution_resources_ecdsa_builtin_applications`       | `INTEGER`                                                                                            | Number of ECDSA builtin applications consumed                                                  |
| `execution_resources_keccak_builtin_applications`      | `INTEGER`                                                                                            | Number of Keccak builtin applications consumed                                                 |
| `execution_resources_memory_holes`                     | `INTEGER`                                                                                            | Number of memory holes in the execution trace                                                  |
| `execution_resources_pedersen_builtin_applications`    | `INTEGER`                                                                                            | Number of Pedersen hash builtin applications consumed                                          |
| `execution_resources_poseidon_builtin_applications`    | `INTEGER`                                                                                            | Number of Poseidon hash builtin applications consumed                                          |
| `execution_resources_range_check_builtin_applications` | `INTEGER`                                                                                            | Number of range check builtin applications consumed                                            |
| `execution_resources_segment_arena_builtin`            | `INTEGER`                                                                                            | Number of segment arena builtin applications consumed                                          |
| `execution_resources_steps`                            | `INTEGER`                                                                                            | Total number of Cairo VM steps executed                                                        |
| `num_subcalls`                                         | `INTEGER`                                                                                            | Number of nested sub-calls triggered by this call                                              |
| `block_hash`                                           | `VARBINARY`                                                                                          | Hash of the block containing this call                                                         |
| `block_new_root`                                       | `VARBINARY`                                                                                          | New global state root after the block                                                          |
| `block_parent_hash`                                    | `VARBINARY`                                                                                          | Hash of the preceding block                                                                    |
| `block_sequencer_address`                              | `VARBINARY`                                                                                          | Address of the sequencer that produced the block                                               |
| `transaction_hash`                                     | `VARBINARY`                                                                                          | Hash of the parent transaction                                                                 |
| `callstack_index`                                      | `ARRAY(INTEGER)`                                                                                     | Position in the call tree hierarchy                                                            |
| `calldata`                                             | `ARRAY(VARBINARY)`                                                                                   | Input data passed to this call                                                                 |
| `caller_address`                                       | `VARBINARY`                                                                                          | Address of the contract that initiated this call                                               |
| `class_hash`                                           | `VARBINARY`                                                                                          | Class hash of the called contract                                                              |
| `contract_address`                                     | `VARBINARY`                                                                                          | Address of the contract being called                                                           |
| `entry_point_selector`                                 | `VARBINARY`                                                                                          | Selector identifying the function entry point                                                  |
| `events`                                               | `ARRAY(ROW(DATA ARRAY(VARCHAR), KEYS ARRAY(VARCHAR), EVENT_INDEX INTEGER))`                          | Events emitted during this call                                                                |
| `messages`                                             | `ARRAY(ROW(FROM_ADDRESS VARBINARY, PAYLOAD VARBINARY, TO_ADDRESS VARBINARY, MESSAGE_INDEX INTEGER))` | L2-to-L1 messages sent during this call                                                        |
| `result`                                               | `VARBINARY`                                                                                          | Return value of the call                                                                       |
| `revert_reason`                                        | `VARCHAR`                                                                                            | Reason for call failure, if the call reverted                                                  |
| `state_diff`                                           | `VARCHAR`                                                                                            | JSON-encoded state changes resulting from this call                                            |

<Note>
  * Prior to [v3 transactions upgrade](https://www.starknet.io/developers/roadmap/v3-transactions/), fees are denominated in `wei` as users pay gas with ETH. For transactions v3 and later, fees are denominated in `fri` as users pay gas with STRK. Hence here you can see two gas types of gas fields, one for `wei` and one for `fri`.
  * Starting with Starknet v0.13.1, Starknet distinguishes between blocks whose state diffs are sent to L1 as calldata and blocks whose state diffs are sent to L1 as blobs. The `l1_da_mode` property in the Starknet block header contains this information. Values possible are `BLOB` or `CALLDATA`.
  * The `block_status` has possible values `ACCEPTED_ON_L1` or `ACCEPTED_ON_L2`. Read here to learn more about [different transaction status](https://docs.starknet.io/architecture-and-concepts/network-architecture/transaction-life-cycle/#transaction_status).
  * The `transaction_type` fields denotes [different types of transactions](https://docs.starknet.io/architecture-and-concepts/network-architecture/transactions/) supported by Starknet. Possible values are: `INVOKE`, `L1_HANDLER`, `DECLARE`, `DEPLOY_ACCOUNT`, and `DEPLOY`.
  * The `call_type` fields denotes what type of function calls was invoked. Possible values are [`LIBRARY_CALL`](https://docs.starknet.io/architecture-and-concepts/smart-contracts/system-calls-cairo1/#library_call), `CALL`, or `DELEGATE`
  * 'entry\_point\_type': The type of entry point. Possible values includes - `EXTERNAL`, `L1_HANDLER`, `CONSTRUCTOR`
</Note>

## Table Sample

<TableSample />


# starknet.events
Source: https://docs.dune.com/data-catalog/starknet/events

StarkNet contract events — event data emitted by Cairo smart contracts during execution.

## Table description

The `starknet.events` table captures the events that are emitted by smart contracts on the Starknet blockchain. Events are used to log significant actions and changes in smart contracts, such as token transfers or updates to contract states. Each event is linked to the transaction that triggered it, providing a detailed audit trail of contract interactions.

## Table Schema

| Column                           | Type               | Description                                              |
| -------------------------------- | ------------------ | -------------------------------------------------------- |
| `block_date`                     | `DATE`             | The date of the block containing this event (UTC)        |
| `block_time`                     | `TIMESTAMP`        | The timestamp of the block containing this event         |
| `block_number`                   | `BIGINT`           | The sequential number of the block containing this event |
| `block_l1_da_mode`               | `VARCHAR`          | Layer 1 data availability mode (`BLOB` or `CALLDATA`)    |
| `block_l1_data_gas_price_in_fri` | `UINT256`          | L1 data gas price in fri (STRK) for the block            |
| `block_l1_data_gas_price_in_wei` | `UINT256`          | L1 data gas price in wei (ETH) for the block             |
| `block_l1_gas_price_in_fri`      | `UINT256`          | L1 gas price in fri (STRK) for the block                 |
| `block_l1_gas_price_in_wei`      | `UINT256`          | L1 gas price in wei (ETH) for the block                  |
| `block_l2_gas_price_in_fri`      | `UINT256`          | L2 gas price in fri (STRK) for the block                 |
| `block_l2_gas_price_in_wei`      | `UINT256`          | L2 gas price in wei (ETH) for the block                  |
| `block_starknet_version`         | `VARCHAR`          | The Starknet protocol version of the block               |
| `event_index`                    | `INTEGER`          | Sequential index of this event within the transaction    |
| `block_hash`                     | `VARBINARY`        | Hash of the block containing this event                  |
| `block_new_root`                 | `VARBINARY`        | New global state root after the block                    |
| `block_parent_hash`              | `VARBINARY`        | Hash of the preceding block                              |
| `block_sequencer_address`        | `VARBINARY`        | Address of the sequencer that produced the block         |
| `transaction_hash`               | `VARBINARY`        | Hash of the transaction that emitted this event          |
| `data`                           | `ARRAY(VARBINARY)` | The data payload associated with this event              |
| `keys`                           | `ARRAY(VARBINARY)` | The indexed keys associated with this event              |
| `from_address`                   | `VARBINARY`        | Address of the L2 contract that emitted this event       |
| `class_hash`                     | `VARBINARY`        | Class hash of the contract that emitted this event       |

<Note>
  * Prior to [v3 transactions upgrade](https://www.starknet.io/developers/roadmap/v3-transactions/), fees are denominated in `wei` as users pay gas with ETH. For transactions v3 and later, fees are denominated in `fri` as users pay gas with STRK. Hence here you can see two gas types of gas fields, one for `wei` and one for `fri`.
  * Starting with Starknet v0.13.1, Starknet distinguishes between blocks whose state diffs are sent to L1 as calldata and blocks whose state diffs are sent to L1 as blobs. The `l1_da_mode` property in the Starknet block header contains this information. Values possible are `BLOB` or `CALLDATA`.
  * The `block_status` has possible values `ACCEPTED_ON_L1` or `ACCEPTED_ON_L2`. Read here to learn more about [different transaction status](https://docs.starknet.io/architecture-and-concepts/network-architecture/transaction-life-cycle/#transaction_status).
  * `from_address`: The address of the L2 contract sending the message
  * `keys`: The keys associated with the event
  * `data`: The data associated with the event
  * Visit this [Starknet doc on events](https://docs.starknet.io/architecture-and-concepts/smart-contracts/starknet-events/) to learn more.
</Note>

## Table Sample

<TableSample />


# Starknet data
Source: https://docs.dune.com/data-catalog/starknet/overview

Starknet data on Dune

## What is Starknet?

Starknet is a permissionless Validity-Rollup, also known as a zero-knowledge rollup (ZK rollup) for Ethereum. As a Layer 2 (L2) blockchain, Starknet enables any dApp to achieve massive computation scale without compromising on Ethereum’s composability and security.

Starknet aims to achieve secure, low-cost transactions and high performance by using the STARK cryptographic proof system. Starknet contracts and the Starknet OS are written in [Cairo](https://github.com/starkware-libs/cairo), a custom-built and specialized programming language.

### Why Starknet?

Starknet addresses the scalability issues of Ethereum by offloading computation and state storage from the Ethereum mainnet. It uses STARK (Scalable Transparent Argument of Knowledge) proofs to ensure that transactions are both scalable and secure, enabling a wide range of applications from DeFi to NFTs without compromising on security or decentralization.

### Starknet Architecture

Starknet's architecture is composed of several key components that work together to achieve high scalability and security:

#### STARK Proofs

At the core of Starknet's technology are STARK proofs, which are zero-knowledge proofs that enable scalable and transparent computation. These proofs ensure the integrity and validity of off-chain computations, which are then verified on-chain.

#### Sequencer and Prover

Starknet employs a sequencer to order transactions and a prover to generate STARK proofs. The sequencer ensures that transactions are processed in a fair and orderly manner, while the prover generates cryptographic proofs that validate these transactions.

#### Cairo Language

Starknet uses Cairo, a Turing-complete language designed for writing provable programs. Developers can write smart contracts and off-chain logic in Cairo, leveraging its efficiency and security features.

#### Accounts and Contracts

Starknet introduces a novel account model where each user interacts with the network through their account contracts. This model enhances security and flexibility, allowing for features like account abstraction and multi-sig wallets. Unlike the traditional EVM model, where accounts are either externally owned accounts (EOAs) or smart contracts, Starknet uses account contracts for both user accounts and smart contracts, allowing for more advanced features and customizability.

See Starknet's documentation on [Accounts](https://docs.starknet.io/architecture-and-concepts/accounts/introduction/) and [Contracts](https://docs.starknet.io/architecture-and-concepts/smart-contracts/contract-classes/) for more information

### Starknet Transaction Lifecycle

Transactions on Starknet follow a well-defined lifecycle:

1. **Submission**: Users submit transactions through their account contracts.
2. **Sequencing**: Transactions are ordered by the sequencer.
3. **Proof Generation**: The prover generates STARK proofs for the ordered transactions.
4. **Verification**: Proofs are verified on the Ethereum mainnet, finalizing the state transitions.

For more information on the transaction flow, see [Starknet's doc](https://docs.starknet.io/architecture-and-concepts/network-architecture/transaction-life-cycle/).

<img />

Key Components:

* **Sequencer**: Receives transactions, orders them, and produces blocks, operating similarly to validators in Ethereum or Bitcoin.
* **Prover**: Generates proofs using the Cairo Virtual Machine (Cairo VM) to create execution traces necessary for generating STARK proofs.
* **Verifier**: L1 smart contract, designed to verify STARK proofs and update Starknet’s state root on L1 if valid.
* **Layer 1 (L1)**: Ethereum hosts a smart contract that verifies STARK proofs and updates Starknet’s state root on L1 if valid.

<CardGroup>
  <Card title="Starknet documentation" icon="link" href="https://docs.starknet.io/">
    Explore comprehensive documentation on Starknet, detailing its architecture, protocol, and resources for developers.
  </Card>
</CardGroup>

## Starknet Data on Dune

Starknet provides comprehensive data on various aspects of its network, enabling developers and users to analyze and interact with the blockchain effectively.

<CardGroup>
  <Card title="Blocks" icon="cube" href="/data-catalog/starknet/blocks">
    Represents the collection of transactions in a single block within the Starknet
    blockchain.
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="/data-catalog/starknet/transactions">
    Includes all user and system transactions processed by the Starknet network.
  </Card>

  <Card title="Events" icon="bolt" href="/data-catalog/starknet/events">
    Captures events emitted by smart contracts, logging significant actions and changes.
  </Card>

  <Card title="Calls" icon="terminal" href="/data-catalog/starknet/calls">
    Represents the invocation of smart contract functions, detailing the interactions and parameters used.
  </Card>
</CardGroup>


# starknet.transactions
Source: https://docs.dune.com/data-catalog/starknet/transactions

StarkNet transaction records — invoke, deploy, and declare transactions with fees and execution status.

## Table description

The `starknet.transactions` table contains information about all transactions on the Starknet blockchain, including both user-initiated and system transactions. Transactions are the actions that modify the state of the blockchain, such as transfers of tokens or the execution of smart contracts. Each transaction is uniquely identified and linked to the block in which it was included.

## Table Schema

| Column                                                 | Type                                                                          | Description                                                                      |
| ------------------------------------------------------ | ----------------------------------------------------------------------------- | -------------------------------------------------------------------------------- |
| `block_date`                                           | `DATE`                                                                        | The date of the block containing this transaction (UTC)                          |
| `block_time`                                           | `TIMESTAMP`                                                                   | The timestamp of the block containing this transaction                           |
| `block_number`                                         | `BIGINT`                                                                      | The sequential number of the block containing this transaction                   |
| `block_l1_da_mode`                                     | `VARCHAR`                                                                     | Layer 1 data availability mode (`BLOB` or `CALLDATA`)                            |
| `block_l1_data_gas_price_in_fri`                       | `UINT256`                                                                     | L1 data gas price in fri (STRK) for the block                                    |
| `block_l1_data_gas_price_in_wei`                       | `UINT256`                                                                     | L1 data gas price in wei (ETH) for the block                                     |
| `block_l1_gas_price_in_fri`                            | `UINT256`                                                                     | L1 gas price in fri (STRK) for the block                                         |
| `block_l1_gas_price_in_wei`                            | `UINT256`                                                                     | L1 gas price in wei (ETH) for the block                                          |
| `block_l2_gas_price_in_fri`                            | `UINT256`                                                                     | L2 gas price in fri (STRK) for the block                                         |
| `block_l2_gas_price_in_wei`                            | `UINT256`                                                                     | L2 gas price in wei (ETH) for the block                                          |
| `block_starknet_version`                               | `VARCHAR`                                                                     | The Starknet protocol version of the block                                       |
| `fee_data_availability_mode`                           | `VARCHAR`                                                                     | Storage domain for fee payment (`L1` or `L2`)                                    |
| `index`                                                | `INTEGER`                                                                     | Position of this transaction within the block                                    |
| `max_fee`                                              | `UINT256`                                                                     | Maximum fee the sender is willing to pay (pre-v3 transactions)                   |
| `nonce`                                                | `INTEGER`                                                                     | Sender's transaction sequence number to prevent replays                          |
| `nonce_data_availability_mode`                         | `VARCHAR`                                                                     | Storage domain for the account nonce (`L1` or `L2`)                              |
| `resource_bounds_l1_gas_max_amount`                    | `UINT256`                                                                     | Maximum L1 gas amount the sender is willing to consume (v3+)                     |
| `resource_bounds_l1_gas_max_price_per_unit`            | `UINT256`                                                                     | Maximum price per unit of L1 gas the sender will pay (v3+)                       |
| `resource_bounds_l1_data_gas_max_amount`               | `UINT256`                                                                     | Maximum L1 data gas amount the sender is willing to consume (v3+)                |
| `resource_bounds_l1_data_gas_max_price_per_unit`       | `UINT256`                                                                     | Maximum price per unit of L1 data gas the sender will pay (v3+)                  |
| `resource_bounds_l2_gas_max_amount`                    | `VARBINARY`                                                                   | Maximum L2 gas amount the sender is willing to consume (v3+)                     |
| `resource_bounds_l2_gas_max_price_per_unit`            | `VARBINARY`                                                                   | Maximum price per unit of L2 gas the sender will pay (v3+)                       |
| `tip`                                                  | `UINT256`                                                                     | Optional tip paid to the sequencer for priority (v3+)                            |
| `type`                                                 | `VARCHAR`                                                                     | Transaction type (`INVOKE`, `L1_HANDLER`, `DECLARE`, `DEPLOY_ACCOUNT`, `DEPLOY`) |
| `version`                                              | `INTEGER`                                                                     | Transaction version number                                                       |
| `actual_fee_amount`                                    | `UINT256`                                                                     | Actual fee charged for this transaction                                          |
| `actual_fee_unit`                                      | `VARCHAR`                                                                     | Unit of the actual fee (`WEI` for ETH, `FRI` for STRK)                           |
| `execution_resources_bitwise_builtin_applications`     | `INTEGER`                                                                     | Number of bitwise builtin applications consumed                                  |
| `execution_resources_data_availability_l1_gas`         | `UINT256`                                                                     | L1 gas consumed for data availability                                            |
| `execution_resources_data_availability_l1_data_gas`    | `UINT256`                                                                     | L1 data gas consumed for data availability                                       |
| `execution_resources_data_availability_l2_gas`         | `UINT256`                                                                     | L2 gas consumed for data availability                                            |
| `execution_resources_ec_op_builtin_applications`       | `INTEGER`                                                                     | Number of elliptic curve operation builtin applications consumed                 |
| `execution_resources_ecdsa_builtin_applications`       | `INTEGER`                                                                     | Number of ECDSA builtin applications consumed                                    |
| `execution_resources_keccak_builtin_applications`      | `INTEGER`                                                                     | Number of Keccak builtin applications consumed                                   |
| `execution_resources_memory_holes`                     | `INTEGER`                                                                     | Number of memory holes in the execution trace                                    |
| `execution_resources_pedersen_builtin_applications`    | `INTEGER`                                                                     | Number of Pedersen hash builtin applications consumed                            |
| `execution_resources_poseidon_builtin_applications`    | `INTEGER`                                                                     | Number of Poseidon hash builtin applications consumed                            |
| `execution_resources_range_check_builtin_applications` | `INTEGER`                                                                     | Number of range check builtin applications consumed                              |
| `execution_resources_segment_arena_builtin`            | `INTEGER`                                                                     | Number of segment arena builtin applications consumed                            |
| `execution_resources_steps`                            | `INTEGER`                                                                     | Total number of Cairo VM steps executed                                          |
| `execution_status`                                     | `VARCHAR`                                                                     | Final execution status of the transaction                                        |
| `finality_status`                                      | `VARCHAR`                                                                     | Finality status (`ACCEPTED_ON_L1` or `ACCEPTED_ON_L2`)                           |
| `receipt_type`                                         | `VARCHAR`                                                                     | Type of the transaction receipt                                                  |
| `block_hash`                                           | `VARBINARY`                                                                   | Hash of the block containing this transaction                                    |
| `block_new_root`                                       | `VARBINARY`                                                                   | New global state root after the block                                            |
| `block_parent_hash`                                    | `VARBINARY`                                                                   | Hash of the preceding block                                                      |
| `block_sequencer_address`                              | `VARBINARY`                                                                   | Address of the sequencer that produced the block                                 |
| `calldata`                                             | `ARRAY(VARBINARY)`                                                            | Input data for the transaction's function call                                   |
| `class_hash`                                           | `VARBINARY`                                                                   | Class hash of the declared or deployed contract                                  |
| `compiled_class_hash`                                  | `VARBINARY`                                                                   | Compiled class hash (for `DECLARE` v2+ transactions)                             |
| `constructor_calldata`                                 | `ARRAY(VARBINARY)`                                                            | Constructor arguments (for `DEPLOY_ACCOUNT` transactions)                        |
| `contract_address`                                     | `VARBINARY`                                                                   | Address of the contract involved in this transaction                             |
| `contract_address_salt`                                | `VARBINARY`                                                                   | Salt used for contract address computation (for deployments)                     |
| `entry_point_selector`                                 | `VARBINARY`                                                                   | Selector identifying the invoked function entry point                            |
| `hash`                                                 | `VARBINARY`                                                                   | Unique hash identifying this transaction                                         |
| `sender_address`                                       | `VARBINARY`                                                                   | Address of the account that sent this transaction                                |
| `signature`                                            | `ARRAY(VARBINARY)`                                                            | Cryptographic signature of the transaction                                       |
| `message_hash`                                         | `VARBINARY`                                                                   | Hash of the L1-to-L2 message (for `L1_HANDLER` transactions)                     |
| `messages_sent`                                        | `ARRAY(ROW(FROM_ADDRESS VARBINARY, PAYLOAD VARBINARY, TO_ADDRESS VARBINARY))` | L2-to-L1 messages sent by this transaction                                       |
| `revert_reason`                                        | `VARCHAR`                                                                     | Reason for transaction failure, if it reverted                                   |
| `transaction_hash`                                     | `VARBINARY`                                                                   | Hash of this transaction (same as `hash`)                                        |

<Note>
  * Prior to [v3 transactions upgrade](https://www.starknet.io/developers/roadmap/v3-transactions/), fees are denominated in `wei` as users pay gas with ETH. For transactions v3 and later, fees are denominated in `fri` as users pay gas with STRK. Hence here you can see two gas types of gas fields, one for `wei` and one for `fri`.
  * Starting with Starknet v0.13.1, Starknet distinguishes between blocks whose state diffs are sent to L1 as calldata and blocks whose state diffs are sent to L1 as blobs. The `l1_da_mode` property in the Starknet block header contains this information. Values possible are `BLOB` or `CALLDATA`.
  * The `type` fields denotes [different types of transactions](https://docs.starknet.io/architecture-and-concepts/network-architecture/transactions/) supported by Starknet. Possible values are: `INVOKE`, `L1_HANDLER`, `DECLARE`, `DEPLOY_ACCOUNT`, and `DEPLOY`.
  * The `fee_data_availability_mode` field denotes the storage domain of the account's balance from which fee will be charged. It can be one of 'L1' or 'L2'
  * The `block_status` has possible values `ACCEPTED_ON_L1` or `ACCEPTED_ON_L2`. Read here to learn more about [different transaction status](https://docs.starknet.io/architecture-and-concepts/network-architecture/transaction-life-cycle/#transaction_status).
  * The `actual_fee` has the actual fee paid for the transaction, to be used together with `actual_fee_unit`.
</Note>

## Table Sample

<TableSample />


# stellar.accounts
Source: https://docs.dune.com/data-catalog/stellar/accounts

Stellar account data — public keys, sequence numbers, balances, and thresholds.

## Table description

The `stellar.accounts` table tracks the native token (Lumens) balances held by accounts.

Accounts are the central data structure in Stellar- they hold balances, sign transactions, and issue assets. Accounts can only exist with a valid keypair and the required minimum balance of XLM.

## Column Descriptions

| **Column**                                    | **Description**                                                                              | **Type**                    |
| --------------------------------------------- | -------------------------------------------------------------------------------------------- | --------------------------- |
| **closed\_at\_date**                          | The date when the account's ledger entry was closed.                                         | date                        |
| **account\_id**                               | The unique identifier for the Stellar account.                                               | varchar                     |
| **balance**                                   | The current balance of lumens (XLM) in the account.                                          | double                      |
| **buying\_liabilities**                       | The total liabilities for buying offers on the account.                                      | double                      |
| **selling\_liabilities**                      | The total liabilities for selling offers on the account.                                     | double                      |
| **sequence\_number**                          | The current sequence number of the account, incremented with each transaction.               | bigint                      |
| **num\_subentries**                           | The number of subentries, such as trustlines or offers, associated with the account.         | bigint                      |
| **inflation\_destination**                    | The destination account for inflation pools (deprecated feature).                            | varchar                     |
| **flags**                                     | A set of flags representing various account properties like authorization.                   | bigint                      |
| **home\_domain**                              | The home domain associated with the account, used for federation or verifying asset issuers. | varchar                     |
| **master\_weight**                            | The weight of the account's master key used for signing transactions.                        | bigint                      |
| **threshold\_low**                            | The threshold level required for low-priority operations (e.g., payments).                   | bigint                      |
| **threshold\_medium**                         | The threshold level required for medium-priority operations (e.g., trustlines).              | bigint                      |
| **threshold\_high**                           | The threshold level required for high-priority operations (e.g., multisig transactions).     | bigint                      |
| **last\_modified\_ledger**                    | The ledger sequence number where the account was last modified.                              | bigint                      |
| **ledger\_entry\_change**                     | Indicates the type of change made to the ledger entry (insert, update, delete).              | bigint                      |
| **deleted**                                   | A boolean indicating whether the account has been deleted from the ledger.                   | boolean                     |
| **sponsor**                                   | The account that is sponsoring this account’s resources.                                     | varchar                     |
| **num\_sponsored**                            | The number of subentries sponsored by this account.                                          | bigint                      |
| **num\_sponsoring**                           | The number of subentries this account is sponsoring.                                         | bigint                      |
| **sequence\_time**                            | The time when the sequence number was last updated.                                          | timestamp(3) with time zone |
| **closed\_at**                                | The timestamp when the account was last closed.                                              | timestamp(3) with time zone |
| **ledger\_sequence**                          | The sequence number of the ledger in which the account is included.                          | bigint                      |
| **account\_sequence\_last\_modified\_ledger** | The last ledger sequence where the account's sequence number was modified.                   | bigint                      |
| **updated\_at**                               | The time when the account record was last updated.                                           | timestamp(3) with time zone |
| **ingested\_at**                              | The time when the account data was ingested into the system.                                 | timestamp(3) with time zone |

## Table Sample

<TableSample />


# stellar.contract_data
Source: https://docs.dune.com/data-catalog/stellar/contract_data

Stellar Soroban smart contract data entries.

## Table description

The `stellar.contract_data` table stores state data for smart contracts, including supported tokens and storage costs.

## Column Descriptions

| **Column**                 | **Description**                                                                 | **Type**                    |
| -------------------------- | ------------------------------------------------------------------------------- | --------------------------- |
| **closed\_at\_date**       | The date when the contract data entry was closed.                               | date                        |
| **contract\_id**           | The unique identifier for the smart contract on the Stellar network.            | varchar                     |
| **contract\_key\_type**    | The type of key used for the contract data (e.g., a hash or other identifier).  | varchar                     |
| **contract\_durability**   | Indicates whether the contract data is durable across contract executions.      | varchar                     |
| **asset\_code**            | The code of the asset associated with the contract (if applicable).             | varchar                     |
| **asset\_issuer**          | The issuer of the asset associated with the contract (if applicable).           | varchar                     |
| **asset\_type**            | The type of asset associated with the contract (e.g., native, issued).          | varchar                     |
| **balance\_holder**        | The account or entity that holds the balance associated with the contract.      | varchar                     |
| **balance**                | The balance associated with the contract, in lumens or other tokens.            | varchar                     |
| **last\_modified\_ledger** | The ledger sequence number where the contract data was last modified.           | bigint                      |
| **ledger\_entry\_change**  | Indicates the type of change made to the ledger entry (insert, update, delete). | bigint                      |
| **deleted**                | A boolean indicating whether the contract data entry has been deleted.          | boolean                     |
| **closed\_at**             | The timestamp when the contract data was closed.                                | timestamp(3) with time zone |
| **ledger\_sequence**       | The sequence number of the ledger in which the contract data is included.       | bigint                      |
| **ledger\_key\_hash**      | The hashed key associated with the contract's ledger entry.                     | varbinary                   |
| **key**                    | The key used in the contract data entry.                                        | varchar                     |
| **key\_decoded**           | A human-readable or decoded version of the contract key.                        | varchar                     |
| **val**                    | The value stored in the contract data entry.                                    | varchar                     |
| **val\_decoded**           | A human-readable or decoded version of the value stored in the contract.        | varchar                     |
| **contract\_data\_xdr**    | The raw XDR (External Data Representation) format of the contract data.         | varchar                     |
| **updated\_at**            | The time when the contract data record was last updated.                        | timestamp(3) with time zone |
| **ingested\_at**           | The time when the contract data was ingested into the system.                   | timestamp(3) with time zone |

## Table Sample

<TableSample />


# EVM vs Stellar Comparison
Source: https://docs.dune.com/data-catalog/stellar/evm_v_stellar

A comparison between EVM-based blockchains and Stellar

## EVM vs Stellar Comparison

This document provides a generalized overview of the differences between Ethereum Virtual Machine (EVM) chains and the Stellar Network. It's meant to help EVM data analysts to understand Stellar chain data better by mapping the concepts.

<Check>A special thanks to [Sydney Wiseman](https://www.linkedin.com/in/syd-wiseman/) from the Stellar Development Foundation for making this available to the community! </Check>

## Blockchain Purpose and Design

### Stellar

The Stellar Network is designed to create digital asset products and services that improve access to the global financial system. With a focus on **simplicity, speed, and cost-effectiveness** in transferring assets, Stellar connects financial institutions, payment systems, and individuals.

Due to its financial-centric design, Stellar includes built-in primitives for asset management, making it more secure and efficient for financial applications. However, Stellar's original design was less flexible and had limited the types of financial applications built on Stellar. Since February 2024, Stellar has supported **smart contracts** written in Rust and compiled as WebAssembly (wasm).

### EVM

EVM blockchains such as Ethereum allow developers to build decentralized applications (dApps) and deploy **smart contracts**. Unlike Stellar, EVM chains emphasize flexible programming at the cost of speed, leading to the need for layer-2 (L2) solutions to improve transaction throughput and cost efficiency. Smart contracts on EVM are written in Solidity.

### Stellar Native Primitives

* **Asset Issuance**
* **Claimable Balances (Airdrops)**
* **Orderbook (Built-in DEX)**
* **Automated Market Makers (AMMs)**

### Tokenization

Stellar allows native **asset tokenization**, where user balances are represented through [trustlines](https://developers.stellar.org/docs/learn/fundamentals/stellar-data-structures/accounts#trustlines). Standards for tokenization similar to ERC-20 and ERC-721 are available under [SEP-41](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0041.md), implemented via the [Stellar Asset Contract](https://developers.stellar.org/docs/smart-contracts/tokens/stellar-asset-contract).

### Consensus Mechanism

Stellar uses **Stellar Consensus Protocol (SCP)**, a Proof of Agreement (PoA) mechanism derived from **Federated Byzantine Agreement (FBA)**. Transactions are confirmed when overlapping quorums of nodes agree on validity. Stellar closes ledgers every **5 seconds**.

EVM chains like Ethereum use **Proof of Stake (PoS)** for consensus.

### Time to Finality

* **Stellar**: Deterministic finality, with ledgers closing every **5-6 seconds**.
* **Ethereum**: Probabilistic finality, requiring \~13 minutes (2 epochs) for finality.

### Submitting Transactions

Stellar supports bundling up to **100 operations** in a single transaction, improving developer experience. However, smart contract transactions (via **Soroban**) are capped at **1 operation per transaction**, similar to EVM.

Stellar allows [**fee bump transactions**](https://developers.stellar.org/docs/learn/encyclopedia/fee-bump-transactions), where an account can pay fees on behalf of another account. Additionally, [**26 operation types**](https://developers.stellar.org/docs/learn/fundamentals/list-of-operations) are natively supported on Stellar, in contrast to EVM's 3 core transaction types (regular, contract deployment, execute contract).

### Ledger State Comparison

Both Stellar and EVM use an **account-based model**. In Stellar, however, there are additional ledger state types:

* **Contracts**: Persistent data and expiration details for smart contracts
* **Accounts**: Externally owned accounts with lumen (XLM) balances
* **Trustlines**: Balances of non-native tokens
* **Claimable Balances**: Built-in airdrop feature
* **Liquidity Pools**: AMM built-in mechanisms
* **Orderbook Offers**: Stellar’s built-in decentralized exchange

| EVM's Accounts         | Stellar's Ledger Entry                                                                                                                                                                                                                |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| nonce                  | *No equivalent*                                                                                                                                                                                                                       |
| balance                | [accounts](https://developers.stellar.org/docs/learn/fundamentals/stellar-data-structures/accounts)                                                                                                                                   |
| storageRoot            | [trustLines](https://developers.stellar.org/docs/learn/fundamentals/stellar-data-structures/accounts#trustlines)                                                                                                                      |
| codeHash               | [data](https://developers.stellar.org/docs/learn/fundamentals/stellar-data-structures/accounts#subentries), [contractData](https://developers.stellar.org/docs/learn/fundamentals/stellar-data-structures/contracts#contract-storage) |
| *No native equivalent* | [contractCode](https://developers.stellar.org/docs/learn/fundamentals/stellar-data-structures/contracts#wasm)                                                                                                                         |
| *No native equivalent* | [claimableBalances](https://developers.stellar.org/docs/learn/encyclopedia/claimable-balances)                                                                                                                                        |
| *No native equivalent* | [liquidityPools](https://developers.stellar.org/docs/learn/encyclopedia/liquidity-on-stellar-sdex-liquidity-pools#liquidity-pools)                                                                                                    |
| *No native equivalent* | [offers](https://developers.stellar.org/docs/learn/encyclopedia/liquidity-on-stellar-sdex-liquidity-pools#order-books)                                                                                                                |
| *No native equivalent* | [configSetting](https://developers.stellar.org/network/core-node/admin-guide/soroban-settings)                                                                                                                                        |
| *No native equivalent* | [ttl](https://developers.stellar.org/docs/learn/smart-contract-internals/state-archival#ttl) (State Archival)                                                                                                                         |

### Data Concept Mapping

Stellar's data model is more complex than EVM due to its built-in primitives.

The table below outlines equivalent data structures between EVM chains and Stellar, which serves to map the concepts between the two networks:

| EVM's Data Model | Stellar Data On Dune                                                                   |
| ---------------- | -------------------------------------------------------------------------------------- |
| blocks           | [history\_ledgers](./history_ledgers)                                                  |
| transactions     | [history\_transactions](./history_transactions)                                        |
| logs             | [history\_contract\_events](./history_contract_events)                                 |
| traces           | [history\_operations](./history_operations), [history\_effects](./history_effects)     |
| contracts        | [contract\_data](./contract_data)                                                      |
| balances         | [accounts](./accounts), [trustlines](./trust_lines), [contract\_data](./contract_data) |
| token\_transfers | [history\_operations](./history_operations)                                            |

## Data Model Details

### Blocks

Stellar calls blocks, ledgers. A ledger represents the state of the Stellar network at a given point in time. EVM blockchains refer to state as a point in time as blocks, and the entire blockchain is “the ledger”. Ledgers on Stellar can refer to individual blocks or the full network history.

#### Size Limits

A transaction set within a ledger contains two transaction types: native and smart contracts. The ledger size has separate limits for each transaction type:

* **Native** - the Stellar Network can apply up to 1,000 operations in a ledger. Transactions can bundle up to 100 operations in a single transaction.
* **Smart contracts** - the Stellar Network dynamically limits the number of smart contract transactions based on network resources consumed (read/write bytes, CPU instructions, etc). See [Smart Contract Settings](https://developers.stellar.org/network/core-node/admin-guide/soroban-settings#examine-current-settings) for more details.
  See [Fees and Metering](https://developers.stellar.org/docs/learn/fundamentals/fees-resource-limits-metering) for more information.

Ethereum limits block size by total gas spent.

#### Schema Mapping

| **Stellar Name**           | **EVM Equivalent**  | **Description**                                                                                                                                                      |
| -------------------------- | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **sequence**               | number              | The sequence number of the ledger                                                                                                                                    |
| **ledger\_hash**           | hash                | The hash of this ledger                                                                                                                                              |
| **previous\_ledger\_hash** | parent\_hash        | The hash of the previous ledger                                                                                                                                      |
| **closed\_at**             | time                | The timestamp when the ledger was written to the chain                                                                                                               |
| **protocol\_version**      | version             | Protocol version specified in the block header                                                                                                                       |
| **total\_coins**           |                     | The total number of lumens in circulation                                                                                                                            |
| **fee\_pool**              | gas\_used           | The sum of all transaction fees                                                                                                                                      |
| **inflation\_seq**         |                     | *Deprecated*                                                                                                                                                         |
| **base\_fee**              | base\_fee\_per\_gas | The minimum fee charged, per operation, to be included in the ledger                                                                                                 |
| **base\_reserve**          |                     | The minimum XLM balance to be held in an account to be considered valid                                                                                              |
| **max\_tx\_set\_size**     | gas\_limit          | The maximum number of non-Soroban operations allowed in a ledger. **Note**: Soroban transactions have a separate mechanism to limit resources utilization per ledger |
| **ledger\_header**         |                     | The raw XDR representation of all the data stored in the [Ledger Header](https://pkg.go.dev/github.com/stellar/go/xdr#LedgerHeader)                                  |
| **transaction\_count**     | transaction\_count  | Number of transactions in the ledger                                                                                                                                 |
| **operation\_count**       |                     | The number of operations in the ledger. **Note**: Up to 100 operations can be bundled in a single transaction                                                        |

### Transactions

Actions are performed on the Stellar network through operations. Operations are bundled into transactions, with each account able to perform up to 100 operations in a single transaction. Accounts are limited to submitting one transaction per ledger.

EVM networks do not have the concept of operations, the lowest level of action is a transaction. This limits accounts to one action per transaction in EVM L1 Layers, which is why L2 solutions and rollups are popular.

#### Transaction Types

Operation types on Stellar are analog to transaction types on EVM networks.

The Stellar network natively supports [26 operation types](https://developers.stellar.org/docs/learn/fundamentals/list-of-operations), ranging from payments to orderbook offer management to smart contract invocation.

EVM natively supports 3 transaction types: payment (regular), contract deployment, and execute contract, and does not support natively for Orderbook or AMMs.

#### Schema Mapping

**Transactions**

| **Stellar Name**               | **EVM Equivalent** | **Description**                                                                                                                                                                                                                           |
| ------------------------------ | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **transaction\_hash**          | hash               | A hex-encoded SHA-256 hash of this transaction's XDR-encoded form                                                                                                                                                                         |
| **ledger\_sequence**           | block\_number      | The sequence number of the ledger                                                                                                                                                                                                         |
| **closed\_at**                 | block\_time        | The timestamp when the ledger was written to the chain                                                                                                                                                                                    |
| **inner\_transaction\_hash**   |                    | A transaction hash of a transaction wrapped with its signatures for fee-bump transactions                                                                                                                                                 |
| **account**                    | from               | The account address that originates the transaction                                                                                                                                                                                       |
| **account\_sequence**          | nonce              | The source account's sequence number that this transaction consumed. Sequence numbers can only be used once and help maintain atomicity and idempotency on the network                                                                    |
| **max\_fee**                   | max\_fee\_per\_gas | The maximum fee (in stroops) that the account is willing to pay for the transaction to be included in a ledger                                                                                                                            |
| **operation\_count**           | Fixed at 1         | The number of operations contained within this transaction                                                                                                                                                                                |
| **memo\_type**                 |                    | Memos can be text, ids, or hashes                                                                                                                                                                                                         |
| **memo**                       |                    | Optional unstructured data field that can be used to differentiate between accounts (for pooled accounts)                                                                                                                                 |
| **time\_bounds**               |                    | Optional UNIX timestamp of a lower and upper bound of when a transaction will be valid                                                                                                                                                    |
| **successful**                 | success            | Indicates if the transaction succeeded                                                                                                                                                                                                    |
| **fee\_charged**               | gas\_used          |                                                                                                                                                                                                                                           |
| **fee\_account**               |                    | An account that is not the originating source account for a transaction is allowed to pay transaction fees on behalf of the source account. These accounts are called fee accounts and incur all transaction costs for the source account |
| **new\_max\_fee**              |                    | The maximum fee (in stroops) an account is willing to pay for this account’s fees                                                                                                                                                         |
| **account\_muxed**             |                    | If the user has defined multiplexed (muxed) accounts, the account exists "virtually" under a traditional Stellar account address. This address distinguishes between the virtual accounts                                                 |
| **fee\_account\_muxed**        |                    | If the fee account that sponsors fee is a multiplexed account, the virtual address will be listed here                                                                                                                                    |
| **preconditions**              |                    | Validity checks the account can add when submitting a transaction to the network. If the conditions are not met, the transaction fails                                                                                                    |
| **transaction\_envelope**      | input\_data        | The raw XDR that was submitted to the Stellar Network                                                                                                                                                                                     |
| **transaction\_result**        | receipt\_root      | The raw XDR that is returned from the network after applying the transaction                                                                                                                                                              |
| **transaction\_meta**          | input\_data        | Raw XDR of ledger state changes based on the application of the transaction                                                                                                                                                               |
| **transaction\_fee\_meta**     | input\_data        |                                                                                                                                                                                                                                           |
| **soroban\_transaction\_data** | traces             | Host env resource consumption by smart contract transactions                                                                                                                                                                              |
| **transaction\_result\_code**  | traces.error       | Result code that includes error codes for failed transactions                                                                                                                                                                             |
| **inclusion\_fee\_charged**    | gas\_price         | The fee charged for the transaction to be included in the ledger. This is a fixed fee for the entire ledger and starts at a minimum of 100 stroops. The fee increases based on demand                                                     |
| **signatures**                 | signature          |                                                                                                                                                                                                                                           |

**Operations**

| **Stellar Name**            | **EVM Equivalent**           | **Description**                                                                                                                      |
| --------------------------- | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| **id**                      |                              | Unique id for the operation                                                                                                          |
| **source\_account**         | transaction.from             | The account address that originates the transaction                                                                                  |
| **transaction\_id**         |                              | Unique ID for the transaction. Bundled operation IDs will share the same Transaction ID                                              |
| **type**                    | transaction.type             | Operation type                                                                                                                       |
| **details**                 | Mix of input data and traces | Unstructured JSON that contains details based on the type of operation executed. Each operation will return its own relevant details |
| **operation\_result\_code** | traces                       |                                                                                                                                      |
| **operation\_trace\_code**  | traces                       |                                                                                                                                      |

### Logs and Traces

Events are the mechanism that applications off-chain can use to monitor changes and events in contracts on-chain. Events are an amalgamation of both EVM logs and traces.

Stellar has three types of smart contract events:

* **contract** - events emitted by contracts to convey state changes
* **system** - events emitted by the host environment itself
* **diagnostic** - details transaction traces intended for debugging purposes

#### Schema Mapping

| **Stellar Name**                   | **EVM Equivalent** | **Description**                                               |
| ---------------------------------- | ------------------ | ------------------------------------------------------------- |
| **type**                           | trace.type         | The type of event emission                                    |
| **ledger**                         | block\_number      | The sequence number of the ledger                             |
| **closed\_at**                     | block\_time        | The timestamp when the ledger was written to the chain        |
| **contract\_id**                   | contract\_address  | String key representation of the contract address             |
| **id**                             | transaction\_index | Unique ID for the event                                       |
| **in\_successful\_contract\_call** | trace.tx\_success  | Whether the event was emitted from a successful contract call |
| **topic**                          | logs.topic\_list   | Topic list of events                                          |
| **value**                          | logs.data          | The body values of the topic list                             |
| **transaction\_hash**              | trace.tx\_hash     | The transaction which triggered this event                    |


# stellar.history_contract_events
Source: https://docs.dune.com/data-catalog/stellar/history_contract_events

Stellar Soroban contract events — events emitted by smart contracts.

## Table description

The `stellar.history_contract_events` table captures all smart contract events and traces, with details on contract execution.

## Column Descriptions

| **Column**                         | **Description**                                                                                            | **Type**                    |
| ---------------------------------- | ---------------------------------------------------------------------------------------------------------- | --------------------------- |
| **closed\_at\_date**               | The date when the contract event entry was closed.                                                         | date                        |
| **transaction\_hash**              | The hash of the transaction associated with the contract event, in binary format.                          | varbinary                   |
| **transaction\_id**                | The unique identifier for the transaction related to the contract event.                                   | bigint                      |
| **successful**                     | Indicates whether the transaction associated with the contract event was successful.                       | boolean                     |
| **in\_successful\_contract\_call** | Indicates whether the event occurred during a successful contract call.                                    | boolean                     |
| **contract\_id**                   | The unique identifier for the smart contract that emitted the event.                                       | varchar                     |
| **type**                           | The numeric representation of the event type.                                                              | bigint                      |
| **type\_string**                   | The string description of the event type.                                                                  | varchar                     |
| **topics**                         | Encoded topics related to the contract event, typically used for filtering and categorizing events.        | varchar                     |
| **topics\_decoded**                | Human-readable or decoded topics related to the contract event.                                            | varchar                     |
| **data**                           | The data associated with the contract event, often related to the state changes or values in the contract. | varchar                     |
| **data\_decoded**                  | A human-readable or decoded version of the event data.                                                     | varchar                     |
| **contract\_event\_xdr**           | The raw XDR (External Data Representation) format of the contract event.                                   | varchar                     |
| **closed\_at**                     | The timestamp when the contract event entry was closed.                                                    | timestamp(3) with time zone |
| **ledger\_sequence**               | The sequence number of the ledger in which the contract event is included.                                 | bigint                      |
| **updated\_at**                    | The time when the contract event record was last updated.                                                  | timestamp(3) with time zone |
| **ingested\_at**                   | The time when the contract event data was ingested into the system.                                        | timestamp(3) with time zone |

## Table Sample

<TableSample />


# stellar.history_effects
Source: https://docs.dune.com/data-catalog/stellar/history_effects

Stellar operation effects — balance changes, trustline modifications, and other state changes.

## Table description

The `stellar.history_effects` table records specific changes that occur in the ledger as a result of successful operations, but are not necessarily directly reflected in the ledger or history, as transactions and operations are.

Operations are objects that represent a desired change to the ledger: payments, offers to exchange currency, changes made to account options, etc. Operations are submitted to the Stellar network grouped in a Transaction. Each of Stellar’s operations have a unique operation object.

## Column Descriptions

| **Column**                                      | **Description**                                                                                    | **Type**                                                                                                                                                                 |
| ----------------------------------------------- | -------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **closed\_at\_date**                            | The date when the effect was closed.                                                               | date                                                                                                                                                                     |
| **address**                                     | The account address associated with the effect.                                                    | varchar                                                                                                                                                                  |
| **address\_muxed**                              | The multiplexed address, if applicable.                                                            | varchar                                                                                                                                                                  |
| **operation\_id**                               | The unique identifier for the operation that produced the effect.                                  | bigint                                                                                                                                                                   |
| **type**                                        | The numeric representation of the effect type.                                                     | bigint                                                                                                                                                                   |
| **type\_string**                                | The string description of the effect type.                                                         | varchar                                                                                                                                                                  |
| **closed\_at**                                  | The timestamp when the effect was closed.                                                          | timestamp(3) with time zone                                                                                                                                              |
| **ledger\_sequence**                            | The sequence number of the ledger in which the effect is included.                                 | bigint                                                                                                                                                                   |
| **index**                                       | The index of the effect within the operation.                                                      | bigint                                                                                                                                                                   |
| **id**                                          | The unique identifier for the effect.                                                              | varchar                                                                                                                                                                  |
| **liquidity\_pool**                             | Information about the liquidity pool related to the effect, including fee, ID, reserves, and type. | row("fee\_bp" bigint,"id" varchar,"total\_shares" decimal(38,9),"total\_trustlines" bigint,"type" varchar,"reserves" array(row("asset" varchar,"amount" decimal(38,9)))) |
| **reserves\_received**                          | An array of reserves received in the liquidity pool operation.                                     | array(row("asset" varchar,"amount" decimal(38,9)))                                                                                                                       |
| **reserves\_deposited**                         | An array of reserves deposited in the liquidity pool operation.                                    | array(row("asset" varchar,"amount" decimal(38,9)))                                                                                                                       |
| **reserves\_revoked**                           | An array of revoked reserves in the liquidity pool, including claimable balance IDs.               | array(row("asset" varchar,"amount" decimal(38,9),"claimable\_balance\_id" varchar))                                                                                      |
| **bought**                                      | An array of assets bought during the operation.                                                    | array(row("asset" varchar,"amount" decimal(38,9)))                                                                                                                       |
| **sold**                                        | An array of assets sold during the operation.                                                      | array(row("asset" varchar,"amount" decimal(38,9)))                                                                                                                       |
| **shares\_revoked**                             | The number of shares revoked in the liquidity pool.                                                | decimal(38,9)                                                                                                                                                            |
| **shares\_received**                            | The number of shares received in the liquidity pool.                                               | decimal(38,9)                                                                                                                                                            |
| **shares\_redeemed**                            | The number of shares redeemed in the liquidity pool.                                               | decimal(38,9)                                                                                                                                                            |
| **liquidity\_pool\_id**                         | The ID of the liquidity pool related to the effect.                                                | varchar                                                                                                                                                                  |
| **balance\_id**                                 | The ID of the balance affected by the effect.                                                      | varchar                                                                                                                                                                  |
| **new\_seq**                                    | The new sequence number for the account.                                                           | bigint                                                                                                                                                                   |
| **name**                                        | The name associated with the effect.                                                               | varchar                                                                                                                                                                  |
| **value**                                       | The value associated with the effect.                                                              | varchar                                                                                                                                                                  |
| **trustor**                                     | The account ID of the trustor involved in the effect.                                              | varchar                                                                                                                                                                  |
| **limit**                                       | The limit associated with the trustline in the effect.                                             | decimal(38,9)                                                                                                                                                            |
| **inflation\_destination**                      | The destination account for inflation in the effect.                                               | varchar                                                                                                                                                                  |
| **authorized\_flag**                            | A boolean indicating whether the asset was authorized.                                             | boolean                                                                                                                                                                  |
| **auth\_immutable\_flag**                       | A boolean indicating whether the asset is immutable.                                               | boolean                                                                                                                                                                  |
| **authorized\_to\_maintain\_liabilities**       | A boolean indicating whether authorization to maintain liabilities was granted.                    | boolean                                                                                                                                                                  |
| **auth\_revocable\_flag**                       | A boolean indicating whether the authorization is revocable.                                       | boolean                                                                                                                                                                  |
| **auth\_required\_flag**                        | A boolean indicating whether authorization is required.                                            | boolean                                                                                                                                                                  |
| **auth\_clawback\_enabled\_flag**               | A boolean indicating whether clawback is enabled for the effect.                                   | boolean                                                                                                                                                                  |
| **claimable\_balance\_clawback\_enabled\_flag** | A boolean indicating whether clawback is enabled for claimable balances.                           | boolean                                                                                                                                                                  |
| **clawback\_enabled\_flag**                     | A boolean indicating whether clawback is enabled for the asset.                                    | boolean                                                                                                                                                                  |
| **high\_threshold**                             | The high threshold for account signatures.                                                         | bigint                                                                                                                                                                   |
| **med\_threshold**                              | The medium threshold for account signatures.                                                       | bigint                                                                                                                                                                   |
| **low\_threshold**                              | The low threshold for account signatures.                                                          | bigint                                                                                                                                                                   |
| **home\_domain**                                | The home domain associated with the account.                                                       | varchar                                                                                                                                                                  |
| **asset\_issuer**                               | The issuer of the asset involved in the effect.                                                    | varchar                                                                                                                                                                  |
| **asset**                                       | The asset involved in the effect.                                                                  | varchar                                                                                                                                                                  |
| **asset\_code**                                 | The code of the asset involved in the effect.                                                      | varchar                                                                                                                                                                  |
| **signer**                                      | The signer involved in the effect.                                                                 | varchar                                                                                                                                                                  |
| **sponsor**                                     | The sponsor of the account or effect.                                                              | varchar                                                                                                                                                                  |
| **new\_sponsor**                                | The new sponsor of the account or effect.                                                          | varchar                                                                                                                                                                  |
| **former\_sponsor**                             | The former sponsor of the account or effect.                                                       | varchar                                                                                                                                                                  |
| **weight**                                      | The weight assigned to the signer.                                                                 | bigint                                                                                                                                                                   |
| **public\_key**                                 | The public key associated with the effect.                                                         | varchar                                                                                                                                                                  |
| **asset\_type**                                 | The type of asset involved in the effect.                                                          | varchar                                                                                                                                                                  |
| **amount**                                      | The amount involved in the effect.                                                                 | decimal(38,9)                                                                                                                                                            |
| **starting\_balance**                           | The starting balance of the account in the effect.                                                 | decimal(38,9)                                                                                                                                                            |
| **seller**                                      | The account ID of the seller in the effect.                                                        | varchar                                                                                                                                                                  |
| **seller\_muxed**                               | The multiplexed account ID of the seller, if applicable.                                           | varchar                                                                                                                                                                  |
| **seller\_muxed\_id**                           | The ID of the multiplexed seller account.                                                          | bigint                                                                                                                                                                   |
| **offer\_id**                                   | The ID of the offer involved in the effect.                                                        | bigint                                                                                                                                                                   |
| **sold\_amount**                                | The amount of the asset sold in the effect.                                                        | decimal(38,9)                                                                                                                                                            |
| **sold\_asset\_type**                           | The type of asset sold in the effect.                                                              | varchar                                                                                                                                                                  |
| **sold\_asset\_code**                           | The code of the asset sold in the effect.                                                          | varchar                                                                                                                                                                  |
| **sold\_asset\_issuer**                         | The issuer of the asset sold in the effect.                                                        | varchar                                                                                                                                                                  |
| **bought\_amount**                              | The amount of the asset bought in the effect.                                                      | decimal(38,9)                                                                                                                                                            |
| **bought\_asset\_type**                         | The type of asset bought in the effect.                                                            | varchar                                                                                                                                                                  |
| **bought\_asset\_code**                         | The code of the asset bought in the effect.                                                        | varchar                                                                                                                                                                  |
| **data\_name**                                  | The name of the data involved in the effect.                                                       | varchar                                                                                                                                                                  |
| **bought\_asset\_issuer**                       | The issuer of the asset bought in the effect.                                                      | varchar                                                                                                                                                                  |
| **entries**                                     | An array of entries involved in the effect.                                                        | array(varchar)                                                                                                                                                           |
| **extend\_to**                                  | The ledger sequence number to which the effect extends.                                            | bigint                                                                                                                                                                   |
| **contract**                                    | The contract associated with the effect.                                                           | varchar                                                                                                                                                                  |
| **contract\_event\_type**                       | The type of contract event associated with the effect.                                             | varchar                                                                                                                                                                  |
| **ledgers\_to\_expire**                         | The number of ledgers until the effect expires.                                                    | bigint                                                                                                                                                                   |
| **updated\_at**                                 | The time when the effect record was last updated.                                                  | timestamp(3) with time zone                                                                                                                                              |
| **ingested\_at**                                | The time when the effect data was ingested into the system.                                        | timestamp(3) with time zone                                                                                                                                              |

## Table Sample

<TableSample />


# stellar.history_ledgers
Source: https://docs.dune.com/data-catalog/stellar/history_ledgers

Stellar ledger data — sequence number, transaction count, and protocol version.

## Table description

The `stellar.history_ledgers` table tracks ledgers info (equivalent of blocks on other blockchain), including metadata such as sequence numbers, transactions included, and fees.

## Column Descriptions

| **Column**                              | **Description**                                                                     | **Type**                    |
| --------------------------------------- | ----------------------------------------------------------------------------------- | --------------------------- |
| **closed\_at\_date**                    | The date when the ledger was closed.                                                | date                        |
| **sequence**                            | The sequence number of the ledger.                                                  | bigint                      |
| **ledger\_hash**                        | The hash of the current ledger, in binary format.                                   | varbinary                   |
| **previous\_ledger\_hash**              | The hash of the previous ledger, in binary format.                                  | varbinary                   |
| **transaction\_count**                  | The number of transactions included in the ledger.                                  | bigint                      |
| **operation\_count**                    | The number of operations executed within the transactions in the ledger.            | bigint                      |
| **closed\_at**                          | The timestamp when the ledger was closed.                                           | timestamp(3) with time zone |
| **id**                                  | The unique identifier for the ledger entry.                                         | bigint                      |
| **total\_coins**                        | The total number of lumens (XLM) in circulation at the time the ledger was closed.  | bigint                      |
| **fee\_pool**                           | The sum of all transaction fees accumulated in the ledger.                          | bigint                      |
| **base\_fee**                           | The minimum fee, in lumens (XLM), charged per operation included in the ledger.     | bigint                      |
| **base\_reserve**                       | The minimum XLM balance required to maintain an account, as defined in the ledger.  | bigint                      |
| **max\_tx\_set\_size**                  | The maximum number of transactions that can be included in a ledger.                | bigint                      |
| **protocol\_version**                   | The protocol version used by the ledger.                                            | bigint                      |
| **ledger\_header**                      | The raw binary (XDR) representation of the ledger header.                           | varbinary                   |
| **successful\_transaction\_count**      | The number of successful transactions in the ledger.                                | bigint                      |
| **failed\_transaction\_count**          | The number of failed transactions in the ledger.                                    | bigint                      |
| **tx\_set\_operation\_count**           | The total number of operations in the transaction set of the ledger.                | bigint                      |
| **soroban\_fee\_write\_1kb**            | The fee in lumens (XLM) for writing 1KB of data related to Soroban smart contracts. | bigint                      |
| **node\_id**                            | The identifier of the node that signed and validated the ledger.                    | varchar                     |
| **signature**                           | The digital signature applied to the ledger by the validating node.                 | varchar                     |
| **total\_byte\_size\_of\_bucket\_list** | The total byte size of the ledger's bucket list, which tracks state changes.        | bigint                      |
| **updated\_at**                         | The time when the ledger record was last updated.                                   | timestamp(3) with time zone |
| **ingested\_at**                        | The time when the ledger data was ingested into the system.                         | timestamp(3) with time zone |

## Table Sample

<TableSample />


# stellar.history_operations
Source: https://docs.dune.com/data-catalog/stellar/history_operations

Stellar operations — payments, offers, account changes, and other operation types.

## Table description

The `stellar.history_operations` table tracks operational details of transaction in ledgers/blocks.

Operations are objects that represent a desired change to the ledger: payments, offers to exchange currency, changes made to account options, etc. Operations are submitted to the Stellar network grouped in a Transaction. Each of Stellar’s operations have a unique operation object.

## Column Descriptions

| **Column**                               | **Description**                                                                  | **Type**                                                                                                                                   |
| ---------------------------------------- | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| **closed\_at\_date**                     | The date when the operation was closed.                                          | date                                                                                                                                       |
| **id**                                   | The unique identifier for the operation.                                         | bigint                                                                                                                                     |
| **source\_account**                      | The account that initiated the operation.                                        | varchar                                                                                                                                    |
| **source\_account\_muxed**               | The multiplexed source account address, if applicable.                           | varchar                                                                                                                                    |
| **transaction\_id**                      | The unique identifier for the transaction that includes the operation.           | bigint                                                                                                                                     |
| **type**                                 | The numeric representation of the operation type.                                | bigint                                                                                                                                     |
| **type\_string**                         | The string description of the operation type.                                    | varchar                                                                                                                                    |
| **closed\_at**                           | The timestamp when the operation was closed.                                     | timestamp(3) with time zone                                                                                                                |
| **operation\_result\_code**              | The result code indicating the outcome of the operation.                         | varchar                                                                                                                                    |
| **operation\_trace\_code**               | The trace code detailing the operation's execution.                              | varchar                                                                                                                                    |
| **ledger\_sequence**                     | The sequence number of the ledger in which the operation is included.            | bigint                                                                                                                                     |
| **account**                              | The account address associated with the operation.                               | varchar                                                                                                                                    |
| **account\_muxed**                       | The multiplexed account address, if applicable.                                  | varchar                                                                                                                                    |
| **account\_muxed\_id**                   | The ID of the multiplexed account, if applicable.                                | varchar                                                                                                                                    |
| **account\_id**                          | The unique identifier for the account involved in the operation.                 | varchar                                                                                                                                    |
| **amount**                               | The amount of the asset transferred or affected by the operation.                | double                                                                                                                                     |
| **asset**                                | The asset involved in the operation.                                             | varchar                                                                                                                                    |
| **asset\_code**                          | The code of the asset involved in the operation.                                 | varchar                                                                                                                                    |
| **asset\_issuer**                        | The issuer of the asset involved in the operation.                               | varchar                                                                                                                                    |
| **asset\_id**                            | The unique identifier for the asset.                                             | bigint                                                                                                                                     |
| **asset\_type**                          | The type of asset involved in the operation.                                     | varchar                                                                                                                                    |
| **authorize**                            | A boolean indicating whether authorization was given for the operation.          | boolean                                                                                                                                    |
| **balance\_id**                          | The ID of the balance affected by the operation.                                 | varchar                                                                                                                                    |
| **buying\_asset\_code**                  | The code of the asset being bought in the operation.                             | varchar                                                                                                                                    |
| **buying\_asset\_issuer**                | The issuer of the asset being bought in the operation.                           | varchar                                                                                                                                    |
| **buying\_asset\_id**                    | The unique identifier for the asset being bought.                                | bigint                                                                                                                                     |
| **buying\_asset\_type**                  | The type of asset being bought in the operation.                                 | varchar                                                                                                                                    |
| **claimable\_balance\_id**               | The ID of the claimable balance involved in the operation.                       | varchar                                                                                                                                    |
| **claimant**                             | The account address of the claimant.                                             | varchar                                                                                                                                    |
| **claimant\_muxed**                      | The multiplexed account of the claimant, if applicable.                          | varchar                                                                                                                                    |
| **claimant\_muxed\_id**                  | The ID of the multiplexed claimant account, if applicable.                       | varchar                                                                                                                                    |
| **data\_account\_id**                    | The account ID for the account where data is being modified.                     | varchar                                                                                                                                    |
| **data\_name**                           | The name of the data being modified in the operation.                            | varchar                                                                                                                                    |
| **from**                                 | The account address sending the asset in the operation.                          | varchar                                                                                                                                    |
| **from\_muxed**                          | The multiplexed sender account, if applicable.                                   | varchar                                                                                                                                    |
| **from\_muxed\_id**                      | The ID of the multiplexed sender account, if applicable.                         | varchar                                                                                                                                    |
| **funder**                               | The account funding the operation.                                               | varchar                                                                                                                                    |
| **funder\_muxed**                        | The multiplexed funder account, if applicable.                                   | varchar                                                                                                                                    |
| **funder\_muxed\_id**                    | The ID of the multiplexed funder account, if applicable.                         | varchar                                                                                                                                    |
| **high\_threshold**                      | The high threshold required for the operation.                                   | bigint                                                                                                                                     |
| **home\_domain**                         | The home domain associated with the account.                                     | varchar                                                                                                                                    |
| **inflation\_dest**                      | The destination account for inflation pools.                                     | varchar                                                                                                                                    |
| **into**                                 | The account receiving the asset in the operation.                                | varchar                                                                                                                                    |
| **into\_muxed**                          | The multiplexed account receiving the asset, if applicable.                      | varchar                                                                                                                                    |
| **into\_muxed\_id**                      | The ID of the multiplexed recipient account, if applicable.                      | varchar                                                                                                                                    |
| **limit**                                | The limit of the trustline or balance change.                                    | double                                                                                                                                     |
| **low\_threshold**                       | The low threshold required for the operation.                                    | bigint                                                                                                                                     |
| **master\_key\_weight**                  | The weight of the master key for signing transactions.                           | bigint                                                                                                                                     |
| **med\_threshold**                       | The medium threshold required for the operation.                                 | bigint                                                                                                                                     |
| **name**                                 | The name associated with the operation or account.                               | varchar                                                                                                                                    |
| **offer\_id**                            | The ID of the offer related to the operation.                                    | bigint                                                                                                                                     |
| **path**                                 | The payment path used in the operation.                                          | array(row("asset\_code" varchar,"asset\_issuer" varchar,"asset\_type" varchar))                                                            |
| **price**                                | The price of the asset involved in the operation.                                | double                                                                                                                                     |
| **price\_r**                             | The rational price of the asset (fraction of numerator and denominator).         | row("d" bigint,"n" bigint)                                                                                                                 |
| **selling\_asset\_code**                 | The code of the asset being sold in the operation.                               | varchar                                                                                                                                    |
| **selling\_asset\_issuer**               | The issuer of the asset being sold in the operation.                             | varchar                                                                                                                                    |
| **selling\_asset\_id**                   | The unique identifier for the asset being sold.                                  | bigint                                                                                                                                     |
| **selling\_asset\_type**                 | The type of asset being sold in the operation.                                   | varchar                                                                                                                                    |
| **set\_flags**                           | An array of flags being set by the operation.                                    | array(bigint)                                                                                                                              |
| **set\_flags\_s**                        | An array of string descriptions for the flags being set.                         | array(varchar)                                                                                                                             |
| **signer\_account\_id**                  | The account ID of the signer.                                                    | varchar                                                                                                                                    |
| **signer\_key**                          | The key of the signer being modified.                                            | varchar                                                                                                                                    |
| **signer\_weight**                       | The weight assigned to the signer.                                               | bigint                                                                                                                                     |
| **source\_amount**                       | The source amount for the operation.                                             | double                                                                                                                                     |
| **source\_asset\_code**                  | The code of the source asset in the operation.                                   | varchar                                                                                                                                    |
| **source\_asset\_issuer**                | The issuer of the source asset in the operation.                                 | varchar                                                                                                                                    |
| **source\_asset\_id**                    | The unique identifier for the source asset.                                      | bigint                                                                                                                                     |
| **source\_asset\_type**                  | The type of source asset in the operation.                                       | varchar                                                                                                                                    |
| **source\_max**                          | The maximum amount of the source asset allowed in the operation.                 | double                                                                                                                                     |
| **starting\_balance**                    | The starting balance for the account in the operation.                           | double                                                                                                                                     |
| **to**                                   | The account receiving the asset.                                                 | varchar                                                                                                                                    |
| **to\_muxed**                            | The multiplexed account receiving the asset, if applicable.                      | varchar                                                                                                                                    |
| **to\_muxed\_id**                        | The ID of the multiplexed recipient account, if applicable.                      | varchar                                                                                                                                    |
| **trustee**                              | The trustee account involved in the operation.                                   | varchar                                                                                                                                    |
| **trustee\_muxed**                       | The multiplexed trustee account, if applicable.                                  | varchar                                                                                                                                    |
| **trustee\_muxed\_id**                   | The ID of the multiplexed trustee account, if applicable.                        | varchar                                                                                                                                    |
| **trustline\_account\_id**               | The account ID associated with the trustline in the operation.                   | varchar                                                                                                                                    |
| **trustline\_asset**                     | The asset involved in the trustline operation.                                   | varchar                                                                                                                                    |
| **trustor**                              | The trustor account in the operation.                                            | varchar                                                                                                                                    |
| **trustor\_muxed**                       | The multiplexed trustor account, if applicable.                                  | varchar                                                                                                                                    |
| **trustor\_muxed\_id**                   | The ID of the multiplexed trustor account, if applicable.                        | varchar                                                                                                                                    |
| **value**                                | The value associated with the operation.                                         | varchar                                                                                                                                    |
| **clear\_flags**                         | An array of flags being cleared by the operation.                                | array(bigint)                                                                                                                              |
| **clear\_flags\_s**                      | An array of string descriptions for the flags being cleared.                     | array(varchar)                                                                                                                             |
| **destination\_min**                     | The minimum destination amount in the operation.                                 | varchar                                                                                                                                    |
| **bump\_to**                             | The sequence number to which the operation bumps.                                | varchar                                                                                                                                    |
| **authorize\_to\_maintain\_liabilities** | A boolean indicating whether authorization is granted to maintain liabilities.   | boolean                                                                                                                                    |
| **clawback\_enabled**                    | A boolean indicating whether clawback is enabled for the operation.              | boolean                                                                                                                                    |
| **sponsor**                              | The account sponsoring the operation.                                            | varchar                                                                                                                                    |
| **sponsored\_id**                        | The ID of the sponsored account.                                                 | varchar                                                                                                                                    |
| **begin\_sponsor**                       | The sponsor that initiated the operation.                                        | varchar                                                                                                                                    |
| **begin\_sponsor\_muxed**                | The multiplexed sponsor account, if applicable.                                  | varchar                                                                                                                                    |
| **begin\_sponsor\_muxed\_id**            | The ID of the multiplexed sponsor account, if applicable.                        | varchar                                                                                                                                    |
| **liquidity\_pool\_id**                  | The liquidity pool ID associated with the operation.                             | varchar                                                                                                                                    |
| **reserve\_a\_asset\_type**              | The type of the first reserve asset in the liquidity pool operation.             | varchar                                                                                                                                    |
| **reserve\_a\_asset\_code**              | The code of the first reserve asset in the liquidity pool operation.             | varchar                                                                                                                                    |
| **reserve\_a\_asset\_issuer**            | The issuer of the first reserve asset in the liquidity pool operation.           | varchar                                                                                                                                    |
| **reserve\_a\_asset\_id**                | The unique identifier for the first reserve asset.                               | bigint                                                                                                                                     |
| **reserve\_a\_max\_amount**              | The maximum amount of the first reserve asset in the operation.                  | double                                                                                                                                     |
| **reserve\_a\_deposit\_amount**          | The amount of the first reserve asset deposited in the operation.                | double                                                                                                                                     |
| **reserve\_b\_asset\_type**              | The type of the second reserve asset in the liquidity pool operation.            | varchar                                                                                                                                    |
| **reserve\_b\_asset\_code**              | The code of the second reserve asset in the liquidity pool operation.            | varchar                                                                                                                                    |
| **reserve\_b\_asset\_issuer**            | The issuer of the second reserve asset in the liquidity pool operation.          | varchar                                                                                                                                    |
| **reserve\_b\_asset\_id**                | The unique identifier for the second reserve asset.                              | bigint                                                                                                                                     |
| **reserve\_b\_max\_amount**              | The maximum amount of the second reserve asset in the operation.                 | double                                                                                                                                     |
| **reserve\_b\_deposit\_amount**          | The amount of the second reserve asset deposited in the operation.               | double                                                                                                                                     |
| **min\_price**                           | The minimum price of the asset in the operation.                                 | double                                                                                                                                     |
| **min\_price\_r**                        | The rational minimum price of the asset (fraction of numerator and denominator). | array(row("d" bigint,"n" bigint))                                                                                                          |
| **max\_price**                           | The maximum price of the asset in the operation.                                 | double                                                                                                                                     |
| **max\_price\_r**                        | The rational maximum price of the asset (fraction of numerator and denominator). | array(row("d" bigint,"n" bigint))                                                                                                          |
| **shares\_received**                     | The number of shares received in the liquidity pool operation.                   | double                                                                                                                                     |
| **reserve\_a\_min\_amount**              | The minimum amount of the first reserve asset in the operation.                  | double                                                                                                                                     |
| **reserve\_a\_withdraw\_amount**         | The amount of the first reserve asset withdrawn in the operation.                | double                                                                                                                                     |
| **reserve\_b\_min\_amount**              | The minimum amount of the second reserve asset in the operation.                 | double                                                                                                                                     |
| **reserve\_b\_withdraw\_amount**         | The amount of the second reserve asset withdrawn in the operation.               | double                                                                                                                                     |
| **shares**                               | The number of shares involved in the liquidity pool operation.                   | double                                                                                                                                     |
| **asset\_balance\_changes**              | An array of asset balance changes related to the operation.                      | array(row("amount" double,"asset\_code" varchar,"asset\_issuer" varchar,"asset\_type" varchar,"from" varchar,"to" varchar,"type" varchar)) |
| **parameters**                           | An array of parameters associated with the operation.                            | array(row("type" varchar,"value" varchar))                                                                                                 |
| **parameters\_decoded**                  | An array of decoded parameters associated with the operation.                    | array(row("type" varchar,"value" varchar))                                                                                                 |
| **function**                             | The function executed in the operation.                                          | varchar                                                                                                                                    |
| **address**                              | The address associated with the operation.                                       | varchar                                                                                                                                    |
| **extend\_to**                           | The sequence number to which the operation extends.                              | bigint                                                                                                                                     |
| **contract\_id**                         | The contract ID associated with the operation.                                   | varchar                                                                                                                                    |
| **contract\_code\_hash**                 | The hash of the contract code associated with the operation.                     | varchar                                                                                                                                    |
| **ledger\_key\_hash**                    | An array of hashes for the ledger keys associated with the operation.            | array(varchar)                                                                                                                             |
| **ledgers\_to\_expire**                  | The number of ledgers until the operation expires.                               | bigint                                                                                                                                     |
| **soroban\_operation\_type**             | The type of operation for Soroban smart contracts.                               | varchar                                                                                                                                    |
| **updated\_at**                          | The time when the operation record was last updated.                             | timestamp(3) with time zone                                                                                                                |
| **ingested\_at**                         | The time when the operation data was ingested into the system.                   | timestamp(3) with time zone                                                                                                                |

## Table Sample

<TableSample />


# stellar.history_trades
Source: https://docs.dune.com/data-catalog/stellar/history_trades

Stellar DEX trades — orderbook-based trades on the Stellar decentralized exchange.

## Table description

The `stellar.history_trades` table records trades performed on Stellar's decentralized exchange.

## Column Descriptions

| **Column**                       | **Description**                                                                                 | **Type**                    |
| -------------------------------- | ----------------------------------------------------------------------------------------------- | --------------------------- |
| **closed\_at\_date**             | The date when the trade operation was closed.                                                   | date                        |
| **history\_operation\_id**       | The unique identifier for the operation associated with the trade.                              | bigint                      |
| **order**                        | The sequence or order of the trade execution within the operation.                              | bigint                      |
| **selling\_account\_address**    | The account address of the seller in the trade.                                                 | varchar                     |
| **selling\_asset\_code**         | The code of the asset being sold in the trade.                                                  | varchar                     |
| **selling\_asset\_issuer**       | The issuer of the asset being sold in the trade.                                                | varchar                     |
| **selling\_asset\_type**         | The type of asset being sold (e.g., native, issued).                                            | varchar                     |
| **selling\_asset\_id**           | The identifier for the asset being sold.                                                        | bigint                      |
| **selling\_amount**              | The amount of the asset being sold.                                                             | double                      |
| **buying\_account\_address**     | The account address of the buyer in the trade.                                                  | varchar                     |
| **buying\_asset\_code**          | The code of the asset being bought in the trade.                                                | varchar                     |
| **buying\_asset\_issuer**        | The issuer of the asset being bought in the trade.                                              | varchar                     |
| **buying\_asset\_type**          | The type of asset being bought (e.g., native, issued).                                          | varchar                     |
| **buying\_asset\_id**            | The identifier for the asset being bought.                                                      | bigint                      |
| **buying\_amount**               | The amount of the asset being bought.                                                           | double                      |
| **price\_n**                     | The numerator of the price ratio (price as a fraction) of the trade.                            | bigint                      |
| **price\_d**                     | The denominator of the price ratio (price as a fraction) of the trade.                          | bigint                      |
| **selling\_offer\_id**           | The offer ID for the selling side of the trade.                                                 | bigint                      |
| **buying\_offer\_id**            | The offer ID for the buying side of the trade.                                                  | bigint                      |
| **selling\_liquidity\_pool\_id** | The identifier for the liquidity pool involved in the selling side of the trade, if applicable. | varchar                     |
| **liquidity\_pool\_fee**         | The fee in lumens (XLM) for the liquidity pool, if applicable.                                  | bigint                      |
| **trade\_type**                  | The type of trade (e.g., market, limit).                                                        | bigint                      |
| **rounding\_slippage**           | The slippage amount due to rounding in the trade execution.                                     | bigint                      |
| **seller\_is\_exact**            | A boolean indicating whether the seller's amount was exact in the trade.                        | boolean                     |
| **closed\_at**                   | The timestamp when the trade was closed.                                                        | timestamp(3) with time zone |
| **updated\_at**                  | The time when the trade record was last updated.                                                | timestamp(3) with time zone |
| **ingested\_at**                 | The time when the trade data was ingested into the system.                                      | timestamp(3) with time zone |

## Table Sample

<TableSample />


# stellar.history_transactions
Source: https://docs.dune.com/data-catalog/stellar/history_transactions

Stellar transaction records — source account, fee, memo, and operation count.

## Table description

The `stellar.history_transactions` table contains transaction details, linking to multiple operations within a transaction.

## Column Descriptions

| **Column**                                  | **Description**                                                                                   | **Type**                    |
| ------------------------------------------- | ------------------------------------------------------------------------------------------------- | --------------------------- |
| **closed\_at\_date**                        | The date when the transaction was closed.                                                         | date                        |
| **id**                                      | The unique identifier for the transaction.                                                        | bigint                      |
| **transaction\_hash**                       | The hash of the transaction, in binary format.                                                    | varbinary                   |
| **ledger\_sequence**                        | The sequence number of the ledger in which the transaction is included.                           | bigint                      |
| **account**                                 | The account address that originated the transaction.                                              | varchar                     |
| **account\_sequence**                       | The source account's sequence number that this transaction consumed.                              | bigint                      |
| **max\_fee**                                | The maximum fee that the account was willing to pay for the transaction.                          | bigint                      |
| **operation\_count**                        | The number of operations contained within this transaction.                                       | bigint                      |
| **created\_at**                             | The timestamp when the transaction was created.                                                   | timestamp(3) with time zone |
| **memo\_type**                              | The type of memo attached to the transaction (e.g., text, id, hash).                              | varchar                     |
| **memo**                                    | The optional unstructured memo data attached to the transaction.                                  | varchar                     |
| **time\_bounds**                            | The optional UNIX timestamp of the lower and upper bounds for when the transaction will be valid. | varchar                     |
| **successful**                              | Indicates if the transaction succeeded.                                                           | boolean                     |
| **fee\_charged**                            | The fee charged for executing the transaction.                                                    | bigint                      |
| **inner\_transaction\_hash**                | The hash of a transaction wrapped with its signatures for fee-bump transactions.                  | varbinary                   |
| **fee\_account**                            | The account that paid for the transaction fees, which may differ from the originating account.    | varchar                     |
| **new\_max\_fee**                           | The maximum fee that the fee-payer is willing to pay for the transaction's fees.                  | bigint                      |
| **account\_muxed**                          | The virtual account address under a traditional Stellar account (multiplexed account).            | varchar                     |
| **fee\_account\_muxed**                     | The virtual address of the fee-paying account if it is a multiplexed account.                     | varchar                     |
| **ledger\_bounds**                          | Optional restrictions on the ledger range within which the transaction is valid.                  | varchar                     |
| **min\_account\_sequence**                  | The minimum account sequence number required for this transaction to be valid.                    | bigint                      |
| **min\_account\_sequence\_age**             | The minimum age (in seconds) of the sequence number.                                              | bigint                      |
| **min\_account\_sequence\_ledger\_gap**     | The minimum number of ledgers between this transaction and the account's last transaction.        | bigint                      |
| **tx\_envelope**                            | The raw XDR of the transaction that was submitted.                                                | varchar                     |
| **tx\_result**                              | The raw XDR of the transaction result after execution.                                            | varchar                     |
| **tx\_meta**                                | The raw XDR of the ledger state changes based on the transaction.                                 | varchar                     |
| **tx\_fee\_meta**                           | The raw XDR of the fee changes associated with the transaction.                                   | varchar                     |
| **extra\_signers**                          | Any additional signers attached to the transaction (array of addresses).                          | array(varchar)              |
| **resource\_fee**                           | The resource fee charged for executing the transaction.                                           | bigint                      |
| **soroban\_resources\_instructions**        | The number of instructions used in Soroban smart contracts during the transaction.                | bigint                      |
| **soroban\_resources\_read\_bytes**         | The number of bytes read during Soroban smart contract execution.                                 | bigint                      |
| **soroban\_resources\_write\_bytes**        | The number of bytes written during Soroban smart contract execution.                              | bigint                      |
| **closed\_at**                              | The timestamp when the transaction was closed.                                                    | timestamp(3) with time zone |
| **transaction\_result\_code**               | The result code that includes error codes for failed transactions.                                | varchar                     |
| **inclusion\_fee\_bid**                     | The fee bid by the account to include the transaction in the ledger.                              | bigint                      |
| **inclusion\_fee\_charged**                 | The actual fee charged for the transaction to be included in the ledger.                          | bigint                      |
| **resource\_fee\_refund**                   | The refunded portion of the resource fee.                                                         | bigint                      |
| **non\_refundable\_resource\_fee\_charged** | The portion of the resource fee that is non-refundable.                                           | bigint                      |
| **refundable\_resource\_fee\_charged**      | The portion of the resource fee that can be refunded.                                             | bigint                      |
| **rent\_fee\_charged**                      | The fee charged for rent of contract storage or data resources.                                   | bigint                      |
| **tx\_signers**                             | The array of signers involved in signing the transaction.                                         | array(varchar)              |
| **refundable\_fee**                         | The fee that can be refunded to the account based on transaction execution.                       | bigint                      |
| **updated\_at**                             | The time when the transaction record was last updated.                                            | timestamp(3) with time zone |
| **ingested\_at**                            | The time when the transaction data was ingested into the system.                                  | timestamp(3) with time zone |

## Table Sample

<TableSample />


# stellar.liquidity_pools
Source: https://docs.dune.com/data-catalog/stellar/liquidity_pools

Stellar AMM liquidity pools — pool assets, reserves, and share supply.

## Table description

The `stellar.liquidity_pools` table stores data on Stellar’s liquidity pools, such as the type, fee, assets involved etc. Liquidity Pools provide a simple, non-interactive way to trade large amounts of capital and enable high volumes of trading.

## Column Descriptions

| **Column**                 | **Description**                                                                         | **Type**                    |
| -------------------------- | --------------------------------------------------------------------------------------- | --------------------------- |
| **closed\_at\_date**       | The date when the liquidity pool entry was closed.                                      | date                        |
| **liquidity\_pool\_id**    | The unique identifier for the liquidity pool.                                           | varchar                     |
| **type**                   | The type of liquidity pool (e.g., constant product, stable).                            | varchar                     |
| **fee**                    | The fee rate, in basis points, for trading within the liquidity pool.                   | bigint                      |
| **trustline\_count**       | The number of trustlines associated with the liquidity pool.                            | bigint                      |
| **pool\_share\_count**     | The total number of pool shares outstanding, representing ownership in the pool.        | double                      |
| **asset\_a\_type**         | The type of the first asset in the liquidity pool.                                      | varchar                     |
| **asset\_a\_code**         | The code of the first asset in the liquidity pool.                                      | varchar                     |
| **asset\_a\_issuer**       | The issuer of the first asset in the liquidity pool.                                    | varchar                     |
| **asset\_a\_id**           | The unique identifier for the first asset in the liquidity pool.                        | bigint                      |
| **asset\_a\_amount**       | The total amount of the first asset held in the liquidity pool.                         | double                      |
| **asset\_b\_type**         | The type of the second asset in the liquidity pool.                                     | varchar                     |
| **asset\_b\_code**         | The code of the second asset in the liquidity pool.                                     | varchar                     |
| **asset\_b\_issuer**       | The issuer of the second asset in the liquidity pool.                                   | varchar                     |
| **asset\_b\_id**           | The unique identifier for the second asset in the liquidity pool.                       | bigint                      |
| **asset\_b\_amount**       | The total amount of the second asset held in the liquidity pool.                        | double                      |
| **last\_modified\_ledger** | The sequence number of the ledger where the liquidity pool entry was last modified.     | bigint                      |
| **ledger\_entry\_change**  | Indicates the type of change made to the ledger entry (insert, update, delete).         | bigint                      |
| **deleted**                | A boolean indicating whether the liquidity pool entry has been deleted from the ledger. | boolean                     |
| **closed\_at**             | The timestamp when the liquidity pool entry was closed.                                 | timestamp(3) with time zone |
| **ledger\_sequence**       | The sequence number of the ledger in which the liquidity pool entry is included.        | bigint                      |
| **updated\_at**            | The time when the liquidity pool record was last updated.                               | timestamp(3) with time zone |
| **ingested\_at**           | The time when the liquidity pool data was ingested into the system.                     | timestamp(3) with time zone |

## Table Sample

<TableSample />


# Stellar Data
Source: https://docs.dune.com/data-catalog/stellar/overview

Stellar blockchain data on Dune

## What is Stellar?

Stellar is an open-source, decentralized blockchain designed for fast, low-cost financial transactions. Built around the Stellar Consensus Protocol (SCP), a unique proof-of-agreement (PoA) mechanism, Stellar focuses on facilitating cross-border payments, asset issuance, and decentralized finance (DeFi) applications. Stellar’s network prioritizes energy efficiency and speed, with transactions confirmed within 5 seconds and the network capable of processing up to 1,000 operations per ledger.

Stellar's native token, the lumen (XLM), plays a key role in maintaining the network’s health by ensuring account activity and discouraging spam through a small transaction fee and minimum balance requirement.

## Key Concepts of Stellar

Stellar’s blockchain architecture and mechanisms are designed for high-speed financial transactions and asset transfers, underpinned by a few critical components that set it apart from other blockchain platforms.

### **Ledger Structure**

Stellar’s blockchain operates using ledgers, similar to blocks on other blockchains. A ledger records the state of accounts, balances, smart contracts, and other relevant data. Each ledger contains a ledger header, summarizing essential metadata such as the sequence number, transaction fees, and validator signatures.

### **Proof-of-Agreement Consensus**

Stellar uses the Stellar Consensus Protocol (SCP), a proof-of-agreement consensus that enables rapid transaction processing while ensuring decentralization. Unlike proof-of-work (PoW) or proof-of-stake (PoS) models, SCP relies on trusted nodes reaching a consensus through agreement, making Stellar energy-efficient and fast.

### **Accounts and Trustlines**

Stellar accounts hold **lumen (XLM)** and other token balances via **trustlines**. A trustline is an established link between a user account and a token issuer, allowing the user to hold, send, or receive tokens other than lumens. While **accounts** store native lumens, **trustlines** track the balances of other tokens, including popular assets like USDC and USDT.

### **Token Issuance**

One of Stellar’s most powerful features is its support for **asset issuance**. Developers can create tokenized assets that represent fiat currencies, commodities, or other real-world value. These assets can be traded on Stellar’s native decentralized exchange (DEX), making Stellar an ideal platform for borderless payments and asset transfers.

### **Transaction Lifecycle & Fees**

Each Stellar transaction is an atomic operation that can involve multiple **operations**, such as payments, creating accounts, or managing offers on the DEX. Fees are minimal, with the current minimum per-transaction fee being 0.00001 XLM. Stellar’s architecture ensures efficient cross-border transactions with a finality time of around 5 seconds.

### **Smart Contracts**

Stellar supports smart contracts through a combination of **operations** and **contract data** stored on the ledger. Smart contracts can define various on-chain actions, such as token management or enforcing custom rules for transactions. Stellar's smart contract execution is energy-efficient, focusing on lightweight operations for scalability.

<CardGroup>
  <Card title="Stellar documentation" icon="link" href="https://developers.stellar.org/docs/learn/fundamentals">
    Explore comprehensive documentation of Stellar, detailing its architecture, protocol, and resources for developers.
  </Card>

  <Card title="Stellar data model diagram" icon="wifi" href="https://developers.stellar.org/docs/data/hubble/data-catalog/data-model-diagram">
    See the relationship between history and state tables in Stellar's data model.
  </Card>
</CardGroup>

## Stellar Data on Dune

Stellar blockchain data is categorized into traditional time series tables (e.g., **history\_** tables for actions affecting the state of the ledger) and **ledger state** tables (e.g., **accounts**, representing the current state). This division allows users to explore historical actions and current ledger state for deeper analysis. Here are the Stellar tables available on Dune:

<CardGroup>
  <Card title="Accounts" icon="notebook" href="/data-catalog/stellar/accounts">
    Tracks the native token (Lumens) balances held by accounts.
  </Card>

  <Card title="Contract Data" icon="file" href="/data-catalog/stellar/contract_data">
    Stores state data for smart contracts, including supported tokens and storage costs.
  </Card>

  <Card title="Trust Lines" icon="right-left-large" href="/data-catalog/stellar/trust_lines">
    Tracks balances of accounts for non-native tokens (such as USDC or USDT).
  </Card>

  <Card title="Liquidity Pools" icon="money-bill" href="/data-catalog/stellar/liquidity_pools">
    Stores data on Stellar’s liquidity pools, such as the type, fee, assets involved etc.
  </Card>

  <Card title="TTL (Time to Live)" icon="clock" href="/data-catalog/stellar/ttl">
    Records time limits for smart contract data, enforcing storage expiry rules.
  </Card>

  <Card title="History Contract Events" icon="bolt" href="/data-catalog/stellar/history_contract_events">
    Captures all smart contract events and traces, with details on contract execution.
  </Card>

  <Card title="History Ledgers" icon="cube" href="/data-catalog/stellar/history_ledgers">
    Tracks ledgers info (equivalent of blocks on other blockchain), including metadata such as sequence numbers, transactions included, and fees.
  </Card>

  <Card title="History Operations" icon="reflect-horizontal" href="/data-catalog/stellar/history_operations">
    Tracks operational details of transaction in ledgers/blocks.
  </Card>

  <Card title="History Trades" icon="swap" href="/data-catalog/stellar/history_trades">
    Records trades performed on Stellar's decentralized exchange.
  </Card>

  <Card title="History Transactions" icon="message-arrow-up" href="/data-catalog/stellar/history_transactions">
    Contains transaction details, linking to multiple operations within a transaction.
  </Card>

  <Card title="History Effects" icon="reflect-vertical" href="/data-catalog/stellar/history_effects">
    Records specific changes that occur in the ledger as a result of success operations, but are not necessarily directly reflected in the ledger or history, as transactions and operations are.
  </Card>
</CardGroup>


# stellar.trust_lines
Source: https://docs.dune.com/data-catalog/stellar/trust_lines

Stellar trustlines — authorized asset holdings per account.

## Table description

The `stellar.trust_lines` table tracks balances of accounts for non-native tokens (such as USDC or USDT).

Trustlines are an explicit opt-in for an account to hold and trade a particular asset. To hold a specific asset, an account must establish a trustline with the issuing account using the change\_trust operation. Trustlines track the balance of an asset and can also limit the amount of an asset that an account can hold.

A trustline must be established for an account to receive any asset except lumens (XLM). You can create a claimable balance to send assets to an account without a trustline, but the recipient has to create a trustline to claim that balance. Learn more here: Claimable Balances Encyclopedia Entry

A trustline also tracks liabilities. Buying liabilities equal the total amount of the asset offered to buy aggregated over all offers owned by an account, and selling liabilities equal the total amount of the asset offered to sell aggregated over all offers owned by an account. A trustline must always have a balance sufficiently large to satisfy its selling liabilities and a balance sufficiently below its limit to accommodate its buying liabilities.

## Column Descriptions

| **Column**                 | **Description**                                                                                      | **Type**                    |
| -------------------------- | ---------------------------------------------------------------------------------------------------- | --------------------------- |
| **ledger\_key**            | The unique identifier for the trustline entry in the ledger.                                         | varchar                     |
| **account\_id**            | The account address associated with the trustline.                                                   | varchar                     |
| **asset\_type**            | The type of asset for which the trustline is established (e.g., native, issued).                     | varchar                     |
| **asset\_issuer**          | The issuer of the asset for which the trustline is established.                                      | varchar                     |
| **asset\_code**            | The code of the asset for which the trustline is established.                                        | varchar                     |
| **asset\_id**              | The unique identifier for the asset in the trustline.                                                | bigint                      |
| **liquidity\_pool\_id**    | The identifier of the liquidity pool related to the trustline, if applicable.                        | varchar                     |
| **balance**                | The balance of the asset held by the account in the trustline.                                       | double                      |
| **trust\_line\_limit**     | The maximum balance of the asset that the account is willing to hold via the trustline.              | bigint                      |
| **buying\_liabilities**    | The total liabilities for buying offers on the account for this trustline.                           | double                      |
| **selling\_liabilities**   | The total liabilities for selling offers on the account for this trustline.                          | double                      |
| **flags**                  | A set of flags representing various properties of the trustline, such as authorization requirements. | bigint                      |
| **last\_modified\_ledger** | The ledger sequence number where the trustline entry was last modified.                              | bigint                      |
| **ledger\_entry\_change**  | Indicates the type of change made to the ledger entry (insert, update, delete).                      | bigint                      |
| **deleted**                | A boolean indicating whether the trustline entry has been deleted from the ledger.                   | boolean                     |
| **sponsor**                | The account that is sponsoring this trustline's resources.                                           | varchar                     |
| **closed\_at**             | The timestamp when the trustline entry was closed.                                                   | timestamp(3) with time zone |
| **ledger\_sequence**       | The sequence number of the ledger in which the trustline entry is included.                          | bigint                      |
| **updated\_at**            | The time when the trustline record was last updated.                                                 | timestamp(3) with time zone |
| **ingested\_at**           | The time when the trustline data was ingested into the system.                                       | timestamp(3) with time zone |

## Table Sample

<TableSample />


# stellar.ttl
Source: https://docs.dune.com/data-catalog/stellar/ttl

Stellar contract data time-to-live records.

## Table description

The `stellar.ttl` table records time limits for smart contract data, enforcing storage expiry rules.

## Column Descriptions

| **Column**                   | **Description**                                                                 | **Type**                    |
| ---------------------------- | ------------------------------------------------------------------------------- | --------------------------- |
| **closed\_at\_date**         | The date when the TTL (Time-to-Live) entry was closed.                          | date                        |
| **key\_hash**                | The hash of the key used to identify the TTL entry, in binary format.           | varbinary                   |
| **live\_until\_ledger\_seq** | The ledger sequence number until which the TTL entry remains live.              | bigint                      |
| **last\_modified\_ledger**   | The ledger sequence number where the TTL entry was last modified.               | bigint                      |
| **ledger\_entry\_change**    | Indicates the type of change made to the ledger entry (insert, update, delete). | bigint                      |
| **deleted**                  | A boolean indicating whether the TTL entry has been deleted from the ledger.    | boolean                     |
| **closed\_at**               | The timestamp when the TTL entry was closed.                                    | timestamp(3) with time zone |
| **ledger\_sequence**         | The sequence number of the ledger in which the TTL entry is included.           | bigint                      |
| **updated\_at**              | The time when the TTL record was last updated.                                  | timestamp(3) with time zone |
| **ingested\_at**             | The time when the TTL data was ingested into the system.                        | timestamp(3) with time zone |

## Table Sample

<TableSample />


# polkadot.balances
Source: https://docs.dune.com/data-catalog/substrate/balances

Description of Substrate balances tables on Dune.

## Table description

The `balances` table (e.g. `polkadot.balances`) stores a snapshot of all account balances at the end of each day: `free`, `reserved`, `misc_frozen`, and their USD value, if available.

## Table Schema

| Column            | Type        | Description                                                            |
| ----------------- | ----------- | ---------------------------------------------------------------------- |
| `year`            | `INTEGER`   | Calendar year of the snapshot (partition column)                       |
| `month`           | `INTEGER`   | Calendar month of the snapshot (partition column)                      |
| `day`             | `INTEGER`   | Calendar day of the snapshot (partition column)                        |
| `ts`              | `TIMESTAMP` | Timestamp of the end-of-day balance snapshot                           |
| `symbol`          | `VARCHAR`   | Token symbol (e.g. `DOT`, `KSM`)                                       |
| `address_ss58`    | `VARCHAR`   | SS58-encoded address of the account holder                             |
| `address_pubkey`  | `VARBINARY` | Public key of the account holder                                       |
| `id`              | `VARCHAR`   | Unique identifier for the asset                                        |
| `chain_name`      | `VARCHAR`   | Name of the Substrate chain (e.g. `polkadot`, `kusama`)                |
| `asset`           | `VARCHAR`   | Asset type or name                                                     |
| `para_id`         | `BIGINT`    | Parachain ID, if the balance is on a parachain                         |
| `free`            | `DOUBLE`    | Freely transferable balance (human-readable units)                     |
| `reserved`        | `DOUBLE`    | Reserved balance locked for on-chain activities (human-readable units) |
| `misc_frozen`     | `DOUBLE`    | Balance frozen for miscellaneous reasons (human-readable units)        |
| `frozen`          | `DOUBLE`    | Total frozen balance (human-readable units)                            |
| `nonce`           | `BIGINT`    | Account transaction nonce at the time of the snapshot                  |
| `free_raw`        | `VARCHAR`   | Raw free balance in smallest denomination (Planck)                     |
| `reserved_raw`    | `VARCHAR`   | Raw reserved balance in smallest denomination (Planck)                 |
| `misc_frozen_raw` | `VARCHAR`   | Raw misc frozen balance in smallest denomination (Planck)              |
| `frozen_raw`      | `VARCHAR`   | Raw frozen balance in smallest denomination (Planck)                   |
| `flags_raw`       | `VARCHAR`   | Raw account flags value                                                |
| `updated_at`      | `TIMESTAMP` | When this record was last updated in the database                      |
| `ingested_at`     | `TIMESTAMP` | When this record was first ingested into the database                  |

## Table Sample

<TableSample />


# polkadot.blocks
Source: https://docs.dune.com/data-catalog/substrate/blocks

Description of Substrate blocks table on Dune.

## Table description

The `polkadot.blocks` table stores basic information about Substrate blocks, with one record per block, including the block hash and statistics on the number of extrinsics, events, and transfers contained in each block.

## Table Schema

| Column               | Type        | Description                                                  |
| -------------------- | ----------- | ------------------------------------------------------------ |
| `year`               | `INTEGER`   | Calendar year of the block (partition column)                |
| `month`              | `INTEGER`   | Calendar month of the block (partition column)               |
| `day`                | `INTEGER`   | Calendar day of the block (partition column)                 |
| `block_time`         | `TIMESTAMP` | The timestamp when the block was produced                    |
| `number`             | `BIGINT`    | The sequential block number                                  |
| `spec_version`       | `BIGINT`    | Runtime specification version active at this block           |
| `relay_block_number` | `BIGINT`    | Corresponding relay chain block number (for parachains)      |
| `hash`               | `VARBINARY` | Unique hash identifying this block                           |
| `parent_hash`        | `VARBINARY` | Hash of the preceding block                                  |
| `state_root`         | `VARBINARY` | Root hash of the state trie after this block                 |
| `extrinsics_root`    | `VARBINARY` | Root hash of the extrinsics trie for this block              |
| `author_ss58`        | `VARCHAR`   | SS58-encoded address of the block author/validator           |
| `author_pub_key`     | `VARBINARY` | Public key of the block author/validator                     |
| `relay_state_root`   | `VARBINARY` | State root of the relay chain at this block (for parachains) |
| `extrinsic_count`    | `BIGINT`    | Number of extrinsics included in this block                  |
| `event_count`        | `BIGINT`    | Number of events emitted in this block                       |
| `transfer_count`     | `BIGINT`    | Number of token transfers in this block                      |
| `trace_count`        | `BIGINT`    | Number of traces recorded for this block                     |
| `updated_at`         | `TIMESTAMP` | When this record was last updated in the database            |
| `ingested_at`        | `TIMESTAMP` | When this record was first ingested into the database        |

## Table Sample

<TableSample />


# polkadot.calls
Source: https://docs.dune.com/data-catalog/substrate/calls

Description of Substrate calls tables on Dune.

## Table description

The `polkadot.calls` table represents *internal* calls within Substrate extrinsics, including recursive calls from `proxy` and `utility` (batch) pallets, and provides detailed call arguments at each level of the call tree. Unlike the `extrinsics` table which only captures the top-level call, this table exposes the full call hierarchy.

Common queries on the `calls` table will typically filter on `block_time`, `call_section` and `call_method` and extract JSON encoded information in
`data` or `decoded_data`.

## Table Schema

| Column              | Type        | Description                                                               |
| ------------------- | ----------- | ------------------------------------------------------------------------- |
| `year`              | `INTEGER`   | Calendar year of the block (partition column)                             |
| `month`             | `INTEGER`   | Calendar month of the block (partition column)                            |
| `call_section`      | `VARCHAR`   | The pallet (module) of this call (e.g. `Balances`, `Staking`)             |
| `call_method`       | `VARCHAR`   | The method name within the pallet (e.g. `transfer`, `bond`)               |
| `block_number`      | `BIGINT`    | The sequential number of the block containing this call                   |
| `block_time`        | `TIMESTAMP` | The timestamp of the block containing this call                           |
| `extrinsic_id`      | `VARCHAR`   | Identifier of the parent extrinsic (format: `blockNumber-extrinsicIndex`) |
| `relay_chain`       | `VARCHAR`   | Name of the relay chain (e.g. `polkadot`, `kusama`)                       |
| `para_id`           | `BIGINT`    | Parachain ID, if this call is on a parachain                              |
| `id`                | `VARCHAR`   | Unique identifier for this call                                           |
| `block_hash`        | `VARBINARY` | Hash of the block containing this call                                    |
| `extrinsic_hash`    | `VARBINARY` | Hash of the parent extrinsic                                              |
| `extrinsic_section` | `VARCHAR`   | The pallet of the top-level extrinsic                                     |
| `extrinsic_method`  | `VARCHAR`   | The method of the top-level extrinsic                                     |
| `call_id`           | `VARCHAR`   | Identifier for this specific call within the extrinsic                    |
| `call_index`        | `VARBINARY` | Encoded index of the call within the pallet                               |
| `call_args`         | `VARCHAR`   | JSON-encoded arguments passed to this call                                |
| `call_args_def`     | `VARCHAR`   | JSON-encoded definition/schema of the call arguments                      |
| `root`              | `BOOLEAN`   | Whether this is the root (top-level) call in the extrinsic                |
| `leaf`              | `BOOLEAN`   | Whether this is a leaf call with no further nested calls                  |
| `fee`               | `DOUBLE`    | Transaction fee paid for this call                                        |
| `weight`            | `BIGINT`    | Execution weight consumed by this call                                    |
| `signed`            | `BOOLEAN`   | Whether the parent extrinsic was signed                                   |
| `signer_ss58`       | `VARCHAR`   | SS58-encoded address of the extrinsic signer                              |
| `signer_pub_key`    | `VARBINARY` | Public key of the extrinsic signer                                        |
| `lifetime`          | `VARCHAR`   | Validity period of the extrinsic (mortal/immortal era)                    |
| `updated_at`        | `TIMESTAMP` | When this record was last updated in the database                         |
| `ingested_at`       | `TIMESTAMP` | When this record was first ingested into the database                     |

## Table Sample

<TableSample />


# polkadot.events
Source: https://docs.dune.com/data-catalog/substrate/events

Substrate runtime events across Polkadot, Kusama, and parachain networks.

## Table description

The `events` table (e.g. `polkadot.events`) holds all events that occur on the chain, including their pallet `section` and `method`, as well as the decoded data involved in the event.

Common queries on the `events` table will typically filter on `block_time`, `section` and `method` and extract JSON encoded information in
`data` or `decoded_data`.

## Table Schema

| Column           | Type        | Description                                                                   |
| ---------------- | ----------- | ----------------------------------------------------------------------------- |
| `year`           | `INTEGER`   | Calendar year of the block (partition column)                                 |
| `month`          | `INTEGER`   | Calendar month of the block (partition column)                                |
| `section`        | `VARCHAR`   | The pallet (module) that emitted this event (e.g. `Balances`, `System`)       |
| `method`         | `VARCHAR`   | The event method name within the pallet (e.g. `Transfer`, `ExtrinsicSuccess`) |
| `block_time`     | `TIMESTAMP` | The timestamp of the block containing this event                              |
| `block_number`   | `BIGINT`    | The sequential number of the block containing this event                      |
| `extrinsic_id`   | `VARCHAR`   | Identifier of the extrinsic that triggered this event                         |
| `event_id`       | `VARCHAR`   | Unique identifier for this event (format: `blockNumber-eventIndex`)           |
| `data`           | `VARCHAR`   | JSON-encoded event data                                                       |
| `extrinsic_hash` | `VARBINARY` | Hash of the extrinsic that triggered this event                               |
| `block_hash`     | `VARBINARY` | Hash of the block containing this event                                       |
| `data_decoded`   | `VARCHAR`   | Human-readable decoded event data                                             |
| `updated_at`     | `TIMESTAMP` | When this record was last updated in the database                             |
| `ingested_at`    | `TIMESTAMP` | When this record was first ingested into the database                         |

## Table Sample

<TableSample />


# polkadot.extrinsics
Source: https://docs.dune.com/data-catalog/substrate/extrinsics

Description of Substrate extrinsics table on Dune.

## Table description

Extrinsics (aka "transactions") normally contain a signature, some data to describe if the extrinsic has passed some validity checks and a reference to the pallet and call that it is intended for.  Extrinsics may be signed or unsigned.  Some extrinsics have a complex structure, e.g. when using proxy or utility pallets, resulting in the top-level call initiating other calls involving other pallets.

Common queries on the `extrinsics` table (e.g. `polkadot.extrinsics`) will typically filter on `block_time`, `section` and `method` and extract JSON encoded information in `data` or `decoded_data`.  In many cases, an initial query on the `extrinsics` table is best developed on the calls table instead to properly capture how users often use proxy and utility constructs to interact with the Substrate chain.

## Table Schema

| Column           | Type        | Description                                                                 |
| ---------------- | ----------- | --------------------------------------------------------------------------- |
| `year`           | `INTEGER`   | Calendar year of the block (partition column)                               |
| `month`          | `INTEGER`   | Calendar month of the block (partition column)                              |
| `section`        | `VARCHAR`   | The pallet (module) of the top-level call (e.g. `Balances`, `Staking`)      |
| `method`         | `VARCHAR`   | The method name within the pallet (e.g. `transferKeepAlive`, `nominate`)    |
| `block_time`     | `TIMESTAMP` | The timestamp of the block containing this extrinsic                        |
| `block_number`   | `BIGINT`    | The sequential number of the block containing this extrinsic                |
| `extrinsic_id`   | `VARCHAR`   | Unique identifier for this extrinsic (format: `blockNumber-extrinsicIndex`) |
| `hash`           | `VARBINARY` | Hash of this extrinsic                                                      |
| `block_hash`     | `VARBINARY` | Hash of the block containing this extrinsic                                 |
| `lifetime`       | `VARCHAR`   | Validity period of the extrinsic (mortal/immortal era)                      |
| `params`         | `VARCHAR`   | JSON-encoded parameters of the top-level call                               |
| `fee`            | `DOUBLE`    | Transaction fee paid for this extrinsic                                     |
| `weight`         | `BIGINT`    | Execution weight consumed by this extrinsic                                 |
| `signed`         | `BOOLEAN`   | Whether this extrinsic includes a cryptographic signature                   |
| `signer_ss58`    | `VARCHAR`   | SS58-encoded address of the signer                                          |
| `signer_pub_key` | `VARBINARY` | Public key of the signer                                                    |
| `status`         | `BOOLEAN`   | Whether the extrinsic executed successfully (`true`) or failed (`false`)    |
| `updated_at`     | `TIMESTAMP` | When this record was last updated in the database                           |
| `ingested_at`    | `TIMESTAMP` | When this record was first ingested into the database                       |

## Table Sample

<TableSample />


# Materialized Views
Source: https://docs.dune.com/data-catalog/substrate/materialized_views

Useful materialized views for Polkadot, Kusama & their parachains.

<Info>
  Materialized views store pre-computed query results as tables, enabling faster queries and simplified data pipelines. To learn more about creating and using materialized views, see the [Materialized Views page](/query-engine/materialized-views).
</Info>

A list of useful queries that we have [materialized](https://dune.com/queries?category=third_party_data\&catalog=dune\&schema=substrate) for usability. Some complex dashboards can be constructed more efficiently by referencing these materialized views. Forks and additions are welcome!

## Polkadot

| Materialized View                                                | Query ID                                           | Description                                                                                                                                        |
| ---------------------------------------------------------------- | -------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| dune.substrate.result\_polkadot\_validators                      | [query\_3302709](https://dune.com/queries/3302709) | Analyzes Polkadot validators' performance and staking rewards, including nominator associations and APR calculations.                              |
| dune.substrate.result\_polkadot\_nominationpools                 | [query\_3327350](https://dune.com/queries/3327350) | Tracks and assesses Nomination Pool rewards, fees, and APR within the Polkadot ecosystem.                                                          |
| dune.substrate.result\_polkadot\_nominators                      | [query\_3326829](https://dune.com/queries/3326829) | Summarizes active nominator contributions, rewards, and their share in validators' stakes in Polkadot.                                             |
| dune.substrate.result\_polkadot\_poolmembers                     | [query\_3327479](https://dune.com/queries/3327479) | Details individual Nomination Pool member contributions, rewards, and unclaimed amounts in Polkadot.                                               |
| dune.substrate.result\_polkadot\_identity                        | [query\_3420617](https://dune.com/queries/3420617) | A mapping between Polkadot and Kusama identities, linking addresses and verifying authenticity.                                                    |
| dune.substrate.result\_polkadot\_referenda\_total\_voting\_power | [query\_3394422](https://dune.com/queries/3394422) | Summarizes Polkadot referenda votes, detailing direct and delegated voting power and convictions.                                                  |
| dune.substrate.result\_polkadot\_staking\_nomination\_total      | [query\_3426963](https://dune.com/queries/3426963) | Displays Polkadot nominators, their staked totals per validator, and validator identities by era.                                                  |
| dune.substrate.result\_polkadot\_open\_gov\_delegation           | [query\_3393179](https://dune.com/queries/3393179) | Details staked totals by Polkadot nominators across validators and eras, including validator names.                                                |
| dune.substrate.result\_polkadot\_vote\_record                    | [query\_3415321](https://dune.com/queries/3415321) | Polkadot referenda vote information, integrating direct, proxy, and delegated votes with dynamic links and voter identities.                       |
| dune.substrate.result\_polkadot\_proposals\_proposed             | [query\_3394156](https://dune.com/queries/3394156) | Tracks Polkadot referenda statuses including proposer details, timelines, and outcome, with direct links to further information.                   |
| dune.substrate.result\_polkadot\_referenda\_direct\_vote         | [query\_3391225](https://dune.com/queries/3391225) | All Polkadot referendum direct votes (filter expired votes).                                                                                       |
| dune.substrate.result\_polkadot\_each\_vote\_record              | [query\_3393684](https://dune.com/queries/3393684) | Aggregates Polkadot referendum voting details, showing voter identities, vote types, convictions, and power, including direct and delegated votes. |
| dune.substrate.result\_polkadot\_referenda\_origin\_map          | [query\_3399352](https://dune.com/queries/3399352) | Associates Polkadot referenda with their origins.                                                                                                  |
| dune.substrate.result\_polkadot\_failed\_calls\_in\_batch        | [query\_3457139](https://dune.com/queries/3457139) | Finds some failed calls hidden in a utility batch on Polkadot.                                                                                     |

## Kusama

| Materialized View                                              | Query ID                                           | Description                                                                                                                                      |
| -------------------------------------------------------------- | -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| dune.substrate.result\_kusama\_validators                      | [query\_3477509](https://dune.com/queries/3477509) | Analyzes Kusama validators' performance and staking rewards, including nominator associations and APR calculations.                              |
| dune.substrate.result\_kusama\_nominationpools                 | [query\_3477568](https://dune.com/queries/3477568) | Tracks and assesses Nomination Pool rewards, fees, and APR within the Kusama ecosystem.                                                          |
| dune.substrate.result\_kusama\_nominators                      | [query\_3477192](https://dune.com/queries/3477192) | Summarizes active nominator contributions, rewards, and their share in validators' stakes in Kusama.                                             |
| dune.substrate.result\_kusama\_poolmembers                     | [query\_3477877](https://dune.com/queries/3477877) | Details individual Nomination Pool member contributions, rewards, and unclaimed amounts in Kusama.                                               |
| dune.substrate.result\_kusama\_referenda\_total\_voting\_power | [query\_3480624](https://dune.com/queries/3480624) | Summarizes Kusama referenda votes, detailing direct and delegated voting power and convictions.                                                  |
| dune.substrate.result\_kusama\_open\_gov\_delegation           | [query\_3480477](https://dune.com/queries/3480477) | Details staked totals by Kusama nominators across validators and eras, including validator names.                                                |
| dune.substrate.result\_kusama\_vote\_record                    | [query\_3480405](https://dune.com/queries/3480405) | Kusama referenda vote information, integrating direct, proxy, and delegated votes with dynamic links and voter identities.                       |
| dune.substrate.result\_kusama\_proposals\_proposed             | [query\_3480370](https://dune.com/queries/3480370) | Tracks Kusama referenda statuses including proposer details, timelines, and outcome, with direct links to further information.                   |
| dune.substrate.result\_kusama\_referenda\_direct\_vote         | [query\_3480617](https://dune.com/queries/3480617) | All Kusama referendum direct votes (filter expired votes).                                                                                       |
| dune.substrate.result\_kusama\_each\_vote\_record              | [query\_3480878](https://dune.com/queries/3480878) | Aggregates Kusama referendum voting details, showing voter identities, vote types, convictions, and power, including direct and delegated votes. |
| dune.substrate.result\_kusama\_referenda\_origin\_map          | [query\_3480454](https://dune.com/queries/3480454) | Associates Kusama referenda with their origins.                                                                                                  |
| dune.substrate.result\_kusama\_failed\_calls\_in\_batch        | [query\_3480469](https://dune.com/queries/3480469) | Finds some failed calls hidden in a utility batch on Kusama.                                                                                     |

## Interlay

| Materialized View                                | Query ID                                           | Description                                            |
| ------------------------------------------------ | -------------------------------------------------- | ------------------------------------------------------ |
| dune.substrate.result\_interlay\_oracle          | [query\_3445402](https://dune.com/queries/3445402) | All graphs that use a price on Interlay                |
| dune.substrate.result\_interlay\_vault\_creation | [query\_3437565](https://dune.com/queries/3437565) | All graphs that show vaults with their collateral      |
| dune.substrate.result\_hydradx\_oracle           | [query\_3459562](https://dune.com/queries/3459562) | All graphs that use trade volume or prices on HydraDX. |


# Polkadot & Substrate Overview
Source: https://docs.dune.com/data-catalog/substrate/overview

Substrate chains (e.g. Polkadot and its parachains) are on Dune.

<Warning>
  **Deprecation Notice**: Starting from the 7th of July 2025 Dune is not live ingesting and indexing Polkadot data. The historical data of the chain will remain available to be used.
</Warning>

The Polkadot Relay Chain is a proof-of-stake blockchain that provides shared security and secure interoperability to other blockchains, known as parachains. Parachain's transactions are processed in parallel by Polkadot. Kusama is a sister relay chain, designed as a canary blockchain, largely to test new Polkadot functionality before being deployed on Polkadot.

Both relay chains and all their parachains are built with Substrate. Substrate is the primary blockchain SDK used by developers to create parachains that make up the Polkadot and Kusama networks. There also is a growing number of chains built with Substrate that are outside of Polkadot's shared security infrastructure.

In Dune, Substrate tables model the activity of Substrate chains and are ingested hourly. All Substrate chains share identical schemas. For documentation purposes, we use `polkadot.<tables>` to showcase how to use all other `<substrate_chain>.<tables>`.

<Info>
  Polkadot and all of the substrate chains are ingested by [Colorful Notion](https://colorfulnotion.com)
  and are supported by [Polkadot OpenGov](https://polkadot.opengov.io).
</Info>

## Onboarding Status

Both Polkadot and Kusama relay chains and several leading parachains have been onboarded as of March 2024. All Polkadot system chains and Polkadot parachains (as of early 2024) are being onboarded in early Q2 2024. Modeling EVM Activity within Substrate is planned in mid to late Q2 2024.

<div>
  <DuneEmbed />
</div>

## Substrate Tables

All tables are organized by a temporal variable (`block_time` or `ts`). Because Substrate is organized by *pallets*, several of the key tables (`calls`, `events` and `extrinsics`) are usually filtered by the pallet section and method (`call_section` and `call_method` for `calls`, or `section` and `method` for `events` and `extrinsics`). Decoded data is available in `decoded_data` for these tables in JSON form.

<CardGroup>
  <Card title="Blocks" icon="cubes" href="/data-catalog/substrate/blocks">
    Each block in the blockchain, summarized with its hash and key statistics for quick overview.
  </Card>

  <Card title="Extrinsics" icon="sitemap" href="/data-catalog/substrate/extrinsics">
    Detailed transaction data, encompassing both signed and unsigned operations, directly invoking pallet functions.
  </Card>

  <Card title="Balances" icon="wallet" href="/data-catalog/substrate/balances">
    Daily snapshots capturing the state of user assets, reflecting the end-of-day balances.
  </Card>

  <Card title="Calls" icon="arrow-right" href="/data-catalog/substrate/calls">
    Comprehensive info on function calls, expanding top-level extrinsics with internal calls.
  </Card>

  <Card title="Events" icon="bolt" href="/data-catalog/substrate/events">
    All events emitted by the runtime, including system events, and events from all pallets.
  </Card>

  <Card title="Transfers" icon="arrow-up-from-bracket" href="/data-catalog/substrate/transfers">
    Complete ledger of asset transfers across the network, capturing the movement of tokens between accounts.
  </Card>

  <Card title="Traces" icon="memo-circle-info" href="/data-catalog/substrate/traces">
    In-depth Substrate storage data, offering insights that are not readily available from the events data alone.
  </Card>

  <Card title="Stakings" icon="hand-holding-heart" href="/data-catalog/substrate/stakings">
    Raw staking data including details on Validators, Nominators, Pools, and Pool Members, specific to Polkadot and Kusama Relay Chains.
  </Card>

  <Card title="Materialized Views" icon="database" href="/data-catalog/substrate/materialized_views">
    Optimized data views storing pre-processed information from other tables, streamlining access to pipelined chain data.
  </Card>
</CardGroup>

## Sample Queries

As Substrate chains use SS58 Addresses, the following Dune function is very useful:

* [SS58 functions: from\_ss58(varchar) + to\_ss58(varbinary, int)](/query-engine/Functions-and-operators/ss58)

### overview of recent blocks

```sql theme={null}
SELECT DATE(block_time) AS logDT,
       count(distinct number) numBlocks,
       MAX(block_time) AS lastBlockTime,
       MIN(number) AS b0,
       MAX(number) AS b1,
       (MAX(number) -MIN(number) - count(distinct number)) + 1 as missing
FROM polkadot.blocks
WHERE block_time > DATE('2024-01-01')
GROUP BY 1
order by 1 desc;
```

### popular pallets

Query the most popular pallets and their methods.

```sql theme={null}
select count(distinct signer_ss58) numUsers, count(*) numCalls, call_section, call_method from polkadot.calls
where call_section not in ('timestamp', 'utility', 'proxy')
group by call_section, call_method order by count(*) desc
```

### frequent events

Query the most frequent events, excluding system events.

```sql theme={null}
select  count(*) numEvents, concat(section, ':', method)  as sm from polkadot.events
where section not in ('system')
group by 2 order by count(*) desc
```

### other chains

To query other chains, replace `polkadot` with the chain name, e.g. `kusama`, `interlay`, `astar` etc.

```sql theme={null}
SELECT
  date_format(block_time, '%Y-%m') as monthDT,
  call_method,
  COUNT(DISTINCT signer_ss58) AS numUniqueActiveUsers,
  COUNT(Distinct extrinsic_id ) AS numCalls
FROM
  assethub.calls
WHERE
  call_section IN ('nfts')
  AND call_method IN ('buyItem', 'mint')
  AND block_time >= TIMESTAMP '2023-01-01'
GROUP BY
  1, 2
ORDER BY
  1, 2;
```

### JSON extraction

You will often need to extract data from JSON fields. Here is an example of how to extract data from the `events` table.

```sql theme={null}
SELECT
    E.block_time,
    JSON_VALUE(E.data, 'strict $[0]') as account,
    JSON_VALUE(E.data_decoded, 'strict $[0].address') as pub_key,
    CAST(JSON_VALUE(E.data, 'strict $[1]') AS SMALLINT) as asset_id_1,
    CAST(JSON_VALUE(E.data, 'strict $[2]') AS SMALLINT) as asset_id_2,
    (JSON_VALUE(E.data, 'strict $[3]'))as amount_1,
    (JSON_VALUE(E.data, 'strict $[4]'))as amount_2,
    (JSON_VALUE(E.data, 'strict $[5]'))as hub_in,
    (JSON_VALUE(E.data, 'strict $[6]'))as hub_out,
    (JSON_VALUE(E.data, 'strict $[7]'))as asset_fee,
    (JSON_VALUE(E.data, 'strict $[8]'))as protocol_fee,
    A1.decimals as decimals_1,
    A1.ticker as ticker_1,
    A2.decimals as decimals_2,
    A2.ticker as ticker_2,
    method
    FROM hydradx.events E
    LEFT JOIN query_3482301 A1 on A1.asset_id=CAST(JSON_VALUE(data, 'strict $[1]') as INT)
    LEFT JOIN query_3482301 A2 on A2.asset_id=CAST(JSON_VALUE(data, 'strict $[2]') as INT)
    WHERE section='omnipool' and method in('SellExecuted', 'BuyExecuted')
```


# polkadot.stakings
Source: https://docs.dune.com/data-catalog/substrate/stakings

Polkadot staking data — validator nominations, staking rewards, and slash events.

## Table description

The `polkadot.stakings` table includes all the data necessary to compute staking-related metrics for Validators, Nominators, Pools, and Pool Members.  This is currently supported for Polkadot and Kusama Relay Chain only.

## Table Schema

| Column                        | Type             | Description                                                                    |
| ----------------------------- | ---------------- | ------------------------------------------------------------------------------ |
| `year`                        | `INTEGER`        | Calendar year of the record (partition column)                                 |
| `month`                       | `INTEGER`        | Calendar month of the record (partition column)                                |
| `section`                     | `VARCHAR`        | The pallet section for this staking record (e.g. `Staking`, `NominationPools`) |
| `storage`                     | `VARCHAR`        | The specific storage item being tracked (e.g. `Validators`, `Nominators`)      |
| `block_number`                | `BIGINT`         | The block number at which this staking snapshot was taken                      |
| `ts`                          | `TIMESTAMP`      | Timestamp of the staking snapshot                                              |
| `era`                         | `BIGINT`         | The staking era number                                                         |
| `address_ss58`                | `VARCHAR`        | SS58-encoded address of the validator, nominator, or pool member               |
| `address_pubkey`              | `VARBINARY`      | Public key of the validator, nominator, or pool member                         |
| `block_hash`                  | `VARBINARY`      | Hash of the block at which the snapshot was taken                              |
| `submitted_in`                | `BIGINT`         | The era in which the nominator's nomination was submitted                      |
| `suppressed`                  | `BOOLEAN`        | Whether the validator is suppressed (excluded from election)                   |
| `validator_total`             | `DOUBLE`         | Total stake backing this validator (own + nominated)                           |
| `validator_own`               | `DOUBLE`         | Validator's own bonded stake                                                   |
| `validator_commission`        | `DOUBLE`         | Validator's commission rate (0.0 to 1.0)                                       |
| `validator_reward_shares`     | `DOUBLE`         | Proportion of total staking rewards earned by this validator                   |
| `validator_reward_points`     | `BIGINT`         | Reward points earned by this validator in the era                              |
| `validator_staking_rewards`   | `DOUBLE`         | Staking rewards earned by this validator in the era                            |
| `total_staked`                | `DOUBLE`         | Total amount staked across all validators in the era                           |
| `total_reward_points`         | `BIGINT`         | Total reward points across all validators in the era                           |
| `total_staking_rewards`       | `DOUBLE`         | Total staking rewards distributed in the era                                   |
| `nominationpools_id`          | `BIGINT`         | Nomination pool ID                                                             |
| `nominationpools_total`       | `DOUBLE`         | Total staked in the nomination pool                                            |
| `nominationpools_member_cnt`  | `BIGINT`         | Number of members in the nomination pool                                       |
| `nominationpools_commission`  | `DOUBLE`         | Commission rate of the nomination pool                                         |
| `nominationpools_rewardpools` | `VARCHAR`        | JSON-encoded reward pool data for the nomination pool                          |
| `member_bonded`               | `DOUBLE`         | Amount bonded by a pool member                                                 |
| `member_unbonded`             | `DOUBLE`         | Amount in the process of unbonding for a pool member                           |
| `member_share`                | `DOUBLE`         | Pool member's share of the pool's total stake                                  |
| `targets`                     | `ARRAY(VARCHAR)` | List of validator addresses targeted by this nominator                         |
| `pv`                          | `VARCHAR`        | Protocol version or parameter value                                            |
| `track`                       | `VARCHAR`        | Governance track for OpenGov-related staking data                              |
| `updated_at`                  | `TIMESTAMP`      | When this record was last updated in the database                              |
| `ingested_at`                 | `TIMESTAMP`      | When this record was first ingested into the database                          |

## Table Sample

<TableSample />


# polkadot.traces
Source: https://docs.dune.com/data-catalog/substrate/traces

Polkadot execution traces — detailed runtime execution data across pallets.

## Table description

The `polkadot.traces` table, also known as the "snapshot" table, stores relevant on-chain state data that is otherwise difficult to acquire from base Substrate tables such as extrinsics and events. The traces tables are populated with special scripts modeling key storage elements at the end of the hour or day.

Having these snapshots enables Dune analysts to build useful dashboards on Dune
such as:

* [Polkadot Staking](https://dune.com/substrate/polkadot-staking)
* [Polkadot OpenGov](https://dune.com/substrate/polkadot-gov)
* [HydraDX OmniPool](https://dune.com/substrate/hydradx)
* [Interlay Vaults](https://dune.com/substrate/interlay)

## Table Schema

| Column           | Type        | Description                                                        |
| ---------------- | ----------- | ------------------------------------------------------------------ |
| `year`           | `INTEGER`   | Calendar year of the snapshot (partition column)                   |
| `month`          | `INTEGER`   | Calendar month of the snapshot (partition column)                  |
| `section`        | `VARCHAR`   | The pallet (module) of the storage item being traced               |
| `storage`        | `VARCHAR`   | The specific storage item name being traced                        |
| `ts`             | `TIMESTAMP` | Timestamp of the state snapshot                                    |
| `block_number`   | `BIGINT`    | The block number at which the snapshot was taken                   |
| `block_hash`     | `VARBINARY` | Hash of the block at which the snapshot was taken                  |
| `chain_name`     | `VARCHAR`   | Name of the Substrate chain (e.g. `polkadot`, `kusama`, `hydradx`) |
| `address_ss58`   | `VARCHAR`   | SS58-encoded address associated with this trace entry              |
| `address_pubkey` | `VARBINARY` | Public key associated with this trace entry                        |
| `track`          | `VARCHAR`   | Category or governance track for grouping trace data               |
| `track_val`      | `VARCHAR`   | Value associated with the track                                    |
| `kv`             | `VARCHAR`   | JSON-encoded key-value data from the storage item                  |
| `pv`             | `VARCHAR`   | Protocol version or parameter value                                |
| `source`         | `VARCHAR`   | Source or origin of the trace data                                 |
| `updated_at`     | `TIMESTAMP` | When this record was last updated in the database                  |
| `ingested_at`    | `TIMESTAMP` | When this record was first ingested into the database              |

## Table Sample

<TableSample />

<TableSample />

<TableSample />

<TableSample />

<TableSample />


# polkadot.transfers
Source: https://docs.dune.com/data-catalog/substrate/transfers

Polkadot native token (DOT) transfers — sender, recipient, amount, and transfer type.

## Table description

The `polkadot.transfers` table the Substrate transfers table stores the types of stored assets, the sender and recipient, and the estimated value of the tokens converted into USD, if available.

## Table Schema

| Column           | Type            | Description                                                        |
| ---------------- | --------------- | ------------------------------------------------------------------ |
| `year`           | `INTEGER`       | Calendar year of the block (partition column)                      |
| `month`          | `INTEGER`       | Calendar month of the block (partition column)                     |
| `day`            | `INTEGER`       | Calendar day of the block (partition column)                       |
| `block_time`     | `TIMESTAMP`     | The timestamp of the block containing this transfer                |
| `block_number`   | `BIGINT`        | The sequential number of the block containing this transfer        |
| `event_id`       | `VARCHAR`       | Unique identifier of the event that recorded this transfer         |
| `extrinsic_id`   | `VARCHAR`       | Identifier of the extrinsic that initiated this transfer           |
| `section`        | `VARCHAR`       | The pallet (module) that processed this transfer (e.g. `Balances`) |
| `method`         | `VARCHAR`       | The transfer method name (e.g. `Transfer`, `TransferKeepAlive`)    |
| `extrinsic_hash` | `VARBINARY`     | Hash of the extrinsic that initiated this transfer                 |
| `block_hash`     | `VARBINARY`     | Hash of the block containing this transfer                         |
| `from_ss58`      | `VARCHAR`       | SS58-encoded address of the sender                                 |
| `from_pub_key`   | `VARBINARY`     | Public key of the sender                                           |
| `to_ss58`        | `VARCHAR`       | SS58-encoded address of the recipient                              |
| `to_pub_key`     | `VARBINARY`     | Public key of the recipient                                        |
| `asset`          | `VARCHAR`       | Asset type or identifier being transferred                         |
| `symbol`         | `VARCHAR`       | Token symbol of the transferred asset (e.g. `DOT`, `KSM`)          |
| `decimals`       | `BIGINT`        | Number of decimal places for the token                             |
| `amount`         | `DOUBLE`        | Transfer amount in human-readable units                            |
| `raw_amount`     | `DECIMAL(38,9)` | Transfer amount in the smallest denomination (Planck)              |
| `updated_at`     | `TIMESTAMP`     | When this record was last updated in the database                  |
| `ingested_at`    | `TIMESTAMP`     | When this record was first ingested into the database              |

## Table Sample

<TableSample />


# succinct.bids
Source: https://docs.dune.com/data-catalog/succinct/bids

Succinct prover bids — bid amounts, prover addresses, and auction outcomes.

The `succinct.bids` table contains all proof generation bids submitted by provers in the Succinct Network. Each bid represents a prover's offer to generate a ZK proof for a specific request at a given price, participating in the auction-based proof contest mechanism.

## Table Schema

| Column Name    | Data Type     | Description                                         |
| -------------- | ------------- | --------------------------------------------------- |
| id             | long          | Unique identifier for the bid                       |
| tx\_hash       | binary        | Transaction hash of the bid submission              |
| prover         | binary        | Address of the prover submitting the bid            |
| request\_id    | binary        | Unique identifier for the proof request             |
| amount         | bigint        | Amount of PROVE tokens bid for the proof generation |
| created\_at    | timestamp     | Timestamp when the bid was submitted                |
| stake          | decimal(38,0) | Amount of PROVE tokens staked by the prover         |
| date           | date          | Date when the bid was submitted                     |
| \_updated\_at  | timestamp     | Last update timestamp                               |
| \_ingested\_at | timestamp     | Ingestion timestamp                                 |

## Sample Query

```sql theme={null}
-- Get the total number of bids and total amount bid per prover
SELECT 
    prover,
    COUNT(*) as bid_count,
    SUM(amount) as total_bid_amount
FROM succinct.bids
WHERE created_at >= NOW() - INTERVAL '7' DAY
GROUP BY prover
ORDER BY total_bid_amount DESC
LIMIT 10;
```


# Succinct
Source: https://docs.dune.com/data-catalog/succinct/overview

Succinct protocol data on Dune

Succinct is a protocol on Ethereum that proves the world's software. It coordinates hardware teams, infrastructure operators, and application developers to facilitate the generation of zero knowledge proofs. Application developers send programs in normal code that are wrapped with SP1 to the Succinct Network, allowing infrastructure and hardware teams (jointly called provers) to compete to generate proofs of the programs' execution.

## Key Features

* **Decentralized Prover Network**: The world's first decentralized protocol for ZK proving, enabling permissionless participation
* **High Performance Architecture**: Verifiable application (vApp) that settles to Ethereum with off-chain auctioneer service and on-chain settlement contracts
* **Competitive Pricing**: Auction-based mechanism where provers compete to generate proofs at the lowest cost
* **PROVE Token**: Native token enabling payments, incentivizing provers, and securing the network through staking and governance
* **Universal Compatibility**: Supports ZK rollups, bridges, games, oracles, AI agents, and more

## Protocol Architecture

The Succinct Network operates as a global, two-sided marketplace composed of provers and requesters. Provers compete to generate ZK proofs of programs submitted by requesters through an auction mechanism called proof contests. The network is architected as a verifiable application that settles to Ethereum, providing high performance while maintaining verifiability.

## Succinct Data on Dune

<CardGroup>
  <Card title="Bids" icon="database" href="/data-catalog/succinct/bids">
    Contains all proof generation bids submitted by provers in the network
  </Card>

  <Card title="Requests" icon="database" href="/data-catalog/succinct/requests">
    Contains all proof requests submitted by application developers
  </Card>
</CardGroup>

<CardGroup>
  <Card title="Succinct Documentation" icon="link" href="https://docs.succinct.xyz/docs/protocol/what-is-succinct">
    The official documentation for Succinct, providing detailed information on the protocol, architecture, and developer resources
  </Card>
</CardGroup>


# succinct.requests
Source: https://docs.dune.com/data-catalog/succinct/requests

Succinct proof generation requests — proof type, input parameters, and submission details.

The `succinct.requests` table contains all proof requests submitted by application developers to the Succinct Network. Each request represents a demand for ZK proof generation, which provers can then bid on through the auction mechanism.

## Table Schema

| Column Name          | Data Type     | Description                                                 |
| -------------------- | ------------- | ----------------------------------------------------------- |
| vk\_hash             | binary        | Verification key hash for the proof request                 |
| requester            | binary        | Address of the application developer submitting the request |
| fulfiller\_address   | binary        | Address of the prover that fulfilled the request            |
| gas\_price           | bigint        | Gas price for the request transaction                       |
| max\_price\_per\_gas | bigint        | Maximum price per gas unit the requester is willing to pay  |
| gas\_used            | bigint        | Gas used for the request transaction                        |
| gas\_limit           | bigint        | Gas limit for the request transaction                       |
| cycles               | bigint        | Number of computational cycles required for the proof       |
| created\_at          | timestamp     | Timestamp when the request was submitted                    |
| fulfilled\_at        | timestamp     | Timestamp when the request was fulfilled                    |
| deadline             | timestamp     | Deadline by which the proof must be generated               |
| date                 | date          | Date when the request was submitted                         |
| tx\_hash             | binary        | Transaction hash of the request submission                  |
| id                   | binary        | Unique identifier for the proof request                     |
| sender               | binary        | Address of the sender (may be different from requester)     |
| base\_fee            | decimal(38,0) | Base fee for the transaction                                |
| min\_auction\_period | bigint        | Minimum auction period in seconds                           |
| \_updated\_at        | timestamp     | Last update timestamp                                       |
| \_ingested\_at       | timestamp     | Ingestion timestamp                                         |

## Sample Query

```sql theme={null}
-- Get the total number of requests and fulfillment rates by requester
SELECT 
    requester,
    COUNT(*) as total_requests,
    COUNT(CASE WHEN fulfiller_address IS NOT NULL THEN 1 END) as fulfilled_requests,
    COUNT(CASE WHEN fulfiller_address IS NOT NULL THEN 1 END) * 100.0 / COUNT(*) as fulfillment_rate
FROM succinct.requests
WHERE created_at >= NOW() - INTERVAL '30' DAY
GROUP BY requester
ORDER BY total_requests DESC
LIMIT 10;
```

## Sample Query

```sql theme={null}
-- Get request activity and gas usage over time
SELECT 
    DATE_TRUNC('day', created_at) as day,
    COUNT(*) as total_requests,
    AVG(gas_used) as avg_gas_used,
    SUM(gas_used) as total_gas_used
FROM succinct.requests
WHERE created_at >= NOW() - INTERVAL '7' DAY
GROUP BY DATE_TRUNC('day', created_at)
ORDER BY day DESC;
```


# sui.checkpoints
Source: https://docs.dune.com/data-catalog/sui/checkpoints

Sui checkpoints — finalized checkpoint data with transaction digests and timestamps.

## Table Description

The `sui.checkpoints` table contains checkpoint data from the Sui blockchain. Checkpoints are fundamental units of consensus in Sui, representing a collection of transactions that have been finalized and agreed upon by validators. This table is partitioned by date.

## Column Descriptions

| **Column**                                 | **Type**      | **Description**                                                             |
| ------------------------------------------ | ------------- | --------------------------------------------------------------------------- |
| **checkpoint\_digest**                     | string        | Unique hash identifier of the checkpoint                                    |
| **sequence\_number**                       | decimal(20,0) | Sequential number of the checkpoint                                         |
| **epoch**                                  | decimal(20,0) | Epoch number when the checkpoint was created                                |
| **timestamp\_ms**                          | decimal(20,0) | Unix timestamp in milliseconds when the checkpoint was created              |
| **date**                                   | date          | Date of when the checkpoint was created                                     |
| **previous\_checkpoint\_digest**           | string        | Hash of the previous checkpoint                                             |
| **end\_of\_epoch**                         | boolean       | Whether this checkpoint marks the end of an epoch                           |
| **total\_gas\_cost**                       | bigint        | Total gas cost for all transactions in this checkpoint                      |
| **computation\_cost**                      | decimal(20,0) | Total computation cost for transactions in this checkpoint                  |
| **storage\_cost**                          | decimal(20,0) | Total storage cost for transactions in this checkpoint                      |
| **storage\_rebate**                        | decimal(20,0) | Total storage rebate for transactions in this checkpoint                    |
| **non\_refundable\_storage\_fee**          | decimal(20,0) | Non-refundable storage fees                                                 |
| **total\_transaction\_blocks**             | decimal(20,0) | Total number of transaction blocks in this checkpoint                       |
| **total\_transactions**                    | decimal(20,0) | Total number of transactions in this checkpoint                             |
| **total\_successful\_transaction\_blocks** | decimal(20,0) | Total number of successful transaction blocks in this checkpoint            |
| **total\_successful\_transactions**        | decimal(20,0) | Total number of successful transactions in this checkpoint                  |
| **network\_total\_transaction**            | decimal(20,0) | Total number of transactions processed by the network up to this checkpoint |
| **validator\_signature**                   | string        | Validator signature for this checkpoint                                     |
| **\_updated\_at**                          | timestamp     | Last time the record was updated                                            |
| **\_ingested\_at**                         | timestamp     | Time when the record was ingested                                           |

## Table Sample

<TableSample />


# sui.events
Source: https://docs.dune.com/data-catalog/sui/events

Sui on-chain events — events emitted by Move packages during execution.

## Table Description

The `sui.events` table contains event data emitted by smart contracts and system operations on the Sui blockchain. Events provide a way for smart contracts to communicate state changes and important information to external systems. This table is partitioned by date.

## Column Descriptions

| **Column**              | **Type**      | **Description**                                                |
| ----------------------- | ------------- | -------------------------------------------------------------- |
| **transaction\_digest** | string        | Hash of the transaction that emitted this event                |
| **event\_index**        | decimal(20,0) | Index/sequence number of the event within the transaction      |
| **checkpoint**          | decimal(20,0) | Checkpoint sequence number containing this event               |
| **epoch**               | decimal(20,0) | Epoch number when the event was emitted                        |
| **timestamp\_ms**       | decimal(20,0) | Unix timestamp in milliseconds when the event was emitted      |
| **date**                | date          | Date of when the event was emitted                             |
| **sender**              | binary        | Binary representation of the sender address                    |
| **package**             | binary        | Binary representation of the package ID that emitted the event |
| **module**              | string        | Module name that emitted the event                             |
| **event\_type**         | string        | Type of the event (e.g., TransferObject, CoinBalanceChange)    |
| **bcs**                 | string        | Binary Canonical Serialization of the event data               |
| **event\_json**         | string        | JSON representation of the event data                          |
| **bcs\_length**         | decimal(20,0) | Length of the BCS data in bytes                                |
| **\_updated\_at**       | timestamp     | Last time the record was updated                               |
| **\_ingested\_at**      | timestamp     | Time when the record was ingested                              |

## Table Sample

<TableSample />


# sui.move_call
Source: https://docs.dune.com/data-catalog/sui/move_call

Sui Move function calls — package, module, and function invocations.

## Table Description

The `sui.move_call` table contains data about Move function calls executed on the Sui blockchain. This table tracks all smart contract function invocations, including the package, module, and function details. This table is partitioned by date.

## Column Descriptions

| **Column**              | **Type**      | **Description**                                                        |
| ----------------------- | ------------- | ---------------------------------------------------------------------- |
| **transaction\_digest** | string        | Hash of the transaction containing this move call                      |
| **checkpoint**          | decimal(20,0) | Checkpoint sequence number containing this move call                   |
| **epoch**               | decimal(20,0) | Epoch number when the move call was executed                           |
| **timestamp\_ms**       | decimal(20,0) | Unix timestamp in milliseconds when the move call was executed         |
| **date**                | date          | Date of when the move call was executed                                |
| **package**             | binary        | Binary representation of the package ID containing the called function |
| **module**              | string        | Name of the module containing the called function                      |
| **function**            | string        | Name of the called function                                            |
| **\_updated\_at**       | timestamp     | Last time the record was updated                                       |
| **\_ingested\_at**      | timestamp     | Time when the record was ingested                                      |

## Table Sample

<TableSample />


# sui.move_package
Source: https://docs.dune.com/data-catalog/sui/move_package

Sui Move package deployments — published packages and upgrade records.

## Table Description

The `sui.move_package` table contains information about Move packages deployed on the Sui blockchain. Move packages are collections of Move modules that define smart contracts and their functionality. This table tracks package deployments, updates, and metadata. This table is partitioned by date.

## Column Descriptions

| **Column**                | **Type**      | **Description**                                                      |
| ------------------------- | ------------- | -------------------------------------------------------------------- |
| **package\_id**           | binary        | Binary representation of the unique identifier of the Move package   |
| **checkpoint**            | decimal(20,0) | Checkpoint sequence number containing this package operation         |
| **epoch**                 | decimal(20,0) | Epoch number when the package was deployed/updated                   |
| **timestamp\_ms**         | decimal(20,0) | Unix timestamp in milliseconds when the package was deployed/updated |
| **date**                  | date          | Date of when the package was deployed/updated                        |
| **bcs**                   | string        | Binary Canonical Serialization of the package data                   |
| **transaction\_digest**   | string        | Hash of the transaction that deployed/updated this package           |
| **package\_version**      | decimal(20,0) | Version number of the package                                        |
| **original\_package\_id** | binary        | Binary representation of the original package ID (for upgrades)      |
| **bcs\_length**           | decimal(20,0) | Length of the BCS data in bytes                                      |
| **\_updated\_at**         | timestamp     | Last time the record was updated                                     |
| **\_ingested\_at**        | timestamp     | Time when the record was ingested                                    |

## Table Sample

<TableSample />


# sui.objects
Source: https://docs.dune.com/data-catalog/sui/objects

Sui object data — owned and shared objects with type, version, and ownership info.

## Table Description

The `sui.objects` table contains data about Sui objects, which are the fundamental units of data storage on the Sui blockchain. Unlike traditional blockchains that use key-value stores, Sui uses an object-centric model where data is stored as objects with unique identifiers. This table is partitioned by date.

## Column Descriptions

| **Column**                   | **Type**      | **Description**                                                                |
| ---------------------------- | ------------- | ------------------------------------------------------------------------------ |
| **object\_id**               | binary        | Binary representation of the unique identifier of the object                   |
| **version**                  | decimal(20,0) | Version number of the object                                                   |
| **digest**                   | string        | Hash digest of the object contents                                             |
| **type\_**                   | string        | Type of the object (e.g., "0x2::coin::Coin\<0x2::sui::SUI>")                   |
| **checkpoint**               | decimal(20,0) | Checkpoint sequence number containing this object operation                    |
| **epoch**                    | decimal(20,0) | Epoch number when the object was created/updated                               |
| **timestamp\_ms**            | decimal(20,0) | Unix timestamp in milliseconds when the object was created/updated             |
| **date**                     | date          | Date of when the object was created/updated                                    |
| **owner\_type**              | string        | Type of ownership (e.g., "AddressOwner", "ObjectOwner", "Shared", "Immutable") |
| **owner\_address**           | binary        | Binary representation of the owner address (if applicable)                     |
| **object\_status**           | string        | Status of the object (e.g., "Created", "Mutated", "Deleted")                   |
| **initial\_shared\_version** | decimal(20,0) | Initial shared version for shared objects                                      |
| **previous\_transaction**    | string        | Hash of the previous transaction that modified this object                     |
| **has\_public\_transfer**    | boolean       | Whether the object can be publicly transferred                                 |
| **is\_consensus**            | boolean       | Whether this is a consensus object                                             |
| **storage\_rebate**          | decimal(20,0) | Storage rebate for this object                                                 |
| **bcs**                      | string        | Binary Canonical Serialization of the object data                              |
| **coin\_type**               | string        | Type of coin if this object is a coin                                          |
| **coin\_balance**            | decimal(20,0) | Balance of the coin if this object is a coin                                   |
| **struct\_tag**              | string        | Struct tag of the object                                                       |
| **object\_json**             | string        | JSON representation of the object data                                         |
| **bcs\_length**              | decimal(20,0) | Length of the BCS data in bytes                                                |
| **\_updated\_at**            | timestamp     | Last time the record was updated                                               |
| **\_ingested\_at**           | timestamp     | Time when the record was ingested                                              |

## Table Sample

<TableSample />


# Sui Data
Source: https://docs.dune.com/data-catalog/sui/overview

Sui blockchain data on Dune

## What is Sui?

Sui is a layer 1 blockchain protocol designed for high performance and scalability. The name derives from the Japanese word for water, reflecting the platform's fluid and adaptable nature. Sui features several key innovations:

* **Object-Centric Architecture**: Unlike traditional blockchains that use key-value stores, Sui treats blocks as objects that define assets, enabling more sophisticated programmability.
* **Delegated Proof-of-Stake (DPoS)**: Energy-efficient consensus mechanism where validators stake SUI tokens to secure the network.
* **Move Programming Language**: A robust logic engine specifically designed for Sui's object-based approach to blockchain technology.
* **Parallel Transaction Processing**: Enables high throughput by processing independent transactions simultaneously.

## Sui Networks

Sui operates across multiple networks serving different purposes:

* **Mainnet**: Production network processing real transactions and handling SUI trading and NFT activities
* **Testnet**: Staging environment for quality assurance and developer testing
* **Devnet**: Development network for testing new features and latest planned capabilities
* **Localnet**: Local development environment for optimized workflows

## SUI Token Economics

The native token for Sui is **SUI**, with **MIST** serving as the smallest unit (1 SUI = 1 billion MIST). All transaction costs, including gas fees and data storage, are paid using SUI tokens. The platform uses a delegated proof-of-stake model where validators must stake SUI to participate in consensus, aligning their interests with network security and efficiency.

## Sui Data on Dune

Sui blockchain data is organized into several key tables that capture different aspects of on-chain activity:

<CardGroup>
  <Card title="Checkpoints" icon="cube" href="/data-catalog/sui/checkpoints">
    Checkpoint data representing finalized collections of transactions agreed upon by validators.
  </Card>

  <Card title="Events" icon="calendar" href="/data-catalog/sui/events">
    Event data emitted by smart contracts and system operations on the Sui blockchain.
  </Card>

  <Card title="Move Call" icon="code" href="/data-catalog/sui/move_call">
    Data about Move function calls executed on the Sui blockchain.
  </Card>

  <Card title="Move Package" icon="box" href="/data-catalog/sui/move_package">
    Information about Move packages deployed on the Sui blockchain.
  </Card>

  <Card title="Objects" icon="shapes" href="/data-catalog/sui/objects">
    Sui's unique object-centric data including object states, ownership, and metadata.
  </Card>

  <Card title="Transaction Objects" icon="link" href="/data-catalog/sui/transaction_objects">
    Objects involved in transactions, tracking which objects are read, written, or deleted.
  </Card>

  <Card title="Transactions" icon="arrow-right-arrow-left" href="/data-catalog/sui/transactions">
    Comprehensive transaction data including transfers, smart contract interactions, and system operations.
  </Card>

  <Card title="Wrapped Object" icon="layer-group" href="/data-catalog/sui/wrapped_object">
    Data about wrapped objects and their hierarchical ownership structure.
  </Card>
</CardGroup>


# sui.transaction_objects
Source: https://docs.dune.com/data-catalog/sui/transaction_objects

Sui transaction-object relationships — objects created, mutated, or deleted per transaction.

## Table Description

The `sui.transaction_objects` table contains data about objects that are involved in transactions on the Sui blockchain. This table tracks which objects are read, written, or deleted in each transaction, providing a comprehensive view of object interactions. This table is partitioned by date.

## Column Descriptions

| **Column**              | **Type**      | **Description**                                                           |
| ----------------------- | ------------- | ------------------------------------------------------------------------- |
| **object\_id**          | binary        | Binary representation of the unique identifier of the object              |
| **version**             | decimal(20,0) | Version of the object in this transaction                                 |
| **transaction\_digest** | string        | Hash of the transaction                                                   |
| **checkpoint**          | decimal(20,0) | Checkpoint sequence number containing this transaction                    |
| **epoch**               | decimal(20,0) | Epoch number when the transaction was executed                            |
| **timestamp\_ms**       | decimal(20,0) | Unix timestamp in milliseconds when the transaction was executed          |
| **date**                | date          | Date of when the transaction was executed                                 |
| **input\_kind**         | string        | Kind of input for this object (e.g., "Input", "SharedInput", "Receiving") |
| **object\_status**      | string        | Status of the object (e.g., "Created", "Mutated", "Deleted", "Unchanged") |
| **\_updated\_at**       | timestamp     | Last time the record was updated                                          |
| **\_ingested\_at**      | timestamp     | Time when the record was ingested                                         |

## Table Sample

<TableSample />


# sui.transactions
Source: https://docs.dune.com/data-catalog/sui/transactions

Sui transaction records — sender, gas, status, and transaction kind.

## Table Description

The `sui.transactions` table contains comprehensive transaction data from the Sui blockchain. This table records all transactions processed on the network, including transfers, smart contract interactions, and system operations. This table is partitioned by date.

## Column Descriptions

| **Column**                         | **Type**      | **Description**                                                                 |
| ---------------------------------- | ------------- | ------------------------------------------------------------------------------- |
| **transaction\_digest**            | string        | Unique hash identifier of the transaction                                       |
| **checkpoint**                     | decimal(20,0) | Checkpoint sequence number containing this transaction                          |
| **epoch**                          | decimal(20,0) | Epoch number when the transaction was executed                                  |
| **timestamp\_ms**                  | decimal(20,0) | Unix timestamp in milliseconds when transaction was executed                    |
| **date**                           | date          | Date of when the transaction was executed                                       |
| **sender**                         | binary        | Binary representation of the address that initiated the transaction             |
| **transaction\_kind**              | string        | Type of transaction (e.g., "ProgrammableTransaction", "ChangeEpoch", "Genesis") |
| **is\_system\_txn**                | boolean       | Whether this is a system transaction                                            |
| **is\_sponsored\_tx**              | boolean       | Whether this is a sponsored transaction                                         |
| **transaction\_count**             | decimal(20,0) | Number of transactions in the batch                                             |
| **execution\_success**             | boolean       | Whether the transaction executed successfully                                   |
| **input**                          | decimal(20,0) | Number of input objects                                                         |
| **shared\_input**                  | decimal(20,0) | Number of shared input objects                                                  |
| **gas\_coins**                     | decimal(20,0) | Number of gas coins used                                                        |
| **created**                        | decimal(20,0) | Number of objects created                                                       |
| **mutated**                        | decimal(20,0) | Number of objects mutated                                                       |
| **deleted**                        | decimal(20,0) | Number of objects deleted                                                       |
| **transfers**                      | decimal(20,0) | Number of transfers performed                                                   |
| **split\_coins**                   | decimal(20,0) | Number of coin splits performed                                                 |
| **merge\_coins**                   | decimal(20,0) | Number of coin merges performed                                                 |
| **publish**                        | decimal(20,0) | Number of packages published                                                    |
| **upgrade**                        | decimal(20,0) | Number of package upgrades                                                      |
| **others**                         | decimal(20,0) | Number of other operations                                                      |
| **move\_calls**                    | decimal(20,0) | Number of move calls made                                                       |
| **packages**                       | string        | Packages involved in the transaction                                            |
| **gas\_owner**                     | binary        | Binary representation of the gas owner address                                  |
| **gas\_object\_id**                | binary        | Binary representation of the gas object ID                                      |
| **gas\_object\_sequence**          | decimal(20,0) | Sequence number of the gas object                                               |
| **gas\_object\_digest**            | string        | Digest of the gas object                                                        |
| **gas\_budget**                    | decimal(20,0) | Gas budget allocated for the transaction                                        |
| **total\_gas\_cost**               | bigint        | Total gas cost for the transaction                                              |
| **computation\_cost**              | decimal(20,0) | Computation cost component of gas                                               |
| **storage\_cost**                  | decimal(20,0) | Storage cost component of gas                                                   |
| **storage\_rebate**                | decimal(20,0) | Storage rebate received                                                         |
| **non\_refundable\_storage\_fee**  | decimal(20,0) | Non-refundable storage fees                                                     |
| **gas\_price**                     | decimal(20,0) | Gas price for the transaction                                                   |
| **raw\_transaction**               | string        | Raw transaction data                                                            |
| **has\_zklogin\_sig**              | boolean       | Whether the transaction has zkLogin signature                                   |
| **has\_upgraded\_multisig**        | boolean       | Whether the transaction has upgraded multisig                                   |
| **transaction\_json**              | string        | JSON representation of the transaction                                          |
| **effects\_json**                  | string        | JSON representation of the transaction effects                                  |
| **transaction\_position**          | decimal(20,0) | Position of the transaction within the checkpoint                               |
| **events\_digest**                 | string        | Digest of events emitted by the transaction                                     |
| **transaction\_data\_bcs\_length** | decimal(20,0) | Length of transaction data BCS in bytes                                         |
| **effects\_bcs\_length**           | decimal(20,0) | Length of effects BCS in bytes                                                  |
| **events\_bcs\_length**            | decimal(20,0) | Length of events BCS in bytes                                                   |
| **signatures\_bcs\_length**        | decimal(20,0) | Length of signatures BCS in bytes                                               |
| **\_updated\_at**                  | timestamp     | Last time the record was updated                                                |
| **\_ingested\_at**                 | timestamp     | Time when the record was ingested                                               |

## Table Sample

<TableSample />


# sui.wrapped_object
Source: https://docs.dune.com/data-catalog/sui/wrapped_object

Sui wrapped object records — objects contained within other objects.

## Table Description

The `sui.wrapped_object` table contains data about wrapped objects on the Sui blockchain. Wrapped objects are objects that have been wrapped by another object, creating a hierarchical ownership structure. This table tracks the wrapping relationships and metadata. This table is partitioned by date.

## Column Descriptions

| **Column**                | **Type**      | **Description**                                                                                     |
| ------------------------- | ------------- | --------------------------------------------------------------------------------------------------- |
| **object\_id**            | binary        | Binary representation of the unique identifier of the wrapped object                                |
| **root\_object\_id**      | binary        | Binary representation of the unique identifier of the root object that contains this wrapped object |
| **root\_object\_version** | decimal(20,0) | Version of the root object                                                                          |
| **checkpoint**            | decimal(20,0) | Checkpoint sequence number containing this wrapping operation                                       |
| **epoch**                 | decimal(20,0) | Epoch number when the object was wrapped                                                            |
| **timestamp\_ms**         | decimal(20,0) | Unix timestamp in milliseconds when the object was wrapped                                          |
| **date**                  | date          | Date of when the object was wrapped                                                                 |
| **json\_path**            | string        | JSON path to the wrapped object within the root object                                              |
| **struct\_tag**           | string        | Struct tag of the wrapped object                                                                    |
| **\_updated\_at**         | timestamp     | Last time the record was updated                                                                    |
| **\_ingested\_at**        | timestamp     | Time when the record was ingested                                                                   |

## Table Sample

<TableSample />


# thorchain.core_block
Source: https://docs.dune.com/data-catalog/thorchain/core_block

THORChain block data — block height, timestamp, and chain metadata.

## Table Description

The `thorchain.core_block` table contains block-level data from the THORChain blockchain including block headers, timestamps, and block statistics. This table is partitioned by block\_month.

## Column Descriptions

| **Column**                | **Type**  | **Description**                         |
| ------------------------- | --------- | --------------------------------------- |
| **block\_id**             | bigint    | Identifier                              |
| **block\_time**           | timestamp | Timestamp of when the block was created |
| **block\_timestamp**      | timestamp | Timestamp of when the block was created |
| **block\_date**           | timestamp | Date of when the block was created      |
| **block\_hour**           | timestamp | Block Hour                              |
| **block\_week**           | timestamp | Block Week                              |
| **block\_month**          | timestamp | Block Month                             |
| **block\_quarter**        | timestamp | Block Quarter                           |
| **block\_year**           | timestamp | Block Year                              |
| **block\_dayofmonth**     | timestamp | Block Dayofmonth                        |
| **block\_dayofweek**      | timestamp | Block Dayofweek                         |
| **block\_dayofyear**      | timestamp | Block Dayofyear                         |
| **timestamp**             | timestamp | Timestamp of the record                 |
| **hash**                  | varchar   | Hash                                    |
| **agg\_state**            | varchar   | Agg State                               |
| **\_inserted\_timestamp** | timestamp | Timestamp of the record                 |
| **inserted\_timestamp**   | timestamp | Time when the record was inserted       |
| **modified\_timestamp**   | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.core_instantiate_events
Source: https://docs.dune.com/data-catalog/thorchain/core_instantiate_events

THORChain module instantiation events.

## Table Description

The `thorchain.core_instantiate_events` table event data for contract instantiation events on THORChain. This table tracks when smart contracts are instantiated on the network. This table is partitioned by block\_month.

## Column Descriptions

| **Column**                        | **Type**  | **Description**                         |
| --------------------------------- | --------- | --------------------------------------- |
| **tx\_id**                        | bigint    | Transaction ID                          |
| **contract\_address**             | varchar   | Address                                 |
| **admin\_address**                | varchar   | Address                                 |
| **code\_id**                      | bigint    | Identifier                              |
| **sender**                        | varchar   | Sender                                  |
| **label**                         | varchar   | Label                                   |
| **msg**                           | varchar   | Msg                                     |
| **funds**                         | varchar   | Funds                                   |
| **event\_id**                     | bigint    | Event identifier                        |
| **block\_timestamp**              | timestamp | Timestamp of when the block was created |
| **block\_time**                   | timestamp | Timestamp of when the block was created |
| **block\_month**                  | timestamp | Block Month                             |
| **\_inserted\_timestamp**         | timestamp | Timestamp of the record                 |
| **fact\_instantiate\_events\_id** | bigint    | Surrogate key for the fact record       |
| **dim\_block\_id**                | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**           | timestamp | Time when the record was inserted       |
| **modified\_timestamp**           | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.core_network_version_events
Source: https://docs.dune.com/data-catalog/thorchain/core_network_version_events

THORChain network version upgrade events.

## Table Description

The `thorchain.core_network_version_events` table event data for network version on THORChain. This table is partitioned by block\_month.

## Column Descriptions

| **Column**                | **Type**  | **Description**                         |
| ------------------------- | --------- | --------------------------------------- |
| **version**               | varchar   | Version                                 |
| **event\_id**             | bigint    | Event identifier                        |
| **block\_timestamp**      | timestamp | Timestamp of when the block was created |
| **block\_time**           | timestamp | Timestamp of when the block was created |
| **block\_month**          | timestamp | Block Month                             |
| **\_inserted\_timestamp** | timestamp | Timestamp of the record                 |
| **dim\_block\_id**        | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**   | timestamp | Time when the record was inserted       |
| **modified\_timestamp**   | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.core_set_mimir_events
Source: https://docs.dune.com/data-catalog/thorchain/core_set_mimir_events

THORChain Mimir governance parameter change events.

## Table Description

The `thorchain.core_set_mimir_events` table event data for set mimir on THORChain. This table is partitioned by block\_month.

## Column Descriptions

| **Column**                       | **Type**  | **Description**                         |
| -------------------------------- | --------- | --------------------------------------- |
| **key**                          | varchar   | Key                                     |
| **value**                        | varchar   | Value                                   |
| **event\_id**                    | bigint    | Event identifier                        |
| **block\_timestamp**             | timestamp | Timestamp of when the block was created |
| **block\_time**                  | timestamp | Timestamp of when the block was created |
| **block\_month**                 | timestamp | Block Month                             |
| **\_inserted\_timestamp**        | timestamp | Timestamp of the record                 |
| **fact\_set\_mimir\_events\_id** | bigint    | Surrogate key for the fact record       |
| **dim\_block\_id**               | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**          | timestamp | Time when the record was inserted       |
| **modified\_timestamp**          | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.core_thorname_change_events
Source: https://docs.dune.com/data-catalog/thorchain/core_thorname_change_events

THORChain THORName registration and update events.

## Table Description

The `thorchain.core_thorname_change_events` table event data for thorname change on THORChain. This table is partitioned by block\_month.

## Column Descriptions

| **Column**                             | **Type**  | **Description**                         |
| -------------------------------------- | --------- | --------------------------------------- |
| **owner**                              | varchar   | Owner                                   |
| **chain**                              | varchar   | Chain                                   |
| **address**                            | varchar   | Address                                 |
| **expire**                             | varchar   | Expire                                  |
| **name**                               | varchar   | Name                                    |
| **fund\_amount\_e8**                   | bigint    | Amount value                            |
| **registration\_fee\_e8**              | bigint    | Registration Fee E8                     |
| **event\_id**                          | bigint    | Event identifier                        |
| **block\_timestamp**                   | timestamp | Timestamp of when the block was created |
| **block\_time**                        | timestamp | Timestamp of when the block was created |
| **block\_month**                       | timestamp | Block Month                             |
| **\_inserted\_timestamp**              | timestamp | Timestamp of the record                 |
| **fact\_thorname\_change\_events\_id** | bigint    | Surrogate key for the fact record       |
| **dim\_block\_id**                     | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**                | timestamp | Time when the record was inserted       |
| **modified\_timestamp**                | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.core_transfer_events
Source: https://docs.dune.com/data-catalog/thorchain/core_transfer_events

THORChain native RUNE transfer events.

## Table Description

The `thorchain.core_transfer_events` table event data for native asset transfers on THORChain. This table captures transfer events between addresses. This table is partitioned by day.

## Column Descriptions

| **Column**                     | **Type**  | **Description**                             |
| ------------------------------ | --------- | ------------------------------------------- |
| **from\_address**              | varchar   | Source address                              |
| **to\_address**                | varchar   | Destination address                         |
| **asset**                      | varchar   | Asset identifier                            |
| **amount\_e8**                 | bigint    | Amount in e8 units (1e8 = 1 unit)           |
| **event\_id**                  | bigint    | Event identifier                            |
| **block\_timestamp**           | timestamp | Timestamp of when the block was created     |
| **\_inserted\_timestamp**      | timestamp | Timestamp of the record                     |
| **fact\_transfer\_events\_id** | bigint    | Surrogate key for the transfer event record |
| **day**                        | timestamp | Date of the record                          |
| **dim\_block\_id**             | bigint    | Reference to the block dimension table      |
| **inserted\_timestamp**        | timestamp | Time when the record was inserted           |
| **modified\_timestamp**        | timestamp | Time when the record was last modified      |

## Table Sample

<TableSample />


# thorchain.core_transfers
Source: https://docs.dune.com/data-catalog/thorchain/core_transfers

THORChain token transfer records — RUNE and synth movements.

## Table Description

The `thorchain.core_transfers` table records all native asset transfers on THORChain. This table tracks RUNE and other asset transfers between addresses on the THORChain network. This table is partitioned by day.

## Column Descriptions

| **Column**                | **Type**      | **Description**                         |
| ------------------------- | ------------- | --------------------------------------- |
| **block\_id**             | bigint        | Identifier                              |
| **from\_address**         | varchar       | Source address                          |
| **to\_address**           | varchar       | Destination address                     |
| **asset**                 | varchar       | Asset identifier                        |
| **rune\_amount**          | decimal(38,0) | Amount in RUNE                          |
| **rune\_amount\_usd**     | decimal(20,6) | USD value of RUNE amount                |
| **\_unique\_key**         | varchar       | Unique Key                              |
| **\_INSERTED\_TIMESTAMP** | timestamp     | Timestamp of the record                 |
| **fact\_transfers\_id**   | bigint        | Surrogate key for the fact record       |
| **day**                   | timestamp     | Date of the record                      |
| **block\_timestamp**      | timestamp     | Timestamp of when the block was created |
| **dim\_block\_id**        | bigint        | Reference to the block dimension table  |
| **inserted\_timestamp**   | timestamp     | Time when the record was inserted       |
| **modified\_timestamp**   | timestamp     | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.core_tss_keygen_failure_events
Source: https://docs.dune.com/data-catalog/thorchain/core_tss_keygen_failure_events

THORChain TSS key generation failure events.

## Table Description

The `thorchain.core_tss_keygen_failure_events` table event data for tss keygen failure on THORChain. This table is partitioned by block\_month.

## Column Descriptions

| **Column**                                 | **Type**  | **Description**                         |
| ------------------------------------------ | --------- | --------------------------------------- |
| **fail\_reason**                           | varchar   | Fail Reason                             |
| **is\_unicast**                            | varchar   | Is Unicast                              |
| **blame\_nodes**                           | varchar   | Blame Nodes                             |
| **round**                                  | varchar   | Round                                   |
| **height**                                 | varchar   | Height                                  |
| **event\_id**                              | bigint    | Event identifier                        |
| **block\_timestamp**                       | timestamp | Timestamp of when the block was created |
| **block\_time**                            | timestamp | Timestamp of when the block was created |
| **block\_month**                           | timestamp | Block Month                             |
| **\_inserted\_timestamp**                  | timestamp | Timestamp of the record                 |
| **fact\_tss\_keygen\_failure\_events\_id** | bigint    | Surrogate key for the fact record       |
| **dim\_block\_id**                         | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**                    | timestamp | Time when the record was inserted       |
| **modified\_timestamp**                    | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.core_tss_keygen_success_events
Source: https://docs.dune.com/data-catalog/thorchain/core_tss_keygen_success_events

THORChain TSS key generation success events.

## Table Description

The `thorchain.core_tss_keygen_success_events` table event data for tss keygen success on THORChain. This table is partitioned by block\_month.

## Column Descriptions

| **Column**                                 | **Type**  | **Description**                         |
| ------------------------------------------ | --------- | --------------------------------------- |
| **pub\_key**                               | varchar   | Pub Key                                 |
| **members**                                | varchar   | Members                                 |
| **height**                                 | varchar   | Height                                  |
| **event\_id**                              | bigint    | Event identifier                        |
| **block\_timestamp**                       | timestamp | Timestamp of when the block was created |
| **block\_time**                            | timestamp | Timestamp of when the block was created |
| **block\_month**                           | timestamp | Block Month                             |
| **\_inserted\_timestamp**                  | timestamp | Timestamp of the record                 |
| **fact\_tss\_keygen\_success\_events\_id** | bigint    | Surrogate key for the fact record       |
| **dim\_block\_id**                         | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**                    | timestamp | Time when the record was inserted       |
| **modified\_timestamp**                    | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.core_wasm_contracts_events
Source: https://docs.dune.com/data-catalog/thorchain/core_wasm_contracts_events

THORChain CosmWasm contract execution events.

## Table Description

The `thorchain.core_wasm_contracts_events` table event data for wasm contracts on THORChain. This table is partitioned by block\_month.

## Column Descriptions

| **Column**                            | **Type**  | **Description**                         |
| ------------------------------------- | --------- | --------------------------------------- |
| **tx\_id**                            | bigint    | Transaction ID                          |
| **contract\_address**                 | varchar   | Address                                 |
| **contract\_type**                    | varchar   | Contract Type                           |
| **sender**                            | varchar   | Sender                                  |
| **attributes**                        | varchar   | Attributes                              |
| **event\_id**                         | bigint    | Event identifier                        |
| **block\_timestamp**                  | timestamp | Timestamp of when the block was created |
| **block\_time**                       | timestamp | Timestamp of when the block was created |
| **block\_month**                      | timestamp | Block Month                             |
| **\_inserted\_timestamp**             | timestamp | Timestamp of the record                 |
| **fact\_wasm\_contracts\_events\_id** | bigint    | Surrogate key for the fact record       |
| **dim\_block\_id**                    | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**               | timestamp | Time when the record was inserted       |
| **modified\_timestamp**               | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_active_vault_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_active_vault_events

THORChain active vault rotation events.

## Table Description

The `thorchain.defi_active_vault_events` table event data for active vault on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                          | **Type**  | **Description**                         |
| ----------------------------------- | --------- | --------------------------------------- |
| **add\_asgard\_addr**               | varchar   | Add Asgard Addr                         |
| **event\_id**                       | bigint    | Event identifier                        |
| **block\_timestamp**                | timestamp | Timestamp of when the block was created |
| **block\_time**                     | timestamp | Timestamp of when the block was created |
| **block\_month**                    | timestamp | Block Month                             |
| **\_inserted\_timestamp**           | timestamp | Timestamp of the record                 |
| **fact\_active\_vault\_events\_id** | bigint    | Surrogate key for the fact record       |
| **dim\_block\_id**                  | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**             | timestamp | Time when the record was inserted       |
| **modified\_timestamp**             | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_add_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_add_events

THORChain liquidity add events — assets deposited to pools.

## Table Description

The `thorchain.defi_add_events` table event data for liquidity addition actions on THORChain. This table captures events when users add liquidity to pools. This table is partitioned by day.

## Column Descriptions

| **Column**                | **Type**  | **Description**                                  |
| ------------------------- | --------- | ------------------------------------------------ |
| **fact\_add\_events\_id** | bigint    | Surrogate key for the add liquidity event record |
| **day**                   | timestamp | Date of the record                               |
| **block\_timestamp**      | timestamp | Timestamp of when the block was created          |
| **dim\_block\_id**        | bigint    | Reference to the block dimension table           |
| **tx\_id**                | bigint    | Transaction ID                                   |
| **rune\_e8**              | bigint    | RUNE amount in e8 units                          |
| **blockchain**            | varchar   | Source blockchain identifier                     |
| **asset\_e8**             | bigint    | Asset amount in e8 units                         |
| **pool\_name**            | varchar   | Name of the liquidity pool                       |
| **memo**                  | varchar   | Transaction memo                                 |
| **to\_address**           | varchar   | Destination address                              |
| **from\_address**         | varchar   | Source address                                   |
| **asset**                 | varchar   | Asset identifier                                 |
| **\_TX\_TYPE**            | varchar   | Tx Type                                          |
| **inserted\_timestamp**   | timestamp | Time when the record was inserted                |
| **modified\_timestamp**   | timestamp | Time when the record was last modified           |

## Table Sample

<TableSample />


# thorchain.defi_affiliate_fee_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_affiliate_fee_events

THORChain affiliate fee collection events.

## Table Description

The `thorchain.defi_affiliate_fee_events` table event data for affiliate fee on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                           | **Type**  | **Description**                         |
| ------------------------------------ | --------- | --------------------------------------- |
| **tx\_id**                           | bigint    | Transaction ID                          |
| **fee\_amt**                         | varchar   | Fee Amt                                 |
| **gross\_amt**                       | varchar   | Gross Amt                               |
| **fee\_bps**                         | varchar   | Fee Bps                                 |
| **memo**                             | varchar   | Transaction memo                        |
| **asset**                            | varchar   | Asset identifier                        |
| **rune\_address**                    | varchar   | Address                                 |
| **thorname**                         | varchar   | Thorname                                |
| **event\_id**                        | bigint    | Event identifier                        |
| **block\_timestamp**                 | timestamp | Timestamp of when the block was created |
| **block\_time**                      | timestamp | Timestamp of when the block was created |
| **block\_month**                     | timestamp | Block Month                             |
| **\_inserted\_timestamp**            | timestamp | Timestamp of the record                 |
| **fact\_affiliate\_fee\_events\_id** | bigint    | Surrogate key for the fact record       |
| **dim\_block\_id**                   | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**              | timestamp | Time when the record was inserted       |
| **modified\_timestamp**              | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_asgard_fund_yggdrasil_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_asgard_fund_yggdrasil_events

THORChain vault funding events — Asgard to Yggdrasil transfers.

## Table Description

The `thorchain.defi_asgard_fund_yggdrasil_events` table event data for asgard fund yggdrasil on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                                    | **Type**  | **Description**                         |
| --------------------------------------------- | --------- | --------------------------------------- |
| **tx**                                        | varchar   | Tx                                      |
| **asset**                                     | varchar   | Asset identifier                        |
| **asset\_e8**                                 | bigint    | Asset amount in e8 units                |
| **vault\_key**                                | varchar   | Vault Key                               |
| **event\_id**                                 | bigint    | Event identifier                        |
| **block\_timestamp**                          | timestamp | Timestamp of when the block was created |
| **tx\_id**                                    | bigint    | Transaction ID                          |
| **block\_time**                               | timestamp | Timestamp of when the block was created |
| **block\_month**                              | timestamp | Block Month                             |
| **\_inserted\_timestamp**                     | timestamp | Timestamp of the record                 |
| **fact\_asgard\_fund\_yggdrasil\_events\_id** | bigint    | Surrogate key for the fact record       |
| **dim\_block\_id**                            | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**                       | timestamp | Time when the record was inserted       |
| **modified\_timestamp**                       | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_block_pool_depths
Source: https://docs.dune.com/data-catalog/thorchain/defi_block_pool_depths

THORChain pool depth snapshots per block — asset and RUNE balances.

## Table Description

The `thorchain.defi_block_pool_depths` table block-level data for block pool depths on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                | **Type**  | **Description**                         |
| ------------------------- | --------- | --------------------------------------- |
| **pool\_name**            | varchar   | Name of the liquidity pool              |
| **asset\_e8**             | bigint    | Asset amount in e8 units                |
| **rune\_e8**              | bigint    | RUNE amount in e8 units                 |
| **synth\_e8**             | bigint    | Synth E8                                |
| **block\_timestamp**      | timestamp | Timestamp of when the block was created |
| **\_inserted\_timestamp** | timestamp | Timestamp of the record                 |
| **dim\_block\_id**        | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**   | timestamp | Time when the record was inserted       |
| **modified\_timestamp**   | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_block_rewards
Source: https://docs.dune.com/data-catalog/thorchain/defi_block_rewards

THORChain block reward distributions — emissions to pools and node operators.

## Table Description

The `thorchain.defi_block_rewards` table block-level data for block rewards on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                | **Type**  | **Description**                        |
| ------------------------- | --------- | -------------------------------------- |
| **day**                   | date      | Date of the record                     |
| **liquidity\_fee**        | varchar   | Identifier                             |
| **block\_rewards**        | varchar   | Block Rewards                          |
| **earnings**              | varchar   | Earnings                               |
| **bonding\_earnings**     | varchar   | Bonding Earnings                       |
| **liquidity\_earnings**   | varchar   | Identifier                             |
| **avg\_node\_count**      | varchar   | Avg Node Count                         |
| **\_inserted\_timestamp** | timestamp | Timestamp of the record                |
| **inserted\_timestamp**   | timestamp | Time when the record was inserted      |
| **modified\_timestamp**   | timestamp | Time when the record was last modified |

## Table Sample

<TableSample />


# thorchain.defi_bond_actions
Source: https://docs.dune.com/data-catalog/thorchain/defi_bond_actions

THORChain node bond actions — bond and unbond operations.

## Table Description

The `thorchain.defi_bond_actions` table records of bond actions on THORChain. This table tracks bonding and unbonding actions for validators and includes asset amounts and USD values.

## Column Descriptions

| **Column**                  | **Type**      | **Description**                          |
| --------------------------- | ------------- | ---------------------------------------- |
| **fact\_bond\_actions\_id** | varchar       | Surrogate key for the bond action record |
| **block\_timestamp**        | timestamp     | Timestamp of when the block was created  |
| **dim\_block\_id**          | varchar       | Reference to the block dimension table   |
| **tx\_id**                  | varchar       | Transaction ID                           |
| **from\_address**           | varchar       | Source address                           |
| **to\_address**             | varchar       | Destination address                      |
| **asset**                   | varchar       | Asset identifier                         |
| **blockchain**              | varchar       | Source blockchain identifier             |
| **bond\_type**              | varchar       | Type of bond action                      |
| **asset\_amount**           | decimal(38,0) | Amount of asset                          |
| **asset\_usd**              | decimal(20,6) | USD value of asset amount                |
| **memo**                    | varchar       | Transaction memo                         |
| **\_TX\_TYPE**              | varchar       | Transaction type                         |
| **inserted\_timestamp**     | timestamp     | Time when the record was inserted        |
| **modified\_timestamp**     | timestamp     | Time when the record was last modified   |

## Table Sample

<TableSample />


# thorchain.defi_bond_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_bond_events

THORChain bond lifecycle events — deposits, withdrawals, and slashes.

## Table Description

The `thorchain.defi_bond_events` table event data for bond actions on THORChain. This table tracks bonding and unbonding events for validators.

## Column Descriptions

| **Column**                 | **Type**  | **Description**                         |
| -------------------------- | --------- | --------------------------------------- |
| **tx\_id**                 | bigint    | Transaction ID                          |
| **blockchain**             | varchar   | Source blockchain identifier            |
| **from\_address**          | varchar   | Source address                          |
| **to\_address**            | varchar   | Destination address                     |
| **asset**                  | varchar   | Asset identifier                        |
| **asset\_e8**              | bigint    | Asset amount in e8 units                |
| **memo**                   | varchar   | Transaction memo                        |
| **bond\_type**             | varchar   | Bond Type                               |
| **e8**                     | varchar   | E8                                      |
| **block\_timestamp**       | timestamp | Timestamp of when the block was created |
| **\_tx\_type**             | varchar   | Tx Type                                 |
| **\_inserted\_timestamp**  | timestamp | Timestamp of the record                 |
| **fact\_bond\_events\_id** | bigint    | Surrogate key for the bond event record |
| **dim\_block\_id**         | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**    | timestamp | Time when the record was inserted       |
| **modified\_timestamp**    | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_daily_earnings
Source: https://docs.dune.com/data-catalog/thorchain/defi_daily_earnings

THORChain daily protocol earnings — fees, rewards, and revenue breakdown.

## Table Description

The `thorchain.defi_daily_earnings` table daily earnings statistics for THORChain. This table tracks liquidity fees, block rewards, and total earnings distributed to nodes and pools. This table is partitioned by day.

## Column Descriptions

| **Column**                    | **Type**      | **Description**                        |
| ----------------------------- | ------------- | -------------------------------------- |
| **day**                       | date          | Date of the record                     |
| **liquidity\_fees**           | varchar       | Identifier                             |
| **liquidity\_fees\_usd**      | decimal(20,6) | Identifier                             |
| **block\_rewards**            | varchar       | Block Rewards                          |
| **block\_rewards\_usd**       | decimal(20,6) | Block Rewards Usd                      |
| **total\_earnings**           | varchar       | Total Earnings                         |
| **total\_earnings\_usd**      | decimal(20,6) | Total Earnings Usd                     |
| **earnings\_to\_nodes**       | varchar       | Earnings To Nodes                      |
| **earnings\_to\_nodes\_usd**  | decimal(20,6) | Earnings To Nodes Usd                  |
| **earnings\_to\_pools**       | varchar       | Earnings To Pools                      |
| **earnings\_to\_pools\_usd**  | decimal(20,6) | Earnings To Pools Usd                  |
| **avg\_node\_count**          | varchar       | Avg Node Count                         |
| **\_inserted\_timestamp**     | timestamp     | Timestamp of the record                |
| **fact\_daily\_earnings\_id** | bigint        | Surrogate key for the fact record      |
| **inserted\_timestamp**       | timestamp     | Time when the record was inserted      |
| **modified\_timestamp**       | timestamp     | Time when the record was last modified |

## Table Sample

<TableSample />


# thorchain.defi_daily_pool_stats
Source: https://docs.dune.com/data-catalog/thorchain/defi_daily_pool_stats

THORChain daily pool statistics — volume, fees, APY, and depth by pool.

## Table Description

The `thorchain.defi_daily_pool_stats` table daily statistics for Continuous Liquidity Pools (CLPs) on THORChain. CLPs are THORChain's advanced AMM mechanism that allows for native asset swaps without wrapped tokens. This table tracks daily pool statistics including liquidity, swaps, fees, and rewards. This table is partitioned by day.

## Column Descriptions

| **Column**                          | **Type**      | **Description**                               |
| ----------------------------------- | ------------- | --------------------------------------------- |
| **DAY**                             | date          | Date of the record                            |
| **pool\_name**                      | varchar       | Name of the liquidity pool                    |
| **system\_rewards**                 | varchar       | System Rewards                                |
| **system\_rewards\_usd**            | decimal(20,6) | System Rewards Usd                            |
| **asset\_liquidity**                | varchar       | Identifier                                    |
| **asset\_price**                    | varchar       | Asset Price                                   |
| **asset\_price\_usd**               | decimal(20,6) | Asset Price Usd                               |
| **rune\_liquidity**                 | varchar       | Identifier                                    |
| **rune\_price**                     | varchar       | Rune Price                                    |
| **rune\_price\_usd**                | decimal(20,6) | Rune Price Usd                                |
| **add\_liquidity\_count**           | varchar       | Identifier                                    |
| **add\_asset\_liquidity**           | varchar       | Identifier                                    |
| **add\_asset\_liquidity\_usd**      | decimal(20,6) | Identifier                                    |
| **add\_rune\_liquidity**            | varchar       | Identifier                                    |
| **add\_rune\_liquidity\_usd**       | decimal(20,6) | Identifier                                    |
| **withdraw\_count**                 | varchar       | Withdraw Count                                |
| **withdraw\_asset\_liquidity**      | varchar       | Identifier                                    |
| **withdraw\_asset\_liquidity\_usd** | decimal(20,6) | Identifier                                    |
| **withdraw\_rune\_liquidity**       | varchar       | Identifier                                    |
| **withdraw\_rune\_liquidity\_usd**  | decimal(20,6) | Identifier                                    |
| **il\_protection\_paid**            | varchar       | Identifier                                    |
| **il\_protection\_paid\_usd**       | decimal(20,6) | Identifier                                    |
| **average\_slip**                   | varchar       | Average Slip                                  |
| **to\_asset\_average\_slip**        | varchar       | To Asset Average Slip                         |
| **to\_rune\_average\_slip**         | varchar       | To Rune Average Slip                          |
| **swap\_count**                     | varchar       | Swap Count                                    |
| **to\_asset\_swap\_count**          | varchar       | To Asset Swap Count                           |
| **to\_rune\_swap\_count**           | varchar       | To Rune Swap Count                            |
| **swap\_volume\_rune**              | varchar       | Swap Volume Rune                              |
| **swap\_volume\_rune\_usd**         | decimal(20,6) | Swap Volume Rune Usd                          |
| **to\_asset\_swap\_volume**         | varchar       | To Asset Swap Volume                          |
| **to\_rune\_swap\_volume**          | varchar       | To Rune Swap Volume                           |
| **total\_swap\_fees\_rune**         | varchar       | Total Swap Fees Rune                          |
| **total\_swap\_fees\_usd**          | decimal(20,6) | Total Swap Fees Usd                           |
| **total\_asset\_swap\_fees**        | varchar       | Total Asset Swap Fees                         |
| **total\_asset\_rune\_fees**        | varchar       | Total Asset Rune Fees                         |
| **unique\_member\_count**           | varchar       | Unique Member Count                           |
| **unique\_swapper\_count**          | varchar       | Unique Swapper Count                          |
| **liquidity\_units**                | varchar       | Identifier                                    |
| **\_unique\_key**                   | varchar       | Unique Key                                    |
| **fact\_daily\_pool\_stats\_id**    | bigint        | Surrogate key for the daily pool stats record |
| **inserted\_timestamp**             | timestamp     | Time when the record was inserted             |
| **modified\_timestamp**             | timestamp     | Time when the record was last modified        |

## Table Sample

<TableSample />


# thorchain.defi_daily_tvl
Source: https://docs.dune.com/data-catalog/thorchain/defi_daily_tvl

THORChain daily total value locked — aggregate TVL across all pools.

## Table Description

The `thorchain.defi_daily_tvl` table daily total value locked (TVL) statistics for THORChain. This table tracks the total value locked across all pools on a daily basis. This table is partitioned by day.

## Column Descriptions

| **Column**                    | **Type**      | **Description**                        |
| ----------------------------- | ------------- | -------------------------------------- |
| **day**                       | date          | Date of the record                     |
| **total\_value\_pooled**      | varchar       | Total Value Pooled                     |
| **total\_value\_pooled\_usd** | decimal(20,6) | Total Value Pooled Usd                 |
| **total\_value\_bonded**      | varchar       | Total Value Bonded                     |
| **total\_value\_bonded\_usd** | decimal(20,6) | Total Value Bonded Usd                 |
| **total\_value\_locked**      | varchar       | Total Value Locked                     |
| **total\_value\_locked\_usd** | decimal(20,6) | Total Value Locked Usd                 |
| **fact\_daily\_tvl\_id**      | bigint        | Surrogate key for the fact record      |
| **inserted\_timestamp**       | timestamp     | Time when the record was inserted      |
| **modified\_timestamp**       | timestamp     | Time when the record was last modified |

## Table Sample

<TableSample />


# thorchain.defi_errata_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_errata_events

THORChain errata correction events — manual adjustments to chain state.

## Table Description

The `thorchain.defi_errata_events` table event data for errata on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                   | **Type**  | **Description**                         |
| ---------------------------- | --------- | --------------------------------------- |
| **in\_tx**                   | varchar   | In Tx                                   |
| **asset**                    | varchar   | Asset identifier                        |
| **asset\_e8**                | bigint    | Asset amount in e8 units                |
| **rune\_e8**                 | bigint    | RUNE amount in e8 units                 |
| **event\_id**                | bigint    | Event identifier                        |
| **block\_timestamp**         | timestamp | Timestamp of when the block was created |
| **block\_time**              | timestamp | Timestamp of when the block was created |
| **block\_month**             | timestamp | Block Month                             |
| **\_inserted\_timestamp**    | timestamp | Timestamp of the record                 |
| **fact\_errata\_events\_id** | bigint    | Surrogate key for the fact record       |
| **dim\_block\_id**           | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**      | timestamp | Time when the record was inserted       |
| **modified\_timestamp**      | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_failed_deposit_messages
Source: https://docs.dune.com/data-catalog/thorchain/defi_failed_deposit_messages

THORChain failed deposit attempts — rejected inbound transactions.

## Table Description

The `thorchain.defi_failed_deposit_messages` table contains data for failed deposit messages on THORChain.

## Column Descriptions

| **Column**                              | **Type**  | **Description**                         |
| --------------------------------------- | --------- | --------------------------------------- |
| **amount\_e8**                          | bigint    | Amount in e8 units (1e8 = 1 unit)       |
| **asset**                               | varchar   | Asset identifier                        |
| **from\_addr**                          | varchar   | From Addr                               |
| **memo**                                | varchar   | Transaction memo                        |
| **code**                                | varchar   | Code                                    |
| **reason**                              | varchar   | Reason                                  |
| **tx\_id**                              | bigint    | Transaction ID                          |
| **event\_id**                           | bigint    | Event identifier                        |
| **block\_timestamp**                    | timestamp | Timestamp of when the block was created |
| **from\_address**                       | varchar   | Source address                          |
| **block\_time**                         | timestamp | Timestamp of when the block was created |
| **block\_month**                        | timestamp | Block Month                             |
| **\_inserted\_timestamp**               | timestamp | Timestamp of the record                 |
| **fact\_failed\_deposit\_messages\_id** | bigint    | Surrogate key for the fact record       |
| **dim\_block\_id**                      | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**                 | timestamp | Time when the record was inserted       |
| **modified\_timestamp**                 | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_fee_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_fee_events

THORChain fee collection events — swap fees, network fees, and outbound fees.

## Table Description

The `thorchain.defi_fee_events` table event data for fee events on THORChain. This table captures fee-related events including pool deductions and asset fees.

## Column Descriptions

| **Column**              | **Type**  | **Description**                         |
| ----------------------- | --------- | --------------------------------------- |
| **block\_time**         | timestamp | Timestamp of when the block was created |
| **block\_date**         | date      | Date of when the block was created      |
| **block\_month**        | timestamp | Month of when the block was created     |
| **block\_height**       | bigint    | Block height                            |
| **tx\_id**              | varchar   | Transaction ID                          |
| **event\_id**           | varchar   | Event identifier                        |
| **asset**               | varchar   | Asset identifier                        |
| **pool\_deduct**        | varchar   | Pool deduction information              |
| **asset\_e8**           | bigint    | Asset amount in e8 units                |
| **inserted\_timestamp** | timestamp | Time when the record was inserted       |
| **modified\_timestamp** | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_gas_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_gas_events

THORChain gas reimbursement events — gas costs for outbound transactions.

## Table Description

The `thorchain.defi_gas_events` table event data for gas on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                | **Type**  | **Description**                         |
| ------------------------- | --------- | --------------------------------------- |
| **asset**                 | varchar   | Asset identifier                        |
| **asset\_e8**             | bigint    | Asset amount in e8 units                |
| **rune\_e8**              | bigint    | RUNE amount in e8 units                 |
| **tx\_count**             | varchar   | Tx Count                                |
| **event\_id**             | bigint    | Event identifier                        |
| **block\_timestamp**      | timestamp | Timestamp of when the block was created |
| **block\_time**           | timestamp | Timestamp of when the block was created |
| **block\_month**          | varchar   | Block Month                             |
| **\_inserted\_timestamp** | timestamp | Timestamp of the record                 |
| **fact\_gas\_events\_id** | bigint    | Surrogate key for the fact record       |
| **dim\_block\_id**        | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**   | timestamp | Time when the record was inserted       |
| **modified\_timestamp**   | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_inactive_vault_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_inactive_vault_events

THORChain vault deactivation events.

## Table Description

The `thorchain.defi_inactive_vault_events` table event data for inactive vault on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                            | **Type**  | **Description**                         |
| ------------------------------------- | --------- | --------------------------------------- |
| **add\_asgard\_addr**                 | varchar   | Add Asgard Addr                         |
| **event\_id**                         | bigint    | Event identifier                        |
| **block\_timestamp**                  | timestamp | Timestamp of when the block was created |
| **add\_asgard\_address**              | varchar   | Address                                 |
| **block\_time**                       | timestamp | Timestamp of when the block was created |
| **block\_month**                      | timestamp | Block Month                             |
| **\_inserted\_timestamp**             | timestamp | Timestamp of the record                 |
| **fact\_inactive\_vault\_events\_id** | bigint    | Surrogate key for the fact record       |
| **dim\_block\_id**                    | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**               | timestamp | Time when the record was inserted       |
| **modified\_timestamp**               | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_liquidity_actions
Source: https://docs.dune.com/data-catalog/thorchain/defi_liquidity_actions

THORChain liquidity actions — adds, withdrawals, and position changes.

## Table Description

The `thorchain.defi_liquidity_actions` table records of liquidity provision and withdrawal actions on THORChain. This table tracks when users add or remove liquidity from Continuous Liquidity Pools (CLPs). This table is partitioned by day.

## Column Descriptions

| **Column**                       | **Type**      | **Description**                               |
| -------------------------------- | ------------- | --------------------------------------------- |
| **block\_id**                    | bigint        | Identifier                                    |
| **tx\_id**                       | bigint        | Transaction ID                                |
| **lp\_action**                   | varchar       | Type of liquidity action (add or withdraw)    |
| **pool\_name**                   | varchar       | Name of the liquidity pool                    |
| **from\_address**                | varchar       | Source address                                |
| **to\_address**                  | varchar       | Destination address                           |
| **rune\_amount**                 | decimal(38,0) | Amount in RUNE                                |
| **rune\_amount\_usd**            | decimal(20,6) | USD value of RUNE amount                      |
| **asset\_amount**                | decimal(38,0) | Amount of asset                               |
| **asset\_amount\_usd**           | decimal(20,6) | USD value of asset amount                     |
| **stake\_units**                 | varchar       | Pool units (LP tokens) received or burned     |
| **asset\_tx\_id**                | bigint        | Identifier                                    |
| **asset\_address**               | varchar       | Address                                       |
| **asset\_blockchain**            | varchar       | Asset Blockchain                              |
| **il\_protection**               | varchar       | Il Protection                                 |
| **il\_protection\_usd**          | decimal(20,6) | Il Protection Usd                             |
| **unstake\_asymmetry**           | varchar       | Unstake Asymmetry                             |
| **unstake\_basis\_points**       | int           | Unstake Basis Points                          |
| **\_unique\_key**                | varchar       | Unique Key                                    |
| **\_inserted\_timestamp**        | timestamp     | Timestamp of the record                       |
| **fact\_liquidity\_actions\_id** | bigint        | Surrogate key for the liquidity action record |
| **day**                          | timestamp     | Date of the record                            |
| **block\_timestamp**             | timestamp     | Timestamp of when the block was created       |
| **dim\_block\_id**               | bigint        | Reference to the block dimension table        |
| **inserted\_timestamp**          | timestamp     | Time when the record was inserted             |
| **modified\_timestamp**          | timestamp     | Time when the record was last modified        |

## Table Sample

<TableSample />


# thorchain.defi_loan_open_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_loan_open_events

THORChain lending — loan origination events with collateral and debt details.

## Table Description

The `thorchain.defi_loan_open_events` table event data for loan open on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                   | **Type**  | **Description**                         |
| ---------------------------- | --------- | --------------------------------------- |
| **owner**                    | varchar   | Owner                                   |
| **collateralization\_ratio** | varchar   | Collateralization Ratio                 |
| **collateral\_asset**        | varchar   | Collateral Asset                        |
| **target\_asset**            | varchar   | Target Asset                            |
| **event\_id**                | bigint    | Event identifier                        |
| **block\_timestamp**         | timestamp | Timestamp of when the block was created |
| **collateral\_deposited**    | varchar   | Collateral Deposited                    |
| **debt\_issued**             | varchar   | Debt Issued                             |
| **tx\_id**                   | bigint    | Transaction ID                          |
| **block\_time**              | timestamp | Timestamp of when the block was created |
| **block\_month**             | varchar   | Block Month                             |
| **\_inserted\_timestamp**    | timestamp | Timestamp of the record                 |
| **dim\_block\_id**           | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**      | timestamp | Time when the record was inserted       |
| **modified\_timestamp**      | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_loan_repayment_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_loan_repayment_events

THORChain lending — loan repayment events.

## Table Description

The `thorchain.defi_loan_repayment_events` table event data for loan repayment on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                | **Type**  | **Description**                         |
| ------------------------- | --------- | --------------------------------------- |
| **owner**                 | varchar   | Owner                                   |
| **collateral\_asset**     | varchar   | Collateral Asset                        |
| **event\_id**             | bigint    | Event identifier                        |
| **block\_timestamp**      | timestamp | Timestamp of when the block was created |
| **collateral\_withdrawn** | varchar   | Collateral Withdrawn                    |
| **debt\_repaid**          | varchar   | Identifier                              |
| **tx\_id**                | bigint    | Transaction ID                          |
| **block\_time**           | timestamp | Timestamp of when the block was created |
| **block\_month**          | varchar   | Block Month                             |
| **\_inserted\_timestamp** | timestamp | Timestamp of the record                 |
| **dim\_block\_id**        | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**   | timestamp | Time when the record was inserted       |
| **modified\_timestamp**   | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_mint_burn_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_mint_burn_events

THORChain synthetic asset mint and burn events.

## Table Description

The `thorchain.defi_mint_burn_events` table event data for mint burn on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                | **Type**  | **Description**                         |
| ------------------------- | --------- | --------------------------------------- |
| **asset**                 | varchar   | Asset identifier                        |
| **asset\_e8**             | bigint    | Asset amount in e8 units                |
| **supply**                | varchar   | Supply                                  |
| **reason**                | varchar   | Reason                                  |
| **event\_id**             | bigint    | Event identifier                        |
| **block\_timestamp**      | timestamp | Timestamp of when the block was created |
| **block\_time**           | timestamp | Timestamp of when the block was created |
| **block\_month**          | timestamp | Block Month                             |
| **\_inserted\_timestamp** | timestamp | Timestamp of the record                 |
| **dim\_block\_id**        | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**   | timestamp | Time when the record was inserted       |
| **modified\_timestamp**   | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_outbound_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_outbound_events

THORChain outbound transaction events — assets sent to external chains.

## Table Description

The `thorchain.defi_outbound_events` table event data for outbound on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                     | **Type**      | **Description**                         |
| ------------------------------ | ------------- | --------------------------------------- |
| **tx\_id**                     | bigint        | Transaction ID                          |
| **blockchain**                 | varchar       | Source blockchain identifier            |
| **from\_address**              | varchar       | Source address                          |
| **to\_address**                | varchar       | Destination address                     |
| **asset**                      | varchar       | Asset identifier                        |
| **asset\_e8**                  | bigint        | Asset amount in e8 units                |
| **asset\_amount**              | decimal(38,0) | Amount of asset                         |
| **memo**                       | varchar       | Transaction memo                        |
| **in\_tx**                     | varchar       | In Tx                                   |
| **event\_id**                  | bigint        | Event identifier                        |
| **block\_timestamp**           | timestamp     | Timestamp of when the block was created |
| **block\_time**                | timestamp     | Timestamp of when the block was created |
| **block\_month**               | varchar       | Block Month                             |
| **\_tx\_type**                 | varchar       | Tx Type                                 |
| **\_inserted\_timestamp**      | timestamp     | Timestamp of the record                 |
| **fact\_outbound\_events\_id** | bigint        | Surrogate key for the fact record       |
| **dim\_block\_id**             | bigint        | Reference to the block dimension table  |
| **inserted\_timestamp**        | timestamp     | Time when the record was inserted       |
| **modified\_timestamp**        | timestamp     | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_pending_liquidity_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_pending_liquidity_events

THORChain pending liquidity events — asymmetric deposits awaiting pairing.

## Table Description

The `thorchain.defi_pending_liquidity_events` table event data for pending liquidity on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                               | **Type**      | **Description**                         |
| ---------------------------------------- | ------------- | --------------------------------------- |
| **pool\_name**                           | varchar       | Name of the liquidity pool              |
| **asset\_tx\_id**                        | bigint        | Identifier                              |
| **asset\_blockchain**                    | varchar       | Asset Blockchain                        |
| **asset\_address**                       | varchar       | Address                                 |
| **asset\_e8**                            | bigint        | Asset amount in e8 units                |
| **asset\_amount**                        | decimal(38,0) | Amount of asset                         |
| **rune\_tx\_id**                         | bigint        | Identifier                              |
| **rune\_address**                        | varchar       | Address                                 |
| **rune\_e8**                             | bigint        | RUNE amount in e8 units                 |
| **rune\_amount**                         | decimal(38,0) | Amount in RUNE                          |
| **pending\_type**                        | varchar       | Pending Type                            |
| **event\_id**                            | bigint        | Event identifier                        |
| **block\_timestamp**                     | timestamp     | Timestamp of when the block was created |
| **block\_time**                          | timestamp     | Timestamp of when the block was created |
| **block\_month**                         | varchar       | Block Month                             |
| **pool\_chain**                          | varchar       | Pool Chain                              |
| **pool\_asset**                          | varchar       | Pool Asset                              |
| **fact\_pending\_liquidity\_events\_id** | bigint        | Surrogate key for the fact record       |
| **dim\_block\_id**                       | bigint        | Reference to the block dimension table  |
| **\_inserted\_timestamp**                | timestamp     | Timestamp of the record                 |
| **inserted\_timestamp**                  | timestamp     | Time when the record was inserted       |
| **modified\_timestamp**                  | timestamp     | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_pool_balance_change_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_pool_balance_change_events

THORChain pool balance change events — triggered by swaps, adds, and withdrawals.

## Table Description

The `thorchain.defi_pool_balance_change_events` table event data for pool balance change on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                                  | **Type**      | **Description**                         |
| ------------------------------------------- | ------------- | --------------------------------------- |
| **asset**                                   | varchar       | Asset identifier                        |
| **rune\_amt**                               | varchar       | Rune Amt                                |
| **rune\_add**                               | varchar       | Rune Add                                |
| **asset\_amt**                              | varchar       | Asset Amt                               |
| **asset\_add**                              | varchar       | Asset Add                               |
| **reason**                                  | varchar       | Reason                                  |
| **event\_id**                               | bigint        | Event identifier                        |
| **block\_timestamp**                        | timestamp     | Timestamp of when the block was created |
| **rune\_amount**                            | decimal(38,0) | Amount in RUNE                          |
| **asset\_amount**                           | decimal(38,0) | Amount of asset                         |
| **block\_time**                             | timestamp     | Timestamp of when the block was created |
| **block\_month**                            | timestamp     | Block Month                             |
| **\_inserted\_timestamp**                   | timestamp     | Timestamp of the record                 |
| **fact\_pool\_balance\_change\_events\_id** | bigint        | Surrogate key for the fact record       |
| **dim\_block\_id**                          | bigint        | Reference to the block dimension table  |
| **inserted\_timestamp**                     | timestamp     | Time when the record was inserted       |
| **modified\_timestamp**                     | timestamp     | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_pool_block_balances
Source: https://docs.dune.com/data-catalog/thorchain/defi_pool_block_balances

THORChain pool balances per block — RUNE and asset depths.

## Table Description

The `thorchain.defi_pool_block_balances` table block-level balances for Continuous Liquidity Pools (CLPs) on THORChain. This table tracks RUNE, asset, and synthetic asset balances in pools at each block. This table is partitioned by day.

## Column Descriptions

| **Column**                          | **Type**      | **Description**                                 |
| ----------------------------------- | ------------- | ----------------------------------------------- |
| **fact\_pool\_block\_balances\_id** | varchar       | Surrogate key for the pool block balance record |
| **day**                             | date          | Date of the record                              |
| **block\_timestamp**                | timestamp     | Timestamp of when the block was created         |
| **dim\_block\_id**                  | varchar       | Reference to the block dimension table          |
| **pool\_name**                      | varchar       | Name of the liquidity pool                      |
| **rune\_amount**                    | decimal(38,0) | RUNE balance in the pool                        |
| **rune\_amount\_usd**               | decimal(20,6) | USD value of RUNE balance                       |
| **asset\_amount**                   | decimal(38,0) | Asset balance in the pool                       |
| **asset\_amount\_usd**              | decimal(20,6) | USD value of asset balance                      |
| **synth\_amount**                   | decimal(38,0) | Synthetic asset amount in the pool              |
| **synth\_amount\_usd**              | decimal(20,6) | USD value of synthetic asset amount             |
| **inserted\_timestamp**             | timestamp     | Time when the record was inserted               |
| **modified\_timestamp**             | timestamp     | Time when the record was last modified          |

## Table Sample

<TableSample />


# thorchain.defi_pool_block_fees
Source: https://docs.dune.com/data-catalog/thorchain/defi_pool_block_fees

THORChain pool fees per block — swap and liquidity fees collected.

## Table Description

The `thorchain.defi_pool_block_fees` table block-level data for pool fees on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                       | **Type**  | **Description**                        |
| -------------------------------- | --------- | -------------------------------------- |
| **DAY**                          | date      | Date of the record                     |
| **pool\_name**                   | varchar   | Name of the liquidity pool             |
| **rewards**                      | varchar   | Rewards                                |
| **total\_liquidity\_fees\_rune** | varchar   | Identifier                             |
| **asset\_liquidity\_fees**       | varchar   | Identifier                             |
| **rune\_liquidity\_fees**        | varchar   | Identifier                             |
| **earnings**                     | varchar   | Earnings                               |
| **\_unique\_key**                | varchar   | Unique Key                             |
| **\_INSERTED\_TIMESTAMP**        | timestamp | Timestamp of the record                |
| **fact\_pool\_block\_fees\_id**  | bigint    | Surrogate key for the fact record      |
| **inserted\_timestamp**          | timestamp | Time when the record was inserted      |
| **modified\_timestamp**          | timestamp | Time when the record was last modified |

## Table Sample

<TableSample />


# thorchain.defi_pool_block_statistics
Source: https://docs.dune.com/data-catalog/thorchain/defi_pool_block_statistics

THORChain pool statistics per block — volume, swap count, and slip.

## Table Description

The `thorchain.defi_pool_block_statistics` table block-level data for pool statistics on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                              | **Type**      | **Description**                        |
| --------------------------------------- | ------------- | -------------------------------------- |
| **day**                                 | date          | Date of the record                     |
| **add\_asset\_liquidity\_volume**       | varchar       | Identifier                             |
| **add\_liquidity\_count**               | varchar       | Identifier                             |
| **add\_liquidity\_volume**              | varchar       | Identifier                             |
| **add\_rune\_liquidity\_volume**        | varchar       | Identifier                             |
| **asset**                               | varchar       | Asset identifier                       |
| **asset\_depth**                        | varchar       | Asset Depth                            |
| **asset\_price**                        | varchar       | Asset Price                            |
| **asset\_price\_usd**                   | decimal(20,6) | Asset Price Usd                        |
| **average\_slip**                       | varchar       | Average Slip                           |
| **impermanent\_loss\_protection\_paid** | varchar       | Identifier                             |
| **rune\_depth**                         | varchar       | Rune Depth                             |
| **status**                              | varchar       | Status                                 |
| **swap\_count**                         | varchar       | Swap Count                             |
| **swap\_volume**                        | varchar       | Swap Volume                            |
| **to\_asset\_average\_slip**            | varchar       | To Asset Average Slip                  |
| **to\_asset\_count**                    | varchar       | To Asset Count                         |
| **to\_asset\_fees**                     | varchar       | To Asset Fees                          |
| **to\_asset\_volume**                   | varchar       | To Asset Volume                        |
| **to\_rune\_average\_slip**             | varchar       | To Rune Average Slip                   |
| **to\_rune\_count**                     | varchar       | To Rune Count                          |
| **to\_rune\_fees**                      | varchar       | To Rune Fees                           |
| **to\_rune\_volume**                    | varchar       | To Rune Volume                         |
| **totalfees**                           | varchar       | Totalfees                              |
| **unique\_member\_count**               | varchar       | Unique Member Count                    |
| **unique\_swapper\_count**              | varchar       | Unique Swapper Count                   |
| **units**                               | varchar       | Units                                  |
| **withdraw\_asset\_volume**             | varchar       | Withdraw Asset Volume                  |
| **withdraw\_count**                     | varchar       | Withdraw Count                         |
| **withdraw\_rune\_volume**              | varchar       | Withdraw Rune Volume                   |
| **withdraw\_volume**                    | varchar       | Withdraw Volume                        |
| **total\_stake**                        | varchar       | Total Stake                            |
| **depth\_product**                      | varchar       | Depth Product                          |
| **synth\_units**                        | varchar       | Synth Units                            |
| **pool\_units**                         | varchar       | Pool Units                             |
| **liquidity\_unit\_value\_index**       | varchar       | Identifier                             |
| **prev\_liquidity\_unit\_value\_index** | varchar       | Identifier                             |
| **\_unique\_key**                       | varchar       | Unique Key                             |
| **fact\_pool\_block\_statistics\_id**   | bigint        | Surrogate key for the fact record      |
| **inserted\_timestamp**                 | timestamp     | Time when the record was inserted      |
| **modified\_timestamp**                 | timestamp     | Time when the record was last modified |

## Table Sample

<TableSample />


# thorchain.defi_pool_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_pool_events

THORChain pool lifecycle events — creation, suspension, and status changes.

## Table Description

The `thorchain.defi_pool_events` table event data for pool-related events on THORChain. This table captures various pool events including balance changes and pool operations.

## Column Descriptions

| **Column**                 | **Type**  | **Description**                         |
| -------------------------- | --------- | --------------------------------------- |
| **asset**                  | varchar   | Asset identifier                        |
| **status**                 | varchar   | Status                                  |
| **event\_id**              | bigint    | Event identifier                        |
| **block\_timestamp**       | timestamp | Timestamp of when the block was created |
| **fact\_pool\_events\_id** | bigint    | Surrogate key for the fact record       |
| **day**                    | timestamp | Date of the record                      |
| **dim\_block\_id**         | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**    | timestamp | Time when the record was inserted       |
| **modified\_timestamp**    | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_refund_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_refund_events

THORChain refund events — returned transactions that couldn't be processed.

## Table Description

The `thorchain.defi_refund_events` table event data for refund on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                | **Type**  | **Description**                         |
| ------------------------- | --------- | --------------------------------------- |
| **tx\_id**                | bigint    | Transaction ID                          |
| **blockchain**            | varchar   | Source blockchain identifier            |
| **from\_address**         | varchar   | Source address                          |
| **to\_address**           | varchar   | Destination address                     |
| **asset**                 | varchar   | Asset identifier                        |
| **asset\_e8**             | bigint    | Asset amount in e8 units                |
| **asset\_2nd**            | varchar   | Asset 2Nd                               |
| **asset\_2nd\_e8**        | bigint    | Asset 2Nd E8                            |
| **memo**                  | varchar   | Transaction memo                        |
| **code**                  | varchar   | Code                                    |
| **reason**                | varchar   | Reason                                  |
| **event\_id**             | bigint    | Event identifier                        |
| **block\_timestamp**      | timestamp | Timestamp of when the block was created |
| **block\_time**           | timestamp | Timestamp of when the block was created |
| **block\_month**          | varchar   | Block Month                             |
| **\_tx\_type**            | varchar   | Tx Type                                 |
| **\_inserted\_timestamp** | timestamp | Timestamp of the record                 |

## Table Sample

<TableSample />


# thorchain.defi_reserve_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_reserve_events

THORChain reserve fund events — emissions from the protocol reserve.

## Table Description

The `thorchain.defi_reserve_events` table event data for reserve on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                    | **Type**  | **Description**                         |
| ----------------------------- | --------- | --------------------------------------- |
| **tx\_id**                    | bigint    | Transaction ID                          |
| **blockchain**                | varchar   | Source blockchain identifier            |
| **from\_address**             | varchar   | Source address                          |
| **to\_address**               | varchar   | Destination address                     |
| **asset**                     | varchar   | Asset identifier                        |
| **asset\_e8**                 | bigint    | Asset amount in e8 units                |
| **memo**                      | varchar   | Transaction memo                        |
| **address**                   | varchar   | Address                                 |
| **e8**                        | varchar   | E8                                      |
| **event\_id**                 | bigint    | Event identifier                        |
| **block\_timestamp**          | timestamp | Timestamp of when the block was created |
| **\_tx\_type**                | varchar   | Tx Type                                 |
| **block\_time**               | timestamp | Timestamp of when the block was created |
| **block\_month**              | timestamp | Block Month                             |
| **\_inserted\_timestamp**     | timestamp | Timestamp of the record                 |
| **fact\_reserve\_events\_id** | bigint    | Surrogate key for the fact record       |
| **dim\_block\_id**            | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**       | timestamp | Time when the record was inserted       |
| **modified\_timestamp**       | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_rewards_event_entries
Source: https://docs.dune.com/data-catalog/thorchain/defi_rewards_event_entries

THORChain reward distribution entries — per-pool reward allocations.

## Table Description

The `thorchain.defi_rewards_event_entries` table contains individual reward distribution entries on THORChain.

## Column Descriptions

| **Column**                            | **Type**  | **Description**                         |
| ------------------------------------- | --------- | --------------------------------------- |
| **pool\_name**                        | varchar   | Name of the liquidity pool              |
| **rune\_e8**                          | bigint    | RUNE amount in e8 units                 |
| **saver\_e8**                         | bigint    | Saver E8                                |
| **event\_id**                         | bigint    | Event identifier                        |
| **block\_timestamp**                  | timestamp | Timestamp of when the block was created |
| **\_inserted\_timestamp**             | timestamp | Timestamp of the record                 |
| **fact\_rewards\_event\_entries\_id** | bigint    | Surrogate key for the fact record       |
| **dim\_block\_id**                    | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**               | timestamp | Time when the record was inserted       |
| **modified\_timestamp**               | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_rewards_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_rewards_events

THORChain reward distribution events — block-level reward summaries.

## Table Description

The `thorchain.defi_rewards_events` table event data for rewards on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                    | **Type**  | **Description**                         |
| ----------------------------- | --------- | --------------------------------------- |
| **bond\_e8**                  | bigint    | Bond E8                                 |
| **event\_id**                 | bigint    | Event identifier                        |
| **block\_timestamp**          | timestamp | Timestamp of when the block was created |
| **fact\_rewards\_events\_id** | bigint    | Surrogate key for the fact record       |
| **day**                       | timestamp | Date of the record                      |
| **dim\_block\_id**            | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**       | timestamp | Time when the record was inserted       |
| **modified\_timestamp**       | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_rune_pool_deposit_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_rune_pool_deposit_events

THORChain RUNEPool deposit events.

## Table Description

The `thorchain.defi_rune_pool_deposit_events` table event data for rune pool deposit on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                | **Type**  | **Description**                         |
| ------------------------- | --------- | --------------------------------------- |
| **tx\_id**                | bigint    | Transaction ID                          |
| **rune\_addr**            | varchar   | Rune Addr                               |
| **amount\_e8**            | bigint    | Amount in e8 units (1e8 = 1 unit)       |
| **units**                 | varchar   | Units                                   |
| **event\_id**             | bigint    | Event identifier                        |
| **block\_timestamp**      | timestamp | Timestamp of when the block was created |
| **rune\_address**         | varchar   | Address                                 |
| **block\_time**           | timestamp | Timestamp of when the block was created |
| **block\_month**          | timestamp | Block Month                             |
| **\_inserted\_timestamp** | timestamp | Timestamp of the record                 |
| **dim\_block\_id**        | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**   | timestamp | Time when the record was inserted       |
| **modified\_timestamp**   | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_rune_pool_withdraw_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_rune_pool_withdraw_events

THORChain RUNEPool withdrawal events.

## Table Description

The `thorchain.defi_rune_pool_withdraw_events` table event data for rune pool withdraw on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                   | **Type**  | **Description**                         |
| ---------------------------- | --------- | --------------------------------------- |
| **tx\_id**                   | bigint    | Transaction ID                          |
| **rune\_addr**               | varchar   | Rune Addr                               |
| **amount\_e8**               | bigint    | Amount in e8 units (1e8 = 1 unit)       |
| **units**                    | varchar   | Units                                   |
| **basis\_points**            | int       | Basis Points                            |
| **affiliate\_basis\_pts**    | varchar   | Affiliate Basis Pts                     |
| **affiliate\_amount\_e8**    | bigint    | Amount value                            |
| **affiliate\_addr**          | varchar   | Affiliate Addr                          |
| **event\_id**                | bigint    | Event identifier                        |
| **block\_timestamp**         | timestamp | Timestamp of when the block was created |
| **rune\_address**            | varchar   | Address                                 |
| **affiliate\_basis\_points** | int       | Affiliate Basis Points                  |
| **affiliate\_address**       | varchar   | Address                                 |
| **block\_time**              | timestamp | Timestamp of when the block was created |
| **block\_month**             | timestamp | Block Month                             |
| **\_inserted\_timestamp**    | timestamp | Timestamp of the record                 |
| **dim\_block\_id**           | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**      | timestamp | Time when the record was inserted       |
| **modified\_timestamp**      | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_scheduled_outbound_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_scheduled_outbound_events

THORChain scheduled outbound queue — pending external chain transactions.

## Table Description

The `thorchain.defi_scheduled_outbound_events` table event data for scheduled outbound on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                                | **Type**      | **Description**                         |
| ----------------------------------------- | ------------- | --------------------------------------- |
| **blockchain**                            | varchar       | Source blockchain identifier            |
| **to\_address**                           | varchar       | Destination address                     |
| **asset**                                 | varchar       | Asset identifier                        |
| **asset\_e8**                             | bigint        | Asset amount in e8 units                |
| **asset\_decimals**                       | decimal(38,0) | Asset Decimals                          |
| **gas\_rate**                             | varchar       | Gas Rate                                |
| **memo**                                  | varchar       | Transaction memo                        |
| **in\_hash**                              | varchar       | In Hash                                 |
| **out\_hash**                             | varchar       | Out Hash                                |
| **max\_gas\_amount**                      | decimal(38,0) | Amount value                            |
| **max\_gas\_decimals**                    | decimal(38,0) | Max Gas Decimals                        |
| **max\_gas\_asset**                       | varchar       | Max Gas Asset                           |
| **module\_name**                          | varchar       | Module Name                             |
| **vault\_pub\_key**                       | varchar       | Vault Pub Key                           |
| **event\_id**                             | bigint        | Event identifier                        |
| **block\_timestamp**                      | timestamp     | Timestamp of when the block was created |
| **block\_time**                           | timestamp     | Timestamp of when the block was created |
| **block\_month**                          | varchar       | Block Month                             |
| **\_inserted\_timestamp**                 | timestamp     | Timestamp of the record                 |
| **fact\_scheduled\_outbound\_events\_id** | bigint        | Surrogate key for the fact record       |
| **dim\_block\_id**                        | bigint        | Reference to the block dimension table  |
| **inserted\_timestamp**                   | timestamp     | Time when the record was inserted       |
| **modified\_timestamp**                   | timestamp     | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_secure_asset_deposit_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_secure_asset_deposit_events

THORChain secure asset deposit events.

## Table Description

The `thorchain.defi_secure_asset_deposit_events` table event data for secure asset deposit on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                                   | **Type**  | **Description**                         |
| -------------------------------------------- | --------- | --------------------------------------- |
| **amount\_e8**                               | bigint    | Amount in e8 units (1e8 = 1 unit)       |
| **asset**                                    | varchar   | Asset identifier                        |
| **asset\_address**                           | varchar   | Address                                 |
| **rune\_address**                            | varchar   | Address                                 |
| **tx\_id**                                   | bigint    | Transaction ID                          |
| **event\_id**                                | bigint    | Event identifier                        |
| **block\_timestamp**                         | timestamp | Timestamp of when the block was created |
| **block\_time**                              | timestamp | Timestamp of when the block was created |
| **block\_month**                             | timestamp | Block Month                             |
| **\_inserted\_timestamp**                    | timestamp | Timestamp of the record                 |
| **fact\_secure\_asset\_deposit\_events\_id** | bigint    | Surrogate key for the fact record       |
| **dim\_block\_id**                           | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**                      | timestamp | Time when the record was inserted       |
| **modified\_timestamp**                      | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_secure_asset_withdraw_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_secure_asset_withdraw_events

THORChain secure asset withdrawal events.

## Table Description

The `thorchain.defi_secure_asset_withdraw_events` table event data for secure asset withdraw on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                                    | **Type**  | **Description**                         |
| --------------------------------------------- | --------- | --------------------------------------- |
| **amount\_e8**                                | bigint    | Amount in e8 units (1e8 = 1 unit)       |
| **asset**                                     | varchar   | Asset identifier                        |
| **asset\_address**                            | varchar   | Address                                 |
| **rune\_address**                             | varchar   | Address                                 |
| **tx\_id**                                    | bigint    | Transaction ID                          |
| **event\_id**                                 | bigint    | Event identifier                        |
| **block\_timestamp**                          | timestamp | Timestamp of when the block was created |
| **block\_time**                               | timestamp | Timestamp of when the block was created |
| **block\_month**                              | timestamp | Block Month                             |
| **\_inserted\_timestamp**                     | timestamp | Timestamp of the record                 |
| **fact\_secure\_asset\_withdraw\_events\_id** | bigint    | Surrogate key for the fact record       |
| **dim\_block\_id**                            | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**                       | timestamp | Time when the record was inserted       |
| **modified\_timestamp**                       | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_send_messages
Source: https://docs.dune.com/data-catalog/thorchain/defi_send_messages

THORChain send messages — internal transfer directives.

## Table Description

The `thorchain.defi_send_messages` table contains outgoing send messages on THORChain.

## Column Descriptions

| **Column**                   | **Type**  | **Description**                         |
| ---------------------------- | --------- | --------------------------------------- |
| **amount\_e8**               | bigint    | Amount in e8 units (1e8 = 1 unit)       |
| **asset**                    | varchar   | Asset identifier                        |
| **from\_address**            | varchar   | Source address                          |
| **to\_address**              | varchar   | Destination address                     |
| **memo**                     | varchar   | Transaction memo                        |
| **tx\_id**                   | bigint    | Transaction ID                          |
| **event\_id**                | bigint    | Event identifier                        |
| **block\_timestamp**         | timestamp | Timestamp of when the block was created |
| **block\_time**              | timestamp | Timestamp of when the block was created |
| **block\_month**             | timestamp | Block Month                             |
| **\_inserted\_timestamp**    | timestamp | Timestamp of the record                 |
| **fact\_send\_messages\_id** | bigint    | Surrogate key for the fact record       |
| **dim\_block\_id**           | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**      | timestamp | Time when the record was inserted       |
| **modified\_timestamp**      | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_stake_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_stake_events

THORChain staking events (legacy) — bond operations.

## Table Description

The `thorchain.defi_stake_events` table event data for stake on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                  | **Type**  | **Description**                           |
| --------------------------- | --------- | ----------------------------------------- |
| **pool\_name**              | varchar   | Name of the liquidity pool                |
| **asset\_tx\_id**           | bigint    | Identifier                                |
| **asset\_blockchain**       | varchar   | Asset Blockchain                          |
| **asset\_address**          | varchar   | Address                                   |
| **asset\_e8**               | bigint    | Asset amount in e8 units                  |
| **stake\_units**            | varchar   | Pool units (LP tokens) received or burned |
| **rune\_tx\_id**            | bigint    | Identifier                                |
| **rune\_address**           | varchar   | Address                                   |
| **rune\_e8**                | bigint    | RUNE amount in e8 units                   |
| **\_ASSET\_IN\_RUNE\_E8**   | bigint    | Asset In Rune E8                          |
| **event\_id**               | bigint    | Event identifier                          |
| **block\_timestamp**        | timestamp | Timestamp of when the block was created   |
| **\_INSERTED\_TIMESTAMP**   | timestamp | Timestamp of the record                   |
| **fact\_stake\_events\_id** | bigint    | Surrogate key for the fact record         |
| **day**                     | timestamp | Date of the record                        |
| **dim\_block\_id**          | bigint    | Reference to the block dimension table    |
| **inserted\_timestamp**     | timestamp | Time when the record was inserted         |
| **modified\_timestamp**     | timestamp | Time when the record was last modified    |

## Table Sample

<TableSample />


# thorchain.defi_streaming_swap_details_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_streaming_swap_details_events

THORChain streaming swap progress — partial fill details for large swaps.

## Table Description

The `thorchain.defi_streaming_swap_details_events` table event data for streaming swap details on THORChain. This table captures detailed information about streaming swaps including intervals, quantities, and success metrics.

## Column Descriptions

| **Column**                | **Type**       | **Description**                                           |
| ------------------------- | -------------- | --------------------------------------------------------- |
| **block\_time**           | timestamp      | Timestamp of when the block was created                   |
| **block\_date**           | date           | Date of when the block was created                        |
| **block\_month**          | timestamp      | Month of when the block was created                       |
| **block\_height**         | bigint         | Block height                                              |
| **tx\_id**                | varchar        | Transaction ID                                            |
| **event\_id**             | varchar        | Event identifier                                          |
| **interval**              | varchar        | Streaming swap interval                                   |
| **quantity**              | bigint         | Quantity in the streaming swap                            |
| **count**                 | bigint         | Count of swaps in the streaming                           |
| **last\_height**          | bigint         | Last block height                                         |
| **deposit\_asset**        | varchar        | Deposit asset identifier                                  |
| **deposit\_e8**           | bigint         | Deposit amount in e8 units                                |
| **in\_asset**             | varchar        | Input asset identifier                                    |
| **in\_e8**                | bigint         | Input amount in e8 units                                  |
| **out\_asset**            | varchar        | Output asset identifier                                   |
| **out\_e8**               | bigint         | Output amount in e8 units                                 |
| **failed\_swaps**         | array(varchar) | Array of failed swap information                          |
| **failed\_swap\_reasons** | array(varchar) | Array of reasons for failed swaps                         |
| **is\_successful**        | boolean        | Whether the streaming swap was successful                 |
| **failed\_swap\_count**   | bigint         | Number of failed swaps                                    |
| **trade\_direction**      | varchar        | Trade direction (sell\_rune, buy\_rune, asset\_to\_asset) |
| **inserted\_timestamp**   | timestamp      | Time when the record was inserted                         |
| **modified\_timestamp**   | timestamp      | Time when the record was last modified                    |

## Table Sample

<TableSample />


# thorchain.defi_swap_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_swap_events

THORChain swap events — cross-chain and intra-chain asset swaps with pricing.

## Table Description

The `thorchain.defi_swap_events` table provides event-level data for swaps executed on THORChain. This table captures detailed swap events including amounts, fees, slippage, and streaming swap information.

## Column Descriptions

| **Column**                 | **Type**  | **Description**                         |
| -------------------------- | --------- | --------------------------------------- |
| **tx\_id**                 | bigint    | Transaction ID                          |
| **blockchain**             | varchar   | Source blockchain identifier            |
| **from\_address**          | varchar   | Source address                          |
| **to\_address**            | varchar   | Destination address                     |
| **from\_asset**            | varchar   | Source asset identifier                 |
| **from\_e8**               | bigint    | From E8                                 |
| **to\_asset**              | varchar   | Destination asset identifier            |
| **to\_e8**                 | bigint    | To E8                                   |
| **memo**                   | varchar   | Transaction memo                        |
| **pool\_name**             | varchar   | Name of the liquidity pool              |
| **to\_e8\_min**            | bigint    | To E8 Min                               |
| **swap\_slip\_bp**         | varchar   | Swap slippage in basis points           |
| **liq\_fee\_e8**           | bigint    | Liq Fee E8                              |
| **liq\_fee\_in\_rune\_e8** | bigint    | Liq Fee In Rune E8                      |
| **\_DIRECTION**            | varchar   | Direction                               |
| **event\_id**              | bigint    | Event identifier                        |
| **block\_timestamp**       | timestamp | Timestamp of when the block was created |
| **streaming\_count**       | varchar   | Streaming Count                         |
| **streaming\_quantity**    | varchar   | Streaming Quantity                      |
| **\_TX\_TYPE**             | varchar   | Tx Type                                 |
| **\_INSERTED\_TIMESTAMP**  | timestamp | Timestamp of the record                 |
| **fact\_swap\_events\_id** | bigint    | Surrogate key for the swap event record |
| **dim\_block\_id**         | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**    | timestamp | Time when the record was inserted       |
| **modified\_timestamp**    | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_swaps
Source: https://docs.dune.com/data-catalog/thorchain/defi_swaps

THORChain swap records — comprehensive swap data with fees, slip, and routing.

## Table Description

The `thorchain.defi_swaps` table records all cross-chain native asset swaps executed on THORChain. This table captures swap transactions that allow users to swap native assets across multiple chains without wrapped or pegged tokens.

## Column Descriptions

| **Column**                               | **Type**       | **Description**                         |
| ---------------------------------------- | -------------- | --------------------------------------- |
| **block\_timestamp**                     | timestamp      | Timestamp of when the block was created |
| **block\_id**                            | bigint         | Identifier                              |
| **tx\_id**                               | bigint         | Transaction ID                          |
| **blockchain**                           | varchar        | Source blockchain identifier            |
| **pool\_name**                           | varchar        | Name of the liquidity pool              |
| **from\_address**                        | varchar        | Source address                          |
| **native\_to\_address**                  | varchar        | Address                                 |
| **to\_pool\_address**                    | varchar        | Address                                 |
| **affiliate\_address**                   | varchar        | Address                                 |
| **affiliate\_fee\_basis\_points**        | int            | Affiliate Fee Basis Points              |
| **affiliate\_addresses\_array**          | array(varchar) | Address                                 |
| **affiliate\_fee\_basis\_points\_array** | int            | Affiliate Fee Basis Points Array        |
| **from\_asset**                          | varchar        | Source asset identifier                 |
| **to\_asset**                            | varchar        | Destination asset identifier            |
| **from\_amount**                         | decimal(38,0)  | Amount of source asset                  |
| **to\_amount**                           | decimal(38,0)  | Amount of destination asset             |
| **min\_to\_amount**                      | decimal(38,0)  | Amount value                            |
| **from\_amount\_usd**                    | decimal(20,6)  | USD value                               |
| **to\_amount\_usd**                      | decimal(20,6)  | USD value                               |
| **rune\_usd**                            | decimal(20,6)  | Rune Usd                                |
| **asset\_usd**                           | decimal(20,6)  | Asset Usd                               |
| **to\_amount\_min\_usd**                 | decimal(20,6)  | USD value                               |
| **swap\_slip\_bp**                       | varchar        | Swap slippage in basis points           |
| **liq\_fee\_rune**                       | varchar        | Liquidity fee in RUNE                   |
| **liq\_fee\_rune\_usd**                  | decimal(20,6)  | USD value of liquidity fee in RUNE      |
| **liq\_fee\_asset**                      | varchar        | Liq Fee Asset                           |
| **liq\_fee\_asset\_usd**                 | decimal(20,6)  | Liq Fee Asset Usd                       |
| **streaming\_count**                     | varchar        | Streaming Count                         |
| **streaming\_quantity**                  | varchar        | Streaming Quantity                      |
| **\_TX\_TYPE**                           | varchar        | Tx Type                                 |
| **\_unique\_key**                        | varchar        | Unique Key                              |
| **\_inserted\_timestamp**                | timestamp      | Timestamp of the record                 |
| **fact\_swaps\_id**                      | bigint         | Surrogate key for the swap record       |
| **dim\_block\_id**                       | bigint         | Reference to the block dimension table  |
| **inserted\_timestamp**                  | timestamp      | Time when the record was inserted       |
| **modified\_timestamp**                  | timestamp      | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_switch_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_switch_events

THORChain BEP2/ERC20 to native RUNE switch events.

## Table Description

The `thorchain.defi_switch_events` table event data for switch on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                   | **Type**  | **Description**                         |
| ---------------------------- | --------- | --------------------------------------- |
| **tx\_id**                   | bigint    | Transaction ID                          |
| **from\_address**            | varchar   | Source address                          |
| **to\_address**              | varchar   | Destination address                     |
| **burn\_asset**              | varchar   | Burn Asset                              |
| **burn\_e8**                 | bigint    | Burn E8                                 |
| **mint\_e8**                 | bigint    | Mint E8                                 |
| **event\_id**                | bigint    | Event identifier                        |
| **block\_timestamp**         | timestamp | Timestamp of when the block was created |
| **block\_time**              | timestamp | Timestamp of when the block was created |
| **block\_month**             | timestamp | Block Month                             |
| **\_inserted\_timestamp**    | timestamp | Timestamp of the record                 |
| **fact\_switch\_events\_id** | bigint    | Surrogate key for the fact record       |
| **dim\_block\_id**           | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**      | timestamp | Time when the record was inserted       |
| **modified\_timestamp**      | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_tcy_claim_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_tcy_claim_events

THORChain TCY claim events.

## Table Description

The `thorchain.defi_tcy_claim_events` table event data for tcy claim on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                       | **Type**  | **Description**                         |
| -------------------------------- | --------- | --------------------------------------- |
| **tx\_id**                       | bigint    | Transaction ID                          |
| **rune\_address**                | varchar   | Address                                 |
| **l1\_address**                  | varchar   | Address                                 |
| **asset**                        | varchar   | Asset identifier                        |
| **tcy\_amt**                     | varchar   | Tcy Amt                                 |
| **memo**                         | varchar   | Transaction memo                        |
| **event\_id**                    | bigint    | Event identifier                        |
| **block\_timestamp**             | timestamp | Timestamp of when the block was created |
| **block\_time**                  | timestamp | Timestamp of when the block was created |
| **block\_month**                 | timestamp | Block Month                             |
| **\_inserted\_timestamp**        | timestamp | Timestamp of the record                 |
| **fact\_tcy\_claim\_events\_id** | bigint    | Surrogate key for the fact record       |
| **dim\_block\_id**               | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**          | timestamp | Time when the record was inserted       |
| **modified\_timestamp**          | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_tcy_distribution_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_tcy_distribution_events

THORChain TCY distribution events.

## Table Description

The `thorchain.defi_tcy_distribution_events` table event data for tcy distribution on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                              | **Type**  | **Description**                         |
| --------------------------------------- | --------- | --------------------------------------- |
| **rune\_address**                       | varchar   | Address                                 |
| **rune\_amt**                           | varchar   | Rune Amt                                |
| **event\_id**                           | bigint    | Event identifier                        |
| **block\_timestamp**                    | timestamp | Timestamp of when the block was created |
| **block\_time**                         | timestamp | Timestamp of when the block was created |
| **block\_month**                        | timestamp | Block Month                             |
| **\_inserted\_timestamp**               | timestamp | Timestamp of the record                 |
| **fact\_tcy\_distribution\_events\_id** | bigint    | Surrogate key for the fact record       |
| **dim\_block\_id**                      | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**                 | timestamp | Time when the record was inserted       |
| **modified\_timestamp**                 | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_tcy_stake_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_tcy_stake_events

THORChain TCY staking events.

## Table Description

The `thorchain.defi_tcy_stake_events` table event data for tcy stake on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                       | **Type**      | **Description**                         |
| -------------------------------- | ------------- | --------------------------------------- |
| **tx\_id**                       | bigint        | Transaction ID                          |
| **amount**                       | decimal(38,0) | Amount value                            |
| **rune\_address**                | varchar       | Address                                 |
| **memo**                         | varchar       | Transaction memo                        |
| **event\_id**                    | bigint        | Event identifier                        |
| **block\_timestamp**             | timestamp     | Timestamp of when the block was created |
| **block\_time**                  | timestamp     | Timestamp of when the block was created |
| **block\_month**                 | timestamp     | Block Month                             |
| **\_inserted\_timestamp**        | timestamp     | Timestamp of the record                 |
| **fact\_tcy\_stake\_events\_id** | bigint        | Surrogate key for the fact record       |
| **dim\_block\_id**               | bigint        | Reference to the block dimension table  |
| **inserted\_timestamp**          | timestamp     | Time when the record was inserted       |
| **modified\_timestamp**          | timestamp     | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_tcy_unstake_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_tcy_unstake_events

THORChain TCY unstaking events.

## Table Description

The `thorchain.defi_tcy_unstake_events` table event data for tcy unstake on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                         | **Type**      | **Description**                         |
| ---------------------------------- | ------------- | --------------------------------------- |
| **tx\_id**                         | bigint        | Transaction ID                          |
| **amount**                         | decimal(38,0) | Amount value                            |
| **rune\_address**                  | varchar       | Address                                 |
| **memo**                           | varchar       | Transaction memo                        |
| **event\_id**                      | bigint        | Event identifier                        |
| **block\_timestamp**               | timestamp     | Timestamp of when the block was created |
| **block\_time**                    | timestamp     | Timestamp of when the block was created |
| **block\_month**                   | timestamp     | Block Month                             |
| **\_inserted\_timestamp**          | timestamp     | Timestamp of the record                 |
| **fact\_tcy\_unstake\_events\_id** | bigint        | Surrogate key for the fact record       |
| **dim\_block\_id**                 | bigint        | Reference to the block dimension table  |
| **inserted\_timestamp**            | timestamp     | Time when the record was inserted       |
| **modified\_timestamp**            | timestamp     | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_total_block_rewards
Source: https://docs.dune.com/data-catalog/thorchain/defi_total_block_rewards

THORChain total block rewards — aggregate emissions per block.

## Table Description

The `thorchain.defi_total_block_rewards` table block-level data for total rewards on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                          | **Type**      | **Description**                         |
| ----------------------------------- | ------------- | --------------------------------------- |
| **block\_id**                       | bigint        | Identifier                              |
| **reward\_entity**                  | varchar       | Reward Entity                           |
| **rune\_amount**                    | decimal(38,0) | Amount in RUNE                          |
| **rune\_amount\_usd**               | decimal(20,6) | USD value of RUNE amount                |
| **\_unique\_key**                   | varchar       | Unique Key                              |
| **\_INSERTED\_TIMESTAMP**           | timestamp     | Timestamp of the record                 |
| **fact\_total\_block\_rewards\_id** | bigint        | Surrogate key for the fact record       |
| **block\_timestamp**                | timestamp     | Timestamp of when the block was created |
| **dim\_block\_id**                  | bigint        | Reference to the block dimension table  |
| **inserted\_timestamp**             | timestamp     | Time when the record was inserted       |
| **modified\_timestamp**             | timestamp     | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_total_value_locked
Source: https://docs.dune.com/data-catalog/thorchain/defi_total_value_locked

THORChain TVL snapshots — total value locked across all pools and features.

## Table Description

The `thorchain.defi_total_value_locked` table tracks total value locked (TVL) across THORChain pools.

## Column Descriptions

| **Column**                         | **Type**  | **Description**                        |
| ---------------------------------- | --------- | -------------------------------------- |
| **day**                            | date      | Date of the record                     |
| **total\_value\_pooled**           | varchar   | Total Value Pooled                     |
| **total\_value\_bonded**           | varchar   | Total Value Bonded                     |
| **total\_value\_locked**           | varchar   | Total Value Locked                     |
| **\_inserted\_timestamp**          | timestamp | Timestamp of the record                |
| **fact\_total\_value\_locked\_id** | bigint    | Surrogate key for the fact record      |
| **inserted\_timestamp**            | timestamp | Time when the record was inserted      |
| **modified\_timestamp**            | timestamp | Time when the record was last modified |

## Table Sample

<TableSample />


# thorchain.defi_trade_account_deposit_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_trade_account_deposit_events

THORChain trade account deposit events.

## Table Description

The `thorchain.defi_trade_account_deposit_events` table event data for trade account deposit on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                                    | **Type**  | **Description**                         |
| --------------------------------------------- | --------- | --------------------------------------- |
| **amount\_e8**                                | bigint    | Amount in e8 units (1e8 = 1 unit)       |
| **asset**                                     | varchar   | Asset identifier                        |
| **asset\_address**                            | varchar   | Address                                 |
| **rune\_address**                             | varchar   | Address                                 |
| **tx\_id**                                    | bigint    | Transaction ID                          |
| **event\_id**                                 | bigint    | Event identifier                        |
| **block\_timestamp**                          | timestamp | Timestamp of when the block was created |
| **block\_time**                               | timestamp | Timestamp of when the block was created |
| **block\_month**                              | timestamp | Block Month                             |
| **\_inserted\_timestamp**                     | timestamp | Timestamp of the record                 |
| **fact\_trade\_account\_deposit\_events\_id** | bigint    | Surrogate key for the fact record       |
| **dim\_block\_id**                            | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**                       | timestamp | Time when the record was inserted       |
| **modified\_timestamp**                       | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_trade_account_withdraw_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_trade_account_withdraw_events

THORChain trade account withdrawal events.

## Table Description

The `thorchain.defi_trade_account_withdraw_events` table event data for trade account withdraw on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                                     | **Type**  | **Description**                         |
| ---------------------------------------------- | --------- | --------------------------------------- |
| **amount\_e8**                                 | bigint    | Amount in e8 units (1e8 = 1 unit)       |
| **asset**                                      | varchar   | Asset identifier                        |
| **asset\_address**                             | varchar   | Address                                 |
| **rune\_address**                              | varchar   | Address                                 |
| **tx\_id**                                     | bigint    | Transaction ID                          |
| **event\_id**                                  | bigint    | Event identifier                        |
| **block\_timestamp**                           | timestamp | Timestamp of when the block was created |
| **block\_time**                                | timestamp | Timestamp of when the block was created |
| **block\_month**                               | timestamp | Block Month                             |
| **\_inserted\_timestamp**                      | timestamp | Timestamp of the record                 |
| **fact\_trade\_account\_withdraw\_events\_id** | bigint    | Surrogate key for the fact record       |
| **dim\_block\_id**                             | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**                        | timestamp | Time when the record was inserted       |
| **modified\_timestamp**                        | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_update_node_account_status_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_update_node_account_status_events

THORChain node status update events — active, standby, and disabled transitions.

## Table Description

The `thorchain.defi_update_node_account_status_events` table event data for update node account status on THORChain. This table is partitioned by day.

## Column Descriptions

| **Column**                                          | **Type**  | **Description**                         |
| --------------------------------------------------- | --------- | --------------------------------------- |
| **block\_timestamp**                                | timestamp | Timestamp of when the block was created |
| **former\_status**                                  | varchar   | Former Status                           |
| **current\_status**                                 | varchar   | Current Status                          |
| **node\_address**                                   | varchar   | Address                                 |
| **\_inserted\_timestamp**                           | timestamp | Timestamp of the record                 |
| **fact\_update\_node\_account\_status\_events\_id** | date      | Surrogate key for the fact record       |
| **dim\_block\_id**                                  | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**                             | timestamp | Time when the record was inserted       |
| **modified\_timestamp**                             | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_upgrades
Source: https://docs.dune.com/data-catalog/thorchain/defi_upgrades

THORChain protocol upgrade events — version changes and migration records.

## Table Description

The `thorchain.defi_upgrades` table contains data for protocol upgrade events on THORChain.

## Column Descriptions

| **Column**                | **Type**      | **Description**                         |
| ------------------------- | ------------- | --------------------------------------- |
| **block\_id**             | bigint        | Identifier                              |
| **tx\_id**                | bigint        | Transaction ID                          |
| **from\_address**         | varchar       | Source address                          |
| **to\_address**           | varchar       | Destination address                     |
| **burn\_asset**           | varchar       | Burn Asset                              |
| **rune\_amount**          | decimal(38,0) | Amount in RUNE                          |
| **rune\_amount\_usd**     | decimal(20,6) | USD value of RUNE amount                |
| **mint\_amount**          | decimal(38,0) | Amount value                            |
| **mint\_amount\_usd**     | decimal(20,6) | USD value                               |
| **\_unique\_key**         | varchar       | Unique Key                              |
| **\_inserted\_timestamp** | timestamp     | Timestamp of the record                 |
| **fact\_upgrades\_id**    | bigint        | Surrogate key for the fact record       |
| **block\_timestamp**      | timestamp     | Timestamp of when the block was created |
| **dim\_block\_id**        | bigint        | Reference to the block dimension table  |
| **inserted\_timestamp**   | timestamp     | Time when the record was inserted       |
| **modified\_timestamp**   | timestamp     | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.defi_withdraw_events
Source: https://docs.dune.com/data-catalog/thorchain/defi_withdraw_events

THORChain liquidity withdrawal events — assets removed from pools.

## Table Description

The `thorchain.defi_withdraw_events` table event data for liquidity withdrawal actions on THORChain. This table captures events when users remove liquidity from pools.

## Column Descriptions

| **Column**                      | **Type**  | **Description**                           |
| ------------------------------- | --------- | ----------------------------------------- |
| **\_TX\_TYPE**                  | varchar   | Tx Type                                   |
| **\_INSERTED\_TIMESTAMP**       | timestamp | Timestamp of the record                   |
| **fact\_withdraw\_events\_id**  | bigint    | Surrogate key for the fact record         |
| **block\_timestamp**            | timestamp | Timestamp of when the block was created   |
| **dim\_block\_id**              | bigint    | Reference to the block dimension table    |
| **tx\_id**                      | bigint    | Transaction ID                            |
| **blockchain**                  | varchar   | Source blockchain identifier              |
| **from\_address**               | varchar   | Source address                            |
| **to\_address**                 | varchar   | Destination address                       |
| **asset**                       | varchar   | Asset identifier                          |
| **asset\_e8**                   | bigint    | Asset amount in e8 units                  |
| **emit\_asset\_e8**             | bigint    | Emit Asset E8                             |
| **emit\_rune\_e8**              | bigint    | Emit Rune E8                              |
| **memo**                        | varchar   | Transaction memo                          |
| **pool\_name**                  | varchar   | Name of the liquidity pool                |
| **stake\_units**                | varchar   | Pool units (LP tokens) received or burned |
| **basis\_points**               | int       | Basis Points                              |
| **asymmetry**                   | varchar   | Asymmetry                                 |
| **imp\_loss\_protection\_e8**   | bigint    | Imp Loss Protection E8                    |
| **\_emit\_asset\_in\_rune\_e8** | bigint    | Emit Asset In Rune E8                     |
| **inserted\_timestamp**         | timestamp | Time when the record was inserted         |
| **modified\_timestamp**         | timestamp | Time when the record was last modified    |

## Table Sample

<TableSample />


# thorchain.gov_new_node_events
Source: https://docs.dune.com/data-catalog/thorchain/gov_new_node_events

THORChain new node registration events.

## Table Description

The `thorchain.gov_new_node_events` table event data for new node registration events on THORChain. This table tracks when new validator nodes are registered on the network.

## Column Descriptions

| **Column**                      | **Type**  | **Description**                         |
| ------------------------------- | --------- | --------------------------------------- |
| **node\_addr**                  | varchar   | Node Addr                               |
| **event\_id**                   | bigint    | Event identifier                        |
| **block\_timestamp**            | timestamp | Timestamp of when the block was created |
| **node\_address**               | varchar   | Address                                 |
| **block\_time**                 | timestamp | Timestamp of when the block was created |
| **block\_month**                | timestamp | Block Month                             |
| **\_inserted\_timestamp**       | timestamp | Timestamp of the record                 |
| **fact\_new\_node\_events\_id** | bigint    | Surrogate key for the fact record       |
| **dim\_block\_id**              | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**         | timestamp | Time when the record was inserted       |
| **modified\_timestamp**         | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.gov_set_ip_address_events
Source: https://docs.dune.com/data-catalog/thorchain/gov_set_ip_address_events

THORChain node IP address configuration events.

## Table Description

The `thorchain.gov_set_ip_address_events` table event data for set ip address on THORChain. This table is partitioned by block\_month.

## Column Descriptions

| **Column**                             | **Type**  | **Description**                         |
| -------------------------------------- | --------- | --------------------------------------- |
| **node\_addr**                         | varchar   | Node Addr                               |
| **ip\_addr**                           | varchar   | Ip Addr                                 |
| **event\_id**                          | bigint    | Event identifier                        |
| **block\_timestamp**                   | timestamp | Timestamp of when the block was created |
| **node\_address**                      | varchar   | Address                                 |
| **block\_time**                        | timestamp | Timestamp of when the block was created |
| **block\_month**                       | timestamp | Block Month                             |
| **\_inserted\_timestamp**              | timestamp | Timestamp of the record                 |
| **fact\_set\_ip\_address\_events\_id** | bigint    | Surrogate key for the fact record       |
| **dim\_block\_id**                     | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**                | timestamp | Time when the record was inserted       |
| **modified\_timestamp**                | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.gov_set_node_keys_events
Source: https://docs.dune.com/data-catalog/thorchain/gov_set_node_keys_events

THORChain node key rotation events.

## Table Description

The `thorchain.gov_set_node_keys_events` table event data for set node keys on THORChain. This table is partitioned by block\_month.

## Column Descriptions

| **Column**                            | **Type**  | **Description**                         |
| ------------------------------------- | --------- | --------------------------------------- |
| **node\_addr**                        | varchar   | Node Addr                               |
| **secp256k1**                         | varchar   | Secp256K1                               |
| **ed25519**                           | varchar   | Ed25519                                 |
| **validator\_consensus**              | varchar   | Identifier                              |
| **event\_id**                         | bigint    | Event identifier                        |
| **block\_timestamp**                  | timestamp | Timestamp of when the block was created |
| **node\_address**                     | varchar   | Address                                 |
| **block\_time**                       | timestamp | Timestamp of when the block was created |
| **block\_month**                      | timestamp | Block Month                             |
| **\_inserted\_timestamp**             | timestamp | Timestamp of the record                 |
| **fact\_set\_node\_keys\_events\_id** | bigint    | Surrogate key for the fact record       |
| **dim\_block\_id**                    | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**               | timestamp | Time when the record was inserted       |
| **modified\_timestamp**               | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.gov_set_node_mimir_events
Source: https://docs.dune.com/data-catalog/thorchain/gov_set_node_mimir_events

THORChain node Mimir vote events — node operator governance votes.

## Table Description

The `thorchain.gov_set_node_mimir_events` table event data for set node mimir on THORChain. This table is partitioned by block\_month.

## Column Descriptions

| **Column**                             | **Type**  | **Description**                         |
| -------------------------------------- | --------- | --------------------------------------- |
| **address**                            | varchar   | Address                                 |
| **key**                                | varchar   | Key                                     |
| **value**                              | varchar   | Value                                   |
| **event\_id**                          | bigint    | Event identifier                        |
| **block\_timestamp**                   | timestamp | Timestamp of when the block was created |
| **block\_time**                        | timestamp | Timestamp of when the block was created |
| **block\_month**                       | timestamp | Block Month                             |
| **\_inserted\_timestamp**              | timestamp | Timestamp of the record                 |
| **fact\_set\_node\_mimir\_events\_id** | bigint    | Surrogate key for the fact record       |
| **dim\_block\_id**                     | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**                | timestamp | Time when the record was inserted       |
| **modified\_timestamp**                | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.gov_set_version_events
Source: https://docs.dune.com/data-catalog/thorchain/gov_set_version_events

THORChain node version declaration events.

## Table Description

The `thorchain.gov_set_version_events` table event data for set version on THORChain. This table is partitioned by block\_month.

## Column Descriptions

| **Column**                         | **Type**  | **Description**                         |
| ---------------------------------- | --------- | --------------------------------------- |
| **node\_addr**                     | varchar   | Node Addr                               |
| **version**                        | varchar   | Version                                 |
| **event\_id**                      | bigint    | Event identifier                        |
| **block\_timestamp**               | timestamp | Timestamp of when the block was created |
| **node\_address**                  | varchar   | Address                                 |
| **block\_time**                    | timestamp | Timestamp of when the block was created |
| **block\_month**                   | timestamp | Block Month                             |
| **\_inserted\_timestamp**          | timestamp | Timestamp of the record                 |
| **fact\_set\_version\_events\_id** | bigint    | Surrogate key for the fact record       |
| **dim\_block\_id**                 | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**            | timestamp | Time when the record was inserted       |
| **modified\_timestamp**            | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.gov_slash_events
Source: https://docs.dune.com/data-catalog/thorchain/gov_slash_events

THORChain slash events — validator penalties for misbehavior.

## Table Description

The `thorchain.gov_slash_events` table event data for slashing events on THORChain. This table tracks validator slashing events including the pool, asset, and amount slashed. This table is partitioned by block\_month.

## Column Descriptions

| **Column**                  | **Type**  | **Description**                         |
| --------------------------- | --------- | --------------------------------------- |
| **pool\_name**              | varchar   | Name of the liquidity pool              |
| **asset**                   | varchar   | Asset identifier                        |
| **asset\_e8**               | bigint    | Asset amount in e8 units                |
| **event\_id**               | bigint    | Event identifier                        |
| **block\_timestamp**        | timestamp | Timestamp of when the block was created |
| **block\_time**             | timestamp | Timestamp of when the block was created |
| **block\_month**            | timestamp | Block Month                             |
| **\_inserted\_timestamp**   | timestamp | Timestamp of the record                 |
| **fact\_slash\_events\_id** | bigint    | Surrogate key for the fact record       |
| **dim\_block\_id**          | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**     | timestamp | Time when the record was inserted       |
| **modified\_timestamp**     | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.gov_slash_points_events
Source: https://docs.dune.com/data-catalog/thorchain/gov_slash_points_events

THORChain slash point accumulation events.

## Table Description

The `thorchain.gov_slash_points_events` table event data for slash points on THORChain. This table is partitioned by block\_month.

## Column Descriptions

| **Column**                  | **Type**  | **Description**                         |
| --------------------------- | --------- | --------------------------------------- |
| **node\_address**           | varchar   | Address                                 |
| **slash\_points**           | int       | Slash Points                            |
| **reason**                  | varchar   | Reason                                  |
| **event\_id**               | bigint    | Event identifier                        |
| **block\_timestamp**        | timestamp | Timestamp of when the block was created |
| **block\_time**             | timestamp | Timestamp of when the block was created |
| **block\_month**            | timestamp | Block Month                             |
| **\_inserted\_timestamp**   | timestamp | Timestamp of the record                 |
| **fact\_slash\_points\_id** | bigint    | Surrogate key for the fact record       |
| **dim\_block\_id**          | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**     | timestamp | Time when the record was inserted       |
| **modified\_timestamp**     | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# thorchain.gov_validator_request_leave_events
Source: https://docs.dune.com/data-catalog/thorchain/gov_validator_request_leave_events

THORChain validator leave request events — nodes signaling intent to exit.

## Table Description

The `thorchain.gov_validator_request_leave_events` table event data for validator request leave on THORChain. This table is partitioned by block\_month.

## Column Descriptions

| **Column**                                      | **Type**  | **Description**                         |
| ----------------------------------------------- | --------- | --------------------------------------- |
| **tx**                                          | varchar   | Tx                                      |
| **from\_addr**                                  | varchar   | From Addr                               |
| **node\_addr**                                  | varchar   | Node Addr                               |
| **event\_id**                                   | bigint    | Event identifier                        |
| **block\_timestamp**                            | timestamp | Timestamp of when the block was created |
| **tx\_id**                                      | bigint    | Transaction ID                          |
| **from\_address**                               | varchar   | Source address                          |
| **node\_address**                               | varchar   | Address                                 |
| **block\_time**                                 | timestamp | Timestamp of when the block was created |
| **block\_month**                                | timestamp | Block Month                             |
| **\_inserted\_timestamp**                       | timestamp | Timestamp of the record                 |
| **fact\_validator\_request\_leave\_events\_id** | bigint    | Surrogate key for the fact record       |
| **dim\_block\_id**                              | bigint    | Reference to the block dimension table  |
| **inserted\_timestamp**                         | timestamp | Time when the record was inserted       |
| **modified\_timestamp**                         | timestamp | Time when the record was last modified  |

## Table Sample

<TableSample />


# THORChain Data
Source: https://docs.dune.com/data-catalog/thorchain/overview

THORChain blockchain data on Dune

## What is THORChain?

THORChain is an independent, cross-chain liquidity protocol that operates as a Layer 1 decentralised exchange (DEX). Built on the Cosmos SDK, it utilises the CometBFT consensus engine, the Cosmos-SDK state machine, and the GG20 Threshold Signature Scheme (TSS) to execute its purpose, which is to allow users to swap native assets across multiple chains with zero reliance on centralised third parties. In doing so, it stands as one of the few exchanges that verifiably ensures transparent and fair prices for cross-chain swaps of native assets.

THORChain's design renders no need for wrapped or pegged assets. Instead, the protocol deploys what are called continuous liquidity pools (CLPs), which—with highly complex algorithms—maximise the efficiency of its transactions. These CLPs allow for THORChain to manage funds directly in on-chain vaults, and it secures those funds via an economic security model. For all this, THORChain might be best described as a "cross-chain automated market maker (AMM), like Uniswap", or even a "decentralised Binance".

### Key Features

* **Native Cross-Chain Swaps**: Swap native assets across multiple chains without wrapped or pegged tokens
* **Continuous Liquidity Pools (CLPs)**: Advanced AMM mechanism that maximizes transaction efficiency
* **Economic Security Model**: Secures funds through bonded RUNE and validator economics
* **THORNodes**: Anonymous validators who bond RUNE to provide validation services
* **Permissionless Network**: Anyone with required funds can become a validator

### THORChain's Financial Offerings

THORChain pursues two important financial primitives:

1. Allow a user to **Swap** Asset X on Chain A to Asset Y on Chain B.
2. Allow a user to **Pool** RUNE across liquidity pools.

## THORChain Data on Dune

THORChain blockchain data is organized into several key tables that capture different aspects of on-chain activity:

<CardGroup>
  <Card title="Blocks" icon="cube" href="/data-catalog/thorchain/core_block">
    Core block data including block headers, timestamps, and block statistics.
  </Card>

  <Card title="Transfers" icon="arrow-right-arrow-left" href="/data-catalog/thorchain/core_transfers">
    Native asset transfers between addresses on THORChain.
  </Card>

  <Card title="Swaps" icon="arrows-rotate" href="/data-catalog/thorchain/defi_swaps">
    Cross-chain native asset swaps executed on THORChain.
  </Card>

  <Card title="Daily Pool Stats" icon="water" href="/data-catalog/thorchain/defi_daily_pool_stats">
    Daily statistics for Continuous Liquidity Pools (CLPs) including liquidity, swaps, and fees.
  </Card>

  <Card title="Liquidity Actions" icon="plus-minus" href="/data-catalog/thorchain/defi_liquidity_actions">
    Add and remove liquidity actions across THORChain pools.
  </Card>

  <Card title="Swap Events" icon="circle-info" href="/data-catalog/thorchain/defi_swap_events">
    Event-level data for swaps including amounts, fees, and slippage.
  </Card>
</CardGroup>

## Network Specifications

* **Consensus**: CometBFT (Tendermint)
* **State Machine**: Cosmos SDK
* **Security**: GG20 Threshold Signature Scheme (TSS)
* **Validator Model**: THORNodes with bonded RUNE
* **Churn Schedule**: Every three days, rotating validators to prevent centralization

## Resources

* [THORChain Documentation](https://docs.thorchain.org/)
* [THORChain Developer Documentation](https://docs.thorchain.org/developers)


# ton.accounts
Source: https://docs.dune.com/data-catalog/ton/accounts

TON account data — wallet addresses, contract types, balances, and status.

## Table Description

The `ton.accounts` table contains all updates of accounts. Including updates of balance and code\_hash.
This table is created using [this SQL](https://github.com/duneanalytics/spellbook/blob/main/dbt_subprojects/daily_spellbook/models/ton/ton_accounts.sql).

## Column Descriptions

| **Column**                     | **type**                    | **Description**                                                                                                                                                                                                  |
| ------------------------------ | --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **address**                    | varchar                     | Account raw address                                                                                                                                                                                              |
| **status**                     | varchar                     | Status of account                                                                                                                                                                                                |
| **last\_tx\_hash**             | varchar                     | Hash of the latest transaction                                                                                                                                                                                   |
| **last\_tx\_at**               | timestamp(3) with time zone | timetsmap of the latest transaction                                                                                                                                                                              |
| **balance**                    | bigint                      | Raw ton balance                                                                                                                                                                                                  |
| **code\_hash**                 | varchar                     | Account code hash (on-chain value)                                                                                                                                                                               |
| **deployment\_tx\_hash**       | varchar                     | Hash of transaction when account was deployed                                                                                                                                                                    |
| **deployment\_at**             | timestamp(3) with time zone | Timestamp when account was deployed                                                                                                                                                                              |
| **deployment\_by\_external**   | boolean                     | Equals true when deployment of transactions was first transaction in trace, in other words when `(deployment tx_hash = deployment trace_id)`, false otherwise                                                    |
| **initial\_funding\_tx\_hash** | varchar                     | Transaction hash with the first occur of account in transactions                                                                                                                                                 |
| **initial\_funding\_at**       | timestamp(3) with time zone | Timestamp of the first occur of account in transactions                                                                                                                                                          |
| **first\_tx\_sender**          | varchar                     | Raw address of who intiated the first transaction with this account                                                                                                                                              |
| **interfaces**                 | array(varchar)              | The list of known available interfaces (for example `wallet_v4r2`, [full list available here](https://github.com/duneanalytics/spellbook/blob/main/dbt_subprojects/daily_spellbook/models/ton/ton_accounts.sql)) |

## Table Sample

Table sample can be found [here](https://dune.com/queries/3419983/5785629?table_name_t6f0df=accounts\&table_schema_t6f0df=ton).


# ton.balances_history
Source: https://docs.dune.com/data-catalog/ton/balances_history

TON account balance history — Toncoin holdings over time.

## Table Description

The `ton.balances_history` table contains information about all balances changes for native TON and jettons. This table allows
to get point time balance for each address as well latest balances.

## Column Descriptions

| **Column**            | **Type**      | **Description**                                                       |
| --------------------- | ------------- | --------------------------------------------------------------------- |
| **block\_time**       | timestamp     | Timestamp of when the block containing the balance change was created |
| **block\_date**       | date          | Date of when the block containing the balance change was created      |
| **address**           | string        | Account raw address                                                   |
| **asset**             | string        | Asset address or **TON** for TON balance                              |
| **amount**            | decimal(38,0) | Asset balance                                                         |
| **mintless\_claimed** | boolean       | Special flag for mintless jettons that mintless part was claimed      |
| **timestamp**         | int           | Unix timestamp of the transaction                                     |
| **lt**                | bigint        | Logical time of the transaction                                       |

## Table Sample

<TableSample />


# ton.blocks
Source: https://docs.dune.com/data-catalog/ton/blocks

TON block data — workchain, shard, seqno, and global block identifiers.

## Table Description

The `ton.blocks` table contains block-level data from the TON blockchain including block header information, validators, and block statistics. This table is partitioned by block\_date.

## Column Descriptions

| **Column**                       | **Type**  | **Description**                                   |
| -------------------------------- | --------- | ------------------------------------------------- |
| **block\_time**                  | timestamp | Timestamp of when the block was created           |
| **block\_date**                  | date      | Date of when the block was created                |
| **workchain**                    | int       | Workchain identifier                              |
| **shard**                        | bigint    | Shard identifier                                  |
| **seqno**                        | int       | Sequence number                                   |
| **root\_hash**                   | string    | Hash of the block root                            |
| **file\_hash**                   | string    | Hash of the block file                            |
| **mc\_block\_workchain**         | int       | Masterchain block workchain identifier            |
| **mc\_block\_shard**             | bigint    | Masterchain block shard identifier                |
| **mc\_block\_seqno**             | int       | Masterchain block sequence number                 |
| **global\_id**                   | int       | Global identifier                                 |
| **version**                      | int       | Block version                                     |
| **after\_merge**                 | boolean   | Flag indicating if block was created after merge  |
| **before\_split**                | boolean   | Flag indicating if block was created before split |
| **after\_split**                 | boolean   | Flag indicating if block was created after split  |
| **want\_merge**                  | boolean   | Flag indicating if block wants to merge           |
| **want\_split**                  | boolean   | Flag indicating if block wants to split           |
| **key\_block**                   | boolean   | Flag indicating if this is a key block            |
| **vert\_seqno\_incr**            | boolean   | Vertical sequence number increment flag           |
| **flags**                        | int       | Block flags                                       |
| **gen\_utime**                   | bigint    | Generation unix time                              |
| **start\_lt**                    | bigint    | Start logical time                                |
| **end\_lt**                      | bigint    | End logical time                                  |
| **validator\_list\_hash\_short** | int       | Short hash of validator list                      |
| **gen\_catchain\_seqno**         | int       | Generation catchain sequence number               |
| **min\_ref\_mc\_seqno**          | int       | Minimum reference masterchain sequence number     |
| **prev\_key\_block\_seqno**      | int       | Previous key block sequence number                |
| **vert\_seqno**                  | int       | Vertical sequence number                          |
| **master\_ref\_seqno**           | int       | Master reference sequence number                  |
| **rand\_seed**                   | string    | Random seed                                       |
| **created\_by**                  | string    | Creator of the block                              |
| **tx\_count**                    | int       | Number of transactions in the block               |
| **updated\_at**                  | timestamp | Last time the record was updated                  |
| **ingested\_at**                 | timestamp | Time when the record was ingested                 |

## Table Sample

<TableSample />


# ton.dex_pools
Source: https://docs.dune.com/data-catalog/ton/dex_pools

TON DEX liquidity pools — pool assets, reserves, and protocol.

## Table Description

The `ton.dex_pools` table contains information about decentralized exchange liquidity pools and their configurations on TON. This table is partitioned by block\_date.

## Column Descriptions

| **Column**          | **Type**       | **Description**                                                  |
| ------------------- | -------------- | ---------------------------------------------------------------- |
| **block\_time**     | timestamp      | Timestamp of when the block containing the pool data was created |
| **block\_date**     | date           | Date of when the block containing the pool data was created      |
| **pool**            | string         | Address of the liquidity pool                                    |
| **project**         | string         | Name of the DEX project                                          |
| **version**         | int            | Version of the DEX protocol                                      |
| **discovered\_at**  | int            | Unix timestamp when the pool was first discovered                |
| **jetton\_left**    | string         | Address of the first token in the pair                           |
| **jetton\_right**   | string         | Address of the second token in the pair                          |
| **reserves\_left**  | decimal(38,0)  | Reserve amount of the first token                                |
| **reserves\_right** | decimal(38,0)  | Reserve amount of the second token                               |
| **total\_supply**   | decimal(38,0)  | Total supply of LP tokens                                        |
| **tvl\_usd**        | decimal(20,6)  | Total value locked in USD                                        |
| **tvl\_ton**        | decimal(20,9)  | Total value locked in TON                                        |
| **last\_updated**   | int            | Unix timestamp of last update                                    |
| **is\_liquid**      | boolean        | Whether the pool has sufficient liquidity                        |
| **lp\_fee**         | decimal(12,10) | Fee paid to liquidity providers                                  |
| **protocol\_fee**   | decimal(12,10) | Fee paid to the protocol                                         |
| **referral\_fee**   | decimal(12,10) | Fee paid to referrers                                            |

## Table Sample

<TableSample />


# ton.dex_trades
Source: https://docs.dune.com/data-catalog/ton/dex_trades

TON DEX trades — swaps on DeDust, STON.fi, and other TON decentralized exchanges.

## Table Description

The `ton.dex_trades` table records of all trades executed on decentralized exchanges within the TON ecosystem. This table is partitioned by block\_date.

## Column Descriptions

| **Column**                 | **Type**      | **Description**                                              |
| -------------------------- | ------------- | ------------------------------------------------------------ |
| **block\_time**            | timestamp     | Timestamp of when the block containing the trade was created |
| **block\_date**            | date          | Date of when the block containing the trade was created      |
| **tx\_hash**               | string        | Transaction hash of the trade                                |
| **trace\_id**              | string        | Trace identifier for trade tracking                          |
| **project\_type**          | string        | Type of DEX project                                          |
| **project**                | string        | Name of the DEX project                                      |
| **version**                | int           | Version of the DEX protocol                                  |
| **event\_time**            | int           | Unix timestamp of the trade event                            |
| **event\_type**            | string        | Type of the trade event                                      |
| **trader\_address**        | string        | Address of the trader                                        |
| **pool\_address**          | string        | Address of the liquidity pool                                |
| **router\_address**        | string        | Address of the DEX router                                    |
| **token\_sold\_address**   | string        | Address of the token sold                                    |
| **token\_bought\_address** | string        | Address of the token bought                                  |
| **amount\_sold\_raw**      | decimal(38,0) | Raw amount of tokens sold                                    |
| **amount\_bought\_raw**    | decimal(38,0) | Raw amount of tokens bought                                  |
| **referral\_address**      | string        | Address of the referral                                      |
| **platform\_tag**          | string        | Tag identifying the platform                                 |
| **query\_id**              | decimal(20,0) | Query identifier                                             |
| **volume\_usd**            | decimal(20,6) | Trade volume in USD                                          |
| **volume\_ton**            | decimal(20,9) | Trade volume in TON                                          |
| **updated\_at**            | timestamp     | Last time the record was updated                             |
| **ingested\_at**           | timestamp     | Time when the record was ingested                            |

## Table Sample

<TableSample />


# ton.jetton_events
Source: https://docs.dune.com/data-catalog/ton/jetton_events

TON Jetton token events — transfers, mints, and burns.

## Table Description

The `ton.jetton_events` table tracks events related to Jettons (TON's equivalent of fungible tokens), including transfers, mints, and burns. This table is partitioned by block\_date.

## Column Descriptions

| **Column**                | **Type**      | **Description**                                              |
| ------------------------- | ------------- | ------------------------------------------------------------ |
| **block\_time**           | timestamp     | Timestamp of when the block containing the event was created |
| **block\_date**           | date          | Date of when the block containing the event was created      |
| **type**                  | string        | Type of the Jetton event                                     |
| **tx\_hash**              | string        | Transaction hash of the event                                |
| **tx\_lt**                | bigint        | Logical time of the transaction                              |
| **utime**                 | int           | Unix timestamp of the event                                  |
| **trace\_id**             | string        | Trace identifier for event tracking                          |
| **tx\_aborted**           | boolean       | Whether the transaction was aborted                          |
| **query\_id**             | decimal(20,0) | Query identifier                                             |
| **amount**                | decimal(38,0) | Amount of Jettons involved in the event                      |
| **source**                | string        | Source address of the event                                  |
| **destination**           | string        | Destination address of the event                             |
| **jetton\_wallet**        | string        | Address of the Jetton wallet                                 |
| **jetton\_master**        | string        | Address of the Jetton master contract                        |
| **response\_destination** | string        | Destination address for the response                         |
| **custom\_payload**       | binary        | Custom payload data                                          |
| **forward\_ton\_amount**  | decimal(38,0) | Amount of TON to forward                                     |
| **forward\_payload**      | binary        | Payload to forward                                           |
| **comment**               | string        | Comment attached to the event                                |
| **updated\_at**           | timestamp     | Last time the record was updated                             |
| **ingested\_at**          | timestamp     | Time when the record was ingested                            |

## Table Sample

<TableSample />


# ton.jetton_metadata
Source: https://docs.dune.com/data-catalog/ton/jetton_metadata

TON Jetton token metadata — name, symbol, decimals, and master contract.

## Table Description

The `ton.jetton_metadata` table contains metadata information for Jettons (TON's equivalent of fungible tokens), including name, symbol, decimals, and other token-specific details. This table has no partitioning.

## Column Descriptions

| **Column**                     | **Type**  | **Description**                         |
| ------------------------------ | --------- | --------------------------------------- |
| **address**                    | string    | Contract address of the Jetton          |
| **update\_time\_onchain**      | int       | Last update time recorded on-chain      |
| **update\_time\_metadata**     | int       | Last update time of the metadata        |
| **mintable**                   | boolean   | Whether the Jetton can be minted        |
| **admin\_address**             | string    | Address of the Jetton administrator     |
| **jetton\_content\_onchain**   | string    | On-chain content of the Jetton          |
| **jetton\_wallet\_code\_hash** | string    | Hash of the Jetton wallet code          |
| **code\_hash**                 | string    | Hash of the Jetton contract code        |
| **metadata\_status**           | int       | Status of the metadata                  |
| **symbol**                     | string    | Symbol/ticker of the Jetton             |
| **name**                       | string    | Name of the Jetton                      |
| **description**                | string    | Description of the Jetton               |
| **image**                      | string    | Image URL of the Jetton                 |
| **image\_data**                | string    | Raw image data of the Jetton            |
| **decimals**                   | int       | Number of decimal places for the Jetton |
| **sources**                    | struct    | Raw metadata sources                    |
| **tonapi\_image\_url**         | string    | TON API image URL for the Jetton        |
| **adding\_date**               | int       | Date when the Jetton was added          |
| **updated\_at**                | timestamp | Last time the record was updated        |
| **ingested\_at**               | timestamp | Time when the record was ingested       |

## Table Sample

<TableSample />


# ton.messages
Source: https://docs.dune.com/data-catalog/ton/messages

TON messages — internal and external messages between accounts.

## Table Description

The `ton.messages` table stores message data that is exchanged between smart contracts and users on the TON network. This table is partitioned by block\_date.

## Column Descriptions

| **Column**            | **Type**  | **Description**                                                |
| --------------------- | --------- | -------------------------------------------------------------- |
| **block\_time**       | timestamp | Timestamp of when the block containing the message was created |
| **block\_date**       | date      | Date of when the block containing the message was created      |
| **tx\_hash**          | string    | Transaction hash associated with the message                   |
| **tx\_lt**            | bigint    | Transaction logical time                                       |
| **tx\_now**           | int       | Transaction timestamp                                          |
| **msg\_hash**         | string    | Unique hash of the message                                     |
| **direction**         | string    | Direction of the message flow                                  |
| **trace\_id**         | string    | Trace identifier for message tracking                          |
| **source**            | string    | Source address of the message                                  |
| **destination**       | string    | Destination address of the message                             |
| **value**             | bigint    | Value transferred in the message                               |
| **fwd\_fee**          | bigint    | Forward fee for the message                                    |
| **ihr\_fee**          | bigint    | IHR (Instant Hypercube Routing) fee                            |
| **created\_lt**       | bigint    | Logical time when message was created                          |
| **created\_at**       | bigint    | Unix timestamp when message was created                        |
| **opcode**            | int       | Operation code of the message                                  |
| **ihr\_disabled**     | boolean   | Whether IHR is disabled for this message                       |
| **bounce**            | boolean   | Whether the message can bounce                                 |
| **bounced**           | boolean   | Whether the message was bounced                                |
| **import\_fee**       | bigint    | Import fee for the message                                     |
| **body\_hash**        | string    | Hash of the message body                                       |
| **body\_boc**         | binary    | Binary data of the message body                                |
| **comment**           | string    | Human-readable comment attached to the message                 |
| **init\_state\_hash** | string    | Hash of the initial state                                      |
| **init\_state\_boc**  | binary    | Binary data of the initial state                               |
| **updated\_at**       | timestamp | Last time the record was updated                               |
| **ingested\_at**      | timestamp | Time when the record was ingested                              |

## Table Sample

<TableSample />


# ton.nft_events
Source: https://docs.dune.com/data-catalog/ton/nft_events

TON NFT events — transfers, sales, and ownership changes.

## Table Description

The `ton.nft_events` table records of all NFT-related events on the TON blockchain, including mints, transfers, and sales. This table is partitioned by block\_date.

## Column Descriptions

| **Column**                    | **Type**      | **Description**                                              |
| ----------------------------- | ------------- | ------------------------------------------------------------ |
| **block\_time**               | timestamp     | Timestamp of when the block containing the event was created |
| **block\_date**               | date          | Date of when the block containing the event was created      |
| **type**                      | string        | Type of NFT event (mint, transfer, sale, etc.)               |
| **nft\_item\_address**        | string        | Address of the NFT item                                      |
| **is\_init**                  | boolean       | Whether the NFT is initialized                               |
| **nft\_item\_index**          | int           | Index of the NFT within its collection                       |
| **collection\_address**       | string        | Address of the NFT collection (nullable)                     |
| **owner\_address**            | string        | Address of the NFT owner                                     |
| **content\_onchain**          | string        | NFT metadata extracted from on-chain data                    |
| **timestamp**                 | int           | Timestamp of NFT state update or action                      |
| **lt**                        | bigint        | Logical time of NFT state update or action                   |
| **tx\_hash**                  | string        | Transaction hash if applicable                               |
| **trace\_id**                 | string        | Trace identifier if applicable                               |
| **prev\_owner**               | string        | Previous owner address if applicable                         |
| **query\_id**                 | decimal(20,0) | Query identifier if exists                                   |
| **forward\_amount**           | decimal(38,0) | Amount of forward message from transfer if related           |
| **forward\_payload**          | binary        | Payload of forward message from transfer if related          |
| **comment**                   | string        | Text comment from forward\_payload                           |
| **custom\_payload**           | string        | Custom payload from transfer message if related              |
| **sale\_contract**            | string        | Address of sale contract if related                          |
| **sale\_type**                | string        | Type of sale (sale or auction)                               |
| **sale\_end\_time**           | int           | End time of sale if applicable (unixtime)                    |
| **marketplace\_address**      | string        | Address of the marketplace                                   |
| **marketplace\_fee\_address** | string        | Address receiving marketplace fee                            |
| **marketplace\_fee**          | decimal(38,0) | Amount of marketplace fee                                    |
| **sale\_price**               | decimal(38,0) | Price of the NFT                                             |
| **payment\_asset**            | string        | Asset type of payment (only TON supported)                   |
| **royalty\_address**          | string        | Address receiving royalty                                    |
| **royalty\_amount**           | decimal(38,0) | Amount of royalty                                            |
| **auction\_max\_bid**         | decimal(38,0) | Maximum bid for auction                                      |
| **auction\_min\_bid**         | decimal(38,0) | Minimum bid for auction                                      |
| **auction\_min\_step**        | decimal(38,0) | Minimum bid step for auction                                 |
| **updated\_at**               | timestamp     | Last time the record was updated                             |
| **ingested\_at**              | timestamp     | Time when the record was ingested                            |

Supported event types:

| Type          | prev\_owner      | Comments                                                                                                  |
| ------------- | ---------------- | --------------------------------------------------------------------------------------------------------- |
| mint          | deployer address | Tx related to the NFT deployment                                                                          |
| put\_on\_sale | null             | NFT is put on sale via sale contract                                                                      |
| cancel\_sale  | null             | Sale is cancelled and NFT is returned to the owner                                                        |
| sale          | seller           | NFT is sold via sale contract, see sale related fields for details                                        |
| transfer      | previous owner   | Direct NFT transfer between addresses. Also includes automatic transfers of TON DNS in case of expiration |
| bid           | bidder           | New bid for an auction                                                                                    |

## Table Sample

<TableSample />


# ton.jetton_metadata
Source: https://docs.dune.com/data-catalog/ton/nft_metadata

TON NFT metadata — collection info, item details, and content URLs.

## Table Description

The `ton.jetton_metadata` table contains metadata information for NFT items and collections.

## Column Descriptions

| **Column**                 | **Type**  | **Description**                                                                           |
| -------------------------- | --------- | ----------------------------------------------------------------------------------------- |
| **type**                   | string    | Possible values: item or collection                                                       |
| **address**                | string    | NFT item/collection address                                                               |
| **update\_time\_onchain**  | int       | Last update time recorded on-chain                                                        |
| **update\_time\_metadata** | int       | Last update time of the metadata                                                          |
| **parent\_address**        | string    | Collection owner address if type is collection, otherwise collection address for the item |
| **content\_onchain**       | string    | On-chain content                                                                          |
| **metadata\_status**       | int       | Status of the metadata                                                                    |
| **name**                   | string    | TEP-64 NFT name                                                                           |
| **description**            | string    | TEP-64 NFT description                                                                    |
| **image**                  | string    | TEP-64 NFT image URL                                                                      |
| **image\_data**            | string    | TEP-64 NFT image data                                                                     |
| **attributes**             | string    | TEP-64 NFT attributes                                                                     |
| **sources**                | struct    | Raw metadata sources                                                                      |
| **tonapi\_image\_url**     | string    | TON API image URL                                                                         |
| **adding\_date**           | int       | Date when the metadata was added                                                          |
| **updated\_at**            | timestamp | Last time the record was updated                                                          |
| **ingested\_at**           | timestamp | Time when the record was ingested                                                         |

## Table Sample

<TableSample />


# TON Data
Source: https://docs.dune.com/data-catalog/ton/overview

TON blockchain data on Dune

## What is TON?

The Open Network (TON) is a fast, secure, and scalable blockchain platform designed to handle millions of transactions per second. Originally developed by Telegram, TON features a unique architecture including:

* **Infinite Sharding**: Dynamic sharding mechanism that allows the network to automatically split and merge blockchains to adapt to load.
* **Proof-of-Stake**: Secure and energy-efficient consensus mechanism.
* **TON Virtual Machine (TVM)**: Handles smart contract execution with support for multiple programming languages.
* **Jettons**: TON's implementation of fungible tokens (similar to ERC-20).

## TON Data on Dune

TON blockchain data is organized into several key tables that capture different aspects of on-chain activity:

<CardGroup>
  <Card title="Blocks" icon="cube" href="/data-catalog/ton/blocks">
    Core block data including block headers, validators, and block statistics.
  </Card>

  <Card title="Transactions" icon="arrow-right-arrow-left" href="/data-catalog/ton/transactions">
    Detailed transaction data including computation, actions, and state changes.
  </Card>

  <Card title="Messages" icon="envelope" href="/data-catalog/ton/messages">
    Inter-contract messages and value transfers between accounts.
  </Card>

  <Card title="Balances history" icon="book" href="/data-catalog/ton/balances_history">
    TON and jettons balances history.
  </Card>

  <Card title="DEX Pools" icon="water" href="/data-catalog/ton/dex_pools">
    Liquidity pool configurations and statistics from decentralized exchanges.
  </Card>

  <Card title="DEX Trades" icon="arrows-rotate" href="/data-catalog/ton/dex_trades">
    Trading activity across TON's decentralized exchanges.
  </Card>

  <Card title="Jetton Events" icon="token" href="/data-catalog/ton/jetton_events">
    Events related to TON's native token standard (Jettons).
  </Card>

  <Card title="Jetton Metadata" icon="circle-info" href="/data-catalog/ton/jetton_metadata">
    Metadata for Jettons including name, symbol, and decimals.
  </Card>

  <Card title="NFT Events" icon="image" href="/data-catalog/ton/nft_events">
    NFT Events (mints, sales, transfers and others)
  </Card>

  <Card title="NFT Metadata" icon="circle-info" href="/data-catalog/ton/nft_metadata">
    Metadata for NFT items and collections
  </Card>

  <Card title="Assets prices" icon="dollar-sign" href="/data-catalog/ton/prices_daily">
    Assets prices based on onchain data
  </Card>
</CardGroup>


# ton.prices_daily
Source: https://docs.dune.com/data-catalog/ton/prices_daily

TON daily token price aggregates — historical pricing data for Toncoin and Jetton tokens.

## Table Description

The `ton.prices_daily` table contains daily prices for most popular assets. All prices are derived from onchain events, the following types of assets are supported:

* Jettons with sufficient trading volume on DEXs
* DEX LP tokens (based on ton.dex\_pools TVL values)
* StormTrade LP tokens
* tsUSDe

This table is created using [this SQL](https://github.com/duneanalytics/spellbook/blob/main/dbt_subprojects/daily_spellbook/models/ton/ton_jetton_price_daily.sql).

## Column Descriptions

| **Column**         | **type**         | **Description**                                                                                |
| ------------------ | ---------------- | ---------------------------------------------------------------------------------------------- |
| **blockchain**     | varchar          | Blockchain for the token (Equals to ton)                                                       |
| **token\_address** | varchar          | Token (Jetton) address in raw format                                                           |
| **timestamp**      | timestamp        | Start of the day in UTC                                                                        |
| **price\_ton**     | double precision | Jetton price in TON (ignoring decimals)                                                        |
| **price\_usd**     | double precision | Jetton price in USD (ignoring decimals)                                                        |
| **asset\_type**    | varchar          | Asset type: Jetton (price is based on DEX trades), DEX LP, SLP (StormTrade LP token) or tsUSDe |

Note: **price\_ton** and **price\_usd** values are already adjusted for token decimals, so multiplying token amounts by these prices will give the correct value without needing decimal conversion.

## Table Sample

Table sample can be found [here](https://dune.com/queries/3419983/5785629?table_name_t6f0df=prices_daily\&table_schema_t6f0df=ton).


# ton.transactions
Source: https://docs.dune.com/data-catalog/ton/transactions

TON transaction records — account, fees, compute phase, and action results.

## Table Description

The `ton.transactions` table records all transactions processed on the TON network, including transfers and smart contract interactions. This table is partitioned by block\_date.

## Column Descriptions

| Column                             | Type      | Description                                                        |
| ---------------------------------- | --------- | ------------------------------------------------------------------ |
| block\_time                        | timestamp | Timestamp of when the block containing the transaction was created |
| block\_date                        | date      | Date of when the block containing the transaction was created      |
| account                            | string    | Account address involved in the transaction                        |
| hash                               | string    | Transaction hash                                                   |
| lt                                 | bigint    | Logical time of the transaction                                    |
| block\_workchain                   | int       | Workchain identifier of the block                                  |
| block\_shard                       | bigint    | Shard identifier of the block                                      |
| block\_seqno                       | int       | Sequence number of the block                                       |
| mc\_block\_seqno                   | int       | Masterchain block sequence number                                  |
| trace\_id                          | string    | Trace identifier for transaction tracking                          |
| prev\_trans\_hash                  | string    | Hash of the previous transaction                                   |
| prev\_trans\_lt                    | bigint    | Logical time of the previous transaction                           |
| now                                | int       | Unix timestamp of the transaction                                  |
| orig\_status                       | string    | Original status of the transaction                                 |
| end\_status                        | string    | Final status of the transaction                                    |
| total\_fees                        | bigint    | Total fees paid for the transaction                                |
| account\_state\_hash\_before       | string    | Hash of account state before transaction                           |
| account\_state\_hash\_after        | string    | Hash of account state after transaction                            |
| account\_state\_code\_hash\_before | string    | Hash of account state code before transaction                      |
| account\_state\_code\_hash\_after  | string    | Hash of account state code after transaction                       |
| account\_state\_balance\_before    | bigint    | Account balance before transaction                                 |
| account\_state\_balance\_after     | bigint    | Account balance after transaction                                  |
| descr                              | string    | Description of the transaction                                     |
| aborted                            | boolean   | Whether the transaction was aborted                                |
| destroyed                          | boolean   | Whether the account was destroyed                                  |
| credit\_first                      | boolean   | Whether credit was processed first                                 |
| is\_tock                           | boolean   | Whether the transaction is a tock                                  |
| installed                          | boolean   | Whether contract was installed                                     |
| storage\_fees\_collected           | bigint    | Storage fees collected                                             |
| storage\_fees\_due                 | bigint    | Storage fees due                                                   |
| storage\_status\_change            | string    | Change in storage status                                           |
| credit\_due\_fees\_collected       | bigint    | Credit fees collected                                              |
| credit                             | bigint    | Credit amount                                                      |
| compute\_skipped                   | boolean   | Whether computation was skipped                                    |
| skipped\_reason                    | string    | Reason for skipping computation                                    |
| compute\_success                   | boolean   | Whether computation was successful                                 |
| compute\_msg\_state\_used          | boolean   | Whether message state was used in computation                      |
| compute\_account\_activated        | boolean   | Whether account was activated during computation                   |
| compute\_gas\_fees                 | bigint    | Gas fees for computation                                           |
| compute\_gas\_used                 | bigint    | Amount of gas used in computation                                  |
| compute\_gas\_limit                | bigint    | Gas limit for computation                                          |
| compute\_gas\_credit               | bigint    | Gas credit for computation                                         |
| compute\_mode                      | int       | Computation mode                                                   |
| compute\_exit\_code                | int       | Exit code of computation                                           |
| compute\_exit\_arg                 | int       | Exit argument of computation                                       |
| compute\_vm\_steps                 | bigint    | Number of VM steps in computation                                  |
| compute\_vm\_init\_state\_hash     | string    | Hash of VM initial state                                           |
| compute\_vm\_final\_state\_hash    | string    | Hash of VM final state                                             |
| action\_success                    | boolean   | Whether action was successful                                      |
| action\_valid                      | boolean   | Whether action was valid                                           |
| action\_no\_funds                  | boolean   | Whether action failed due to insufficient funds                    |
| action\_status\_change             | string    | Change in action status                                            |
| action\_total\_fwd\_fees           | bigint    | Total forward fees for actions                                     |
| action\_total\_action\_fees        | bigint    | Total fees for actions                                             |
| action\_result\_code               | int       | Result code of action                                              |
| action\_result\_arg                | int       | Result argument of action                                          |
| action\_tot\_actions               | int       | Total number of actions                                            |
| action\_spec\_actions              | int       | Number of special actions                                          |
| action\_skipped\_actions           | int       | Number of skipped actions                                          |
| action\_msgs\_created              | int       | Number of messages created by action                               |
| action\_action\_list\_hash         | string    | Hash of action list                                                |
| action\_tot\_msg\_size\_cells      | bigint    | Total message size in cells                                        |
| action\_tot\_msg\_size\_bits       | bigint    | Total message size in bits                                         |
| bounce                             | string    | Whether the transaction bounced                                    |
| bounce\_msg\_size\_cells           | bigint    | Bounce message size in cells                                       |
| bounce\_msg\_size\_bits            | bigint    | Bounce message size in bits                                        |
| bounce\_req\_fwd\_fees             | bigint    | Required forward fees for bounce                                   |
| bounce\_msg\_fees                  | bigint    | Message fees for bounce                                            |
| bounce\_fwd\_fees                  | bigint    | Forward fees for bounce                                            |
| split\_info\_cur\_shard\_pfx\_len  | int       | Current shard prefix length for split                              |
| split\_info\_acc\_split\_depth     | int       | Account split depth                                                |
| split\_info\_this\_addr            | string    | This address in split                                              |
| split\_info\_sibling\_addr         | string    | Sibling address in split                                           |
| updated\_at                        | timestamp | Last time the record was updated                                   |
| ingested\_at                       | timestamp | Time when the record was ingested                                  |

## Table Sample

<TableSample />


# tron.contracts
Source: https://docs.dune.com/data-catalog/tron/decoded/contracts

Verified contract registry on Tron — contract name, ABI, and deployment details.

## Table Description

The `tron.contracts` table contains information about the contracts Dune has decoded on the Tron blockchain.

You can use this table to find information about the contracts that have been decoded by Dune.

## Table Schema

| Column            | Type           | Description                                                                                           |
| ----------------- | -------------- | ----------------------------------------------------------------------------------------------------- |
| abi\_id           | varchar        | Unique identifier for the contract's ABI definition                                                   |
| abi               | array(varchar) | The full ABI (Application Binary Interface) of the contract as an array of function/event definitions |
| address           | varbinary      | The contract's deployment address on the Tron blockchain                                              |
| from              | varbinary      | Address of the account that deployed this contract                                                    |
| code              | varbinary      | The bytecode of the deployed contract                                                                 |
| name              | varchar        | Human-readable name of the contract (e.g. "SunswapV2Router")                                          |
| namespace         | varchar        | Project or protocol namespace the contract belongs to (e.g. "sunswapv2")                              |
| dynamic           | boolean        | Whether the contract was dynamically decoded via ABI matching                                         |
| base              | boolean        | Whether this is a base contract (not created by a factory)                                            |
| factory           | boolean        | Whether this contract was created by a factory contract                                               |
| detection\_source | varchar        | How the contract was detected and added to Dune's decoded set (e.g. "base", "factory")                |
| created\_at       | timestamp(3)   | Timestamp when this record was created in Dune's database                                             |

## Table Sample

<TableSample />


# Event Logs
Source: https://docs.dune.com/data-catalog/tron/decoded/event-logs

Smart Contracts emit event logs when certain predefined actions are completed.

## Overview

Smart contracts emit event logs when certain predefined actions are completed. The emitted event logs are stored on the blockchain and are publicly accessible. Event logs are an important tool for smart contract developers to communicate with the outside world, as well as for data analysts to keep track of what happens inside of a smart contract.

For example, the TRC20 standard defines the `Transfer` event, which is emitted every time a token transfer occurs. The event log contains the sender, the recipient and the amount of tokens transferred.

```solidity theme={null}
event Transfer(address indexed from, address indexed to, uint256 value);
```

Decoded event logs always originate from the fields `topic0`, `topic1`, `topic2`, `topic3` and `data` in the `logs` table.

## Event Logs in Dune

In Dune, we store all event logs of decoded smart contracts in separate tables.

The structure published in these logs is predefined by the developer of the smart contract, the content is dynamically created during the transaction.

Logs are useful for monitoring, alerting and in general keeping track of what happens inside of a smart contract. Logs are your best friend as a data analyst since they reliably present you with data that is intended to be analyzed post factum. If you ever want to see which logs *can* be emitted by a smart contract, you can simply search for the keyword `emit` in the source code of the smart contract.

We will decode all event logs for smart contracts into tables named accordingly to this schema:

`[projectname_blockchain].[contractName]_evt_[eventName]`

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/tron/decoded/contracts" />
</CardGroup>


# Decoded Tron data
Source: https://docs.dune.com/data-catalog/tron/decoded/overview

Simplifying smart contract analysis through human-readable tables.

### Overview of Dune's Decoded Data Approach

Dune uses the ABI (Application Binary Interface) of smart contracts to decode blockchain transactions into structured tables. Each event log and function call from the ABI are parsed into their own tables. This decoding process transforms the raw, encoded data on the blockchain into human-readable tables, simplifying the analysis of smart contract data.

Dune's decoded data approach offers several benefits:

* **Enhanced Readability:** The decoded data tables provide a clear and intuitive representation of smart contract activities

* **Efficient Analysis:** The structured tables enable efficient querying and analysis of smart contract data

* **Handling Multiple Contract Instances:** For smart contracts with multiple instances, Dune aggregates the data from these instances into a single table, simplifying the analysis process.

* **Collaborative Mapping:** Dune's smart contract library is continuously expanded through the active participation of the Dune community, ensuring that the decoding coverage remains comprehensive and current.

<CardGroup>
  <Card title="Explore decoded logs" icon="circle-bolt" href="/data-catalog/tron/decoded/event-logs" />
</CardGroup>

## Which contracts have decoded data?

Contract submissions on Dune are driven by the community. Usually, the odds are good that the contract you are looking at is already decoded, but especially for new projects or new contracts, it might be that the contract is not decoded yet. In those cases, you can submit the contract to be decoded. Decoding usually takes about 24 hours, in special cases it might take longer.

You can check if contracts are already decoded by querying [`[blockchain].contracts`](/data-catalog/tron/decoded/contracts) tables, the [data explorer](/web-app/query-editor/data-explorer) or use [this dashboard](https://dune.com/dune/is-my-contract-decoded-yet-v2).

<CardGroup>
  <Card title="Submit any contract for decoding" icon="file-import" href="/web-app/decoding/decoding-contracts" />

  <Card title="Explore already decoded contracts" icon="database" href="/data-catalog/tron/decoded/contracts" />
</CardGroup>

## How does decoding work?

Smart Contracts on the TVM blockchain are mostly written in high level languages like [Solidity](https://docs.soliditylang.org/en/v0.8.2) or [Vyper](https://vyper.readthedocs.io/en/stable).

For them to be able to be deployed to a TVM execution environment, they need to be compiled to TVM executable bytecode. Once deployed, the bytecode gets associated with an address on the respective chain and is permanently stored in this chain's state storage.

To be able to interact with this smart contract, which is now just bytecode, we need a guide to be able to call the functions that are defined in the high-level languages. This translation of names and arguments into byte representation is done using an **Application Binary Interface (ABI)**.

The ABI documents names, types, and arguments precisely which allows us to interact with the smart contract using a somewhat human-readable format. The ABI can be compiled using the high-level language source code.

**The ABI is used to call a smart contract or interpret the data it emits.**

<img alt="source: https://hackernoon.com/hn-images/1*Sz1a7G2pQ62UnkHoieve4w.jpeg" />


# TRON Overview
Source: https://docs.dune.com/data-catalog/tron/overview

TRON data on Dune

TRON is an EVM-compatible Layer1 blockchain that uses a Delegated Proof of Stake (DPoS) consensus mechanism, where 27 Super Representatives are elected to validate transactions and produce blocks.

The TRON network has a native token called TRX, which is used to pay for transactions and smart contract execution. TRON also supports the creation of custom tokens, which can be used for various purposes such as fundraising and governance. TRON's smart contract platform is compatible with the Ethereum Virtual Machine (EVM), which allows developers to deploy Solidity smart contracts on TRON.

Dune provides raw, decoded and aggregated data for the TRON network, including event logs, blocks, transactions, tokens and Tether on TRON.
The datasets are similar to our EVM chains, but without internal transactions and traces as the TRON clients do not provide this data.

## Data Catalog

<CardGroup>
  <Card title="Logs" icon="bolt" href="/data-catalog/tron/raw/logs">
    Event logs from smart contracts
  </Card>

  <Card title="Blocks" icon="cubes" href="/data-catalog/tron/raw/blocks">
    Block information and statistics
  </Card>

  <Card title="Transactions" icon="message-arrow-up" href="/data-catalog/tron/raw/transactions">
    Transaction details
  </Card>

  <Card title="decoded" icon="file" href="/data-catalog/tron/decoded/">
    Human readable smart contract activity
  </Card>

  <Card title="Tokens" icon="database" href="/data-catalog/tron/tokens/overview">
    Data for TRC tokens
  </Card>

  <Card title="Tether" icon="coin" href="/data-catalog/tron/tether">
    Data for Tether on TRON
  </Card>
</CardGroup>


# tron.blocks
Source: https://docs.dune.com/data-catalog/tron/raw/blocks

Tron block data — block number, timestamp, witness address, and transaction count.

## Table Description

The `tron.blocks` table contains information about blocks in the Tron blockchain. A block is a collection of transactions that are hashed and added to the blockchain. Each block contains a reference to the previous block, known as the parent hash, and a timestamp. The table contains information about each block, such as the block number, the block hash, the block size, the number of transactions, and the gas used.

## Table Schema

| Column              | Type          | Description                                                                  |
| ------------------- | ------------- | ---------------------------------------------------------------------------- |
| time                | timestamp(3)  | Timestamp when this block was added to the chain                             |
| number              | bigint        | Sequential position of this block in the blockchain                          |
| gas\_limit          | decimal(38,0) | Maximum amount of energy that can be used by all transactions in this block  |
| gas\_used           | decimal(38,0) | Total amount of energy actually consumed by all transactions in this block   |
| difficulty          | bigint        | Measure of how difficult it was to produce this block                        |
| total\_difficulty   | decimal(38,0) | Total chain difficulty up to this block                                      |
| size                | bigint        | Size of this block in bytes                                                  |
| base\_fee\_per\_gas | bigint        | Minimum fee per energy unit required for transaction inclusion in this block |
| hash                | varbinary     | Unique identifier (hash) of this block                                       |
| parent\_hash        | varbinary     | Hash of the previous block in the blockchain                                 |
| miner               | varbinary     | Address of the block producer (super representative) who produced this block |
| nonce               | varbinary     | Block nonce value used in the consensus mechanism                            |
| date                | date          | The UTC date when this block was added to the chain                          |

## Table Sample

<TableSample />

## Examples

### Show the most recent blocks

```sql theme={null}
SELECT
  number,
  hash,
  size,
  gas_used
FROM
  tron.blocks
ORDER BY
  number DESC
LIMIT 10
```

### Show the number of blocks produced each day

```sql theme={null}
SELECT
  date_trunc('day', time) AS day,
  count(distinct number)
FROM
  tron.blocks
GROUP BY
  day
ORDER BY
  day DESC
```

### Show the number of transactions in each block

```sql theme={null}
SELECT
  number,
  count(*)
FROM
  tron.blocks
group by 1 

LIMIT 10
```


# tron.logs
Source: https://docs.dune.com/data-catalog/tron/raw/logs

Tron smart contract event logs — topics and data from TRC-20 transfers and protocol interactions.

## Table Description

The `tron.logs` table represents the logs generated by the Tron Virtual Machine (TVM) when a contract is executed. Logs are a way to store data on the blockchain. Logs originate from events that occur during the execution of a smart contract. A log consists of:

* topic list: a list of 0 to 4 32-byte data topics. `Topic0` is the hash of the signature of the event (indexed), and the remaining topics are indexed parameters of the event.
* data: contains non-indexed data.

While working with raw logs is possible, we recommend to work with [decoded logs](../decoded/event-logs) for a more user-friendly experience.

## Table Schema

| Column            | Type         | Description                                                                          |
| ----------------- | ------------ | ------------------------------------------------------------------------------------ |
| block\_time       | timestamp(3) | The exact UTC timestamp when the block containing this log was added to the chain    |
| block\_number     | bigint       | The sequential number of the block containing this log                               |
| block\_hash       | varbinary    | Unique identifier (hash) of the block containing this log                            |
| contract\_address | varbinary    | Address of the smart contract that emitted this log                                  |
| topic0            | varbinary    | First 32-byte topic, typically the keccak256 hash of the event signature             |
| topic1            | varbinary    | Second 32-byte topic, containing the first indexed event parameter                   |
| topic2            | varbinary    | Third 32-byte topic, containing the second indexed event parameter                   |
| topic3            | varbinary    | Fourth 32-byte topic, containing the third indexed event parameter                   |
| data              | varbinary    | ABI-encoded data containing non-indexed event parameters                             |
| tx\_hash          | varbinary    | Unique identifier (hash) of the transaction that generated this log                  |
| index             | integer      | Position of this log within the block                                                |
| tx\_index         | integer      | Position of the parent transaction within its containing block                       |
| block\_date       | date         | The UTC date of the block in which this log was included                             |
| tx\_from          | varbinary    | Address of the account that initiated the transaction containing this log            |
| tx\_to            | varbinary    | Address of the recipient account or contract for the transaction containing this log |

## Table Sample

<TableSample />

## Examples

### Filter the logs for a specific contract

```sql theme={null}
select *
from tron.logs
where contract_address = 0x06012c8cf97bead5deae237070f9587f8e7a266d
limit 10
```

### Filter the logs for a specific topic

```sql theme={null}
select *
from tron.logs
where topic0 = 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef

```

### Show the logs of a specific block

```sql theme={null}
SELECT *
FROM tron.logs
WHERE evt_block_number = 1000000
```


# tron.transactions
Source: https://docs.dune.com/data-catalog/tron/raw/transactions

Tron transaction records — sender, recipient, contract calls, fees, and execution results.

## Table Description

The `tron.transactions` table contains information about all transactions on the Tron blockchain. Each row represents a single transaction and includes information such as block number, hash, timestamp, sender, recipient, value, gas, gas price, and more.
Transactions are the fundamental unit of interaction with the Tron blockchain. Transactions are created by users and are used to send value, deploy smart contracts, and interact with smart contracts.

## Table Schema

| Column                       | Type                                                        | Description                                                                                      |
| ---------------------------- | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------ |
| block\_time                  | timestamp(3)                                                | The exact UTC timestamp when the block containing this transaction was added to the chain        |
| block\_number                | bigint                                                      | The sequential number of the block containing this transaction                                   |
| value                        | uint256                                                     | Amount of TRX sent from sender to recipient, measured in sun (1 TRX = 10^6 sun)                  |
| gas\_limit                   | bigint                                                      | Maximum number of energy units this transaction can consume                                      |
| gas\_price                   | bigint                                                      | Price per unit of energy for this transaction, denominated in sun                                |
| gas\_used                    | bigint                                                      | Actual amount of energy units consumed by this transaction's execution                           |
| max\_fee\_per\_gas           | bigint                                                      | Maximum total amount per energy unit the initiator is willing to pay                             |
| max\_priority\_fee\_per\_gas | bigint                                                      | Maximum additional fee per energy unit the initiator is willing to pay as a tip                  |
| priority\_fee\_per\_gas      | bigint                                                      | Actual additional fee per energy unit paid as a tip                                              |
| nonce                        | bigint                                                      | Sequential number representing the count of transactions sent from the sender's address          |
| index                        | bigint                                                      | Position of this transaction within its containing block                                         |
| success                      | boolean                                                     | Whether the transaction executed successfully (true) or failed (false)                           |
| from                         | varbinary                                                   | Address of the account that initiated and signed this transaction                                |
| to                           | varbinary                                                   | Address of the recipient account or contract for this transaction                                |
| block\_hash                  | varbinary                                                   | Unique identifier (hash) of the block containing this transaction                                |
| data                         | varbinary                                                   | Input data for the transaction, which may include function calls or contract interaction data    |
| hash                         | varbinary                                                   | Unique identifier (hash) of this specific transaction                                            |
| type                         | varchar                                                     | Type of transaction indicating its structure and fee mechanism                                   |
| access\_list                 | array(row(address varbinary, storagekeys array(varbinary))) | List of addresses and storage keys the transaction plans to access, used for energy optimization |
| block\_date                  | date                                                        | The UTC date of the block in which this transaction was included                                 |

## Table Sample

<TableSample />

## Examples

### Show all transactions sent by a specific address

```sql theme={null}
select * 
from tron.transactions where "from" = 0x50A1b5c358F8D34F0d35aA2f10742c46054E247e
```

### Count the number of transactions per block

```sql theme={null}
SELECT 
    block_number, 
    COUNT(*)
FROM tron.transactions
GROUP BY 1
ORDER BY 1 DESC
LIMIT 10
```

### Show the top 10 transactions with the highest gas price

```sql theme={null}
SELECT 
    hash, 
    gas_price
FROM tron.transactions
ORDER BY gas_price DESC
LIMIT 10
```


# USDT on tron
Source: https://docs.dune.com/data-catalog/tron/tether

Decoded USDT data on the Tron network.

USDT is a stablecoin pegged to the US dollar. It is issued by Tether, a company that has issued several stablecoins on different blockchains. USDT on Tron is a TRC-20 token, which means it is issued on the Tron network. USDT on Tron is the most popular stablecoin that is used in the real world. It is used by traders, investors, and businesses to transfer value across the world. On Dune, you can explore USDT on Tron data, including the number of transactions, the number of holders, and the total supply.

<Info> technically, Tether belongs to the [decoded category](/data-catalog/tron/decoded), but Tether is >90% of activity on Tron, so we decided to give it its own page </Info>

## Data Overview

The [USDT smart contract](https://tronscan.org/#/token20/TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t) on the Tron network is a TRC-20 token contract. It is used to issue and manage USDT tokens on the Tron network. The contract has several functions that allow users to transfer, issue, and manage USDT tokens. The contract also has several events that are logged when certain actions are performed. These events can be used to track the history of the contract and the USDT tokens that are issued by it.

These are the events that are logged by the USDT contract on the Tron network and their respective descriptions:

* `tether_tron.tether_usd_evt_addedblacklist`: Records events where addresses are added to the blacklist by the contract. This could imply restrictions on transactions for the addresses involved.

* `tether_tron.tether_usd_evt_approval`: Logs approval events, indicating when a user has allowed another account to withdraw a certain amount of USDT on their behalf.

* `tether_tron.tether_usd_evt_deprecate`: Captures instances where the contract has been deprecated, which might happen when a contract is upgraded or migrated.

* `tether_tron.tether_usd_evt_destroyedblackfunds`: Details events where funds from blacklisted addresses are destroyed or removed from circulation by the contract.

* `tether_tron.tether_usd_evt_issue`: Contains records of issue events, where new USDT tokens are created and issued within the ecosystem.

* `tether_tron.tether_usd_evt_ownershipttransferred`: Logs the transfer of contract ownership events, which indicates a change in who can execute administrative functions on the contract.

* `tether_tron.tether_usd_evt_params`: Stores data related to changes in the contract's operational parameters, which could include things like fees, transaction limits, or other configuration settings.

* `tether_tron.tether_usd_evt_pause`: Details when the contract has been paused, which prevents all transfers, issuances, and blacklisting until it is unpaused.

* `tether_tron.tether_usd_evt_removedblacklist`: Logs events where addresses are removed from the blacklist, usually re-enabling their ability to execute transactions.

* `tether_tron.tether_usd_evt_transfer`: Tracks transfer events between addresses, a core functionality for a token contract, logging the sender, receiver, and amount.

* `tether_tron.tether_usd_evt_unpause`: Captures the moments when the contract's pause is lifted, thereby resuming normal operations and transactions.

You can query all of these tables in the `tether_tron` schema in the Dune database.

## Example queries

### Daily transfer count of USDT on Tron.

```sql theme={null}
SELECT 
  date_trunc('day', evt_block_time) as day,
  count(*) as transfer_count
FROM tether_tron.Tether_USD_evt_transfer
where evt_block_time > now() - interval '10' day
group by 1
```

<div>
  <DuneEmbed />
</div>

### Daily transfer volume of USDT on Tron.

```sql theme={null}
SELECT 
  date_trunc('day', evt_block_time) as day,
  sum(value/1e6) as transfer_volume
FROM tether_tron.Tether_USD_evt_transfer
where evt_block_time > now() - interval '10' day
group by 1
```

<div>
  <DuneEmbed />
</div>


# Tokens
Source: https://docs.dune.com/data-catalog/tron/tokens/overview

Exploring the landscape of digital assets on the blockchain.

Tron adheres to the Ethereum Virtual Machine (EVM) standards for token creation and management. These standards define the rules and interfaces that smart contracts must follow in order to create and manage tokens on the blockchain. The most common token standards include:

* [ERC20](https://eips.ethereum.org/EIPS/eip-20)
* [ERC721](https://eips.ethereum.org/EIPS/eip-721)
* [ERC1155](https://eips.ethereum.org/EIPS/eip-1155)

ERC20 tokens are fungible, meaning that each token is identical to every other token. ERC721 tokens are non-fungible, meaning that each token is unique. ERC1155 tokens are a hybrid of the two, allowing for both fungible and non-fungible tokens to be created.

On Tron, these standards are called **TRC20**, **TRC721**, and **TRC1155**, respectively.

Additionally, there is also the native asset of the TVM, `TRX`, which is used to pay for transaction fees. TRX is not an ERC20 token, but it is still a digital asset that can be transferred and owned by users.

## Data Catalog

The following datasets are available for exploring the landscape of digital assets on the blockchain:

<CardGroup>
  <Card title="TRC20" icon="layer-group" href="/data-catalog/tron/tokens/transfers/erc20-transfers">
    All TRC20 token transfers that have occurred on the network.
  </Card>

  <Card title="TRC721" icon="layer-group" href="/data-catalog/tron/tokens/transfers/erc721-transfers">
    All TRC721 token transfers that have occurred on the network.
  </Card>

  <Card title="TRC1155" icon="layer-group" href="/data-catalog/tron/tokens/transfers/erc1155-transfers">
    All TRC1155 token transfers that have occurred on the network.
  </Card>
</CardGroup>


# TRC1155 Transfers
Source: https://docs.dune.com/data-catalog/tron/tokens/transfers/erc1155-transfers

Event logs for TRC1155 token transfers on the Tron blockchain.

## Table description

The `TRC1155 Transfers` table captures all `Transfer` event logs for TRC1155 token transfers on the Tron blockchain.
This log is emitted when a `transfer` or `TransferFrom` function is called successfully on a TRC1155 token contract.

## Table Schema

| Column             | Type         | Description                                                            |
| ------------------ | ------------ | ---------------------------------------------------------------------- |
| contract\_address  | varbinary    | Address of the TRC1155 token contract that emitted this transfer event |
| evt\_tx\_hash      | varbinary    | Hash of the transaction containing this transfer event                 |
| evt\_tx\_from      | varbinary    | Address of the account that initiated the parent transaction           |
| evt\_tx\_to        | varbinary    | Address of the recipient of the parent transaction                     |
| evt\_tx\_index     | integer      | Position of the parent transaction within its containing block         |
| evt\_index         | bigint       | Index position of this event log within the transaction                |
| evt\_block\_time   | timestamp(3) | Timestamp of the block containing this event                           |
| evt\_block\_number | bigint       | The block number containing this event                                 |
| evt\_block\_date   | date         | The UTC date of the block containing this event                        |
| from               | varbinary    | Address sending the TRC1155 tokens                                     |
| id                 | uint256      | Token type identifier for the specific TRC1155 token being transferred |
| operator           | varbinary    | Address approved to execute the transfer on behalf of the sender       |
| to                 | varbinary    | Address receiving the TRC1155 tokens                                   |
| value              | uint256      | Quantity of the specified token type transferred                       |

## Table Sample

<TableSample />


# TRC20 Transfers
Source: https://docs.dune.com/data-catalog/tron/tokens/transfers/erc20-transfers

Event logs for TRC20 token transfers on the Tron blockchain.

## Table description

The `TRC20 Transfers` table captures all `Transfer` event logs for TRC20 token transfers on the Tron blockchain.
This log is usually emitted when a `transfer` or `TransferFrom` function is called successfully on a TRC20 token contract.

## Table Schema

| Column             | Type         | Description                                                          |
| ------------------ | ------------ | -------------------------------------------------------------------- |
| contract\_address  | varbinary    | Address of the TRC20 token contract that emitted this transfer event |
| evt\_tx\_hash      | varbinary    | Hash of the transaction containing this transfer event               |
| evt\_tx\_from      | varbinary    | Address of the account that initiated the parent transaction         |
| evt\_tx\_to        | varbinary    | Address of the recipient of the parent transaction                   |
| evt\_tx\_index     | integer      | Position of the parent transaction within its containing block       |
| evt\_index         | bigint       | Index position of this event log within the transaction              |
| evt\_block\_time   | timestamp(3) | Timestamp of the block containing this event                         |
| evt\_block\_number | bigint       | The block number containing this event                               |
| evt\_block\_date   | date         | The UTC date of the block containing this event                      |
| from               | varbinary    | Address sending the TRC20 tokens                                     |
| to                 | varbinary    | Address receiving the TRC20 tokens                                   |
| value              | uint256      | Amount of TRC20 tokens transferred, in the token's smallest unit     |

## Table Sample

<TableSample />


# TRC721 Transfers
Source: https://docs.dune.com/data-catalog/tron/tokens/transfers/erc721-transfers

Event logs for TRC721 token transfers on the tron blockchain.

## Table description

The `TRC721 Transfers` table captures all `Transfer` event logs for TRC721 token transfers on the Tron blockchain.
This log is usually emitted when a `transfer` or `TransferFrom` function is called successfully on a TRC721 token contract.

## Table Schema

| Column             | Type         | Description                                                                 |
| ------------------ | ------------ | --------------------------------------------------------------------------- |
| contract\_address  | varbinary    | Address of the TRC721 (NFT) token contract that emitted this transfer event |
| evt\_tx\_hash      | varbinary    | Hash of the transaction containing this transfer event                      |
| evt\_tx\_from      | varbinary    | Address of the account that initiated the parent transaction                |
| evt\_tx\_to        | varbinary    | Address of the recipient of the parent transaction                          |
| evt\_tx\_index     | integer      | Position of the parent transaction within its containing block              |
| evt\_index         | bigint       | Index position of this event log within the transaction                     |
| evt\_block\_time   | timestamp(3) | Timestamp of the block containing this event                                |
| evt\_block\_number | bigint       | The block number containing this event                                      |
| evt\_block\_date   | date         | The UTC date of the block containing this event                             |
| from               | varbinary    | Address sending the TRC721 NFT                                              |
| to                 | varbinary    | Address receiving the TRC721 NFT                                            |
| tokenid            | uint256      | Unique identifier of the specific NFT being transferred                     |

## Table Sample

<TableSample />


# xrpl.accounts
Source: https://docs.dune.com/data-catalog/xrpl/accounts

The 'xrpl.accounts' table contains all XRPL accounts observed on the ledger, including creation/deletion history, current XRP balance, and identity labels.

## Table Description

Contains all XRPL accounts observed on the ledger, including their creation and deletion history, current XRP balance, and identity labels where available. Use this table to profile accounts, track lifecycle events, and filter activity by named entities.

## Column Descriptions

| **Column**                           | **type**  | **Description**                                                                          |
| ------------------------------------ | --------- | ---------------------------------------------------------------------------------------- |
| **account\_id**                      | bigint    | Unique surrogate primary key for the account                                             |
| **annotation\_id**                   | bigint    | Reference to a human-readable label for this account, if known (→ annotations)           |
| **account\_address**                 | string    | The account's XRPL classic address (r-address); unique and not null                      |
| **created\_ledger\_index**           | bigint    | Ledger index at which this account was first funded and activated on-chain               |
| **created\_timestamp**               | timestamp | Timestamp when the account was created on the ledger                                     |
| **created\_transaction\_hash**       | string    | Hash of the transaction that created this account                                        |
| **deleted\_ledger\_index**           | bigint    | Ledger index at which this account was deleted, if applicable (null for active accounts) |
| **deleted\_transaction\_index**      | integer   | Transaction index within the deletion ledger for ordering purposes                       |
| **deleted\_timestamp**               | timestamp | Timestamp when the account was deleted from the ledger                                   |
| **deleted\_transaction\_hash**       | string    | Hash of the transaction that deleted this account                                        |
| **last\_updated\_ledger\_index**     | bigint    | Ledger index of the most recent transaction that modified this account's state           |
| **last\_updated\_timestamp**         | timestamp | Timestamp of the most recent state change for this account                               |
| **last\_updated\_transaction\_hash** | string    | Hash of the transaction that last modified this account                                  |
| **current\_xrp\_balance**            | double    | Current XRP balance held by the account, in XRP                                          |

## Table Sample

<TableSample />


# xrpl.aggregated_metrics_daily
Source: https://docs.dune.com/data-catalog/xrpl/aggregated_metrics_daily

The 'xrpl.aggregated_metrics_daily' table contains aggregated daily metrics for XRP Ledger activity, including transaction volumes, DEX activity, and AMM statistics.

## Table Description

Aggregated daily metrics for XRP Ledger activity, including transaction volumes, DEX activity, and AMM statistics.

## Column Descriptions

| **Column**                            | **type**      | **Description**                                                                            |
| ------------------------------------- | ------------- | ------------------------------------------------------------------------------------------ |
| **date**                              | date          | The date for which the metrics are aggregated (YYYY-MM-DD).                                |
| **issuers\_count\_daily**             | integer       | Number of unique issuers of tokens on the XRP Ledger for the given day.                    |
| **tokens\_count\_daily**              | integer       | Number of unique tokens (currency.issuer) on the XRP Ledger for the given day.             |
| **xrp\_txn\_volume\_xrp**             | decimal(38,6) | Total volume of all transactions involving XRP, denominated in XRP.                        |
| **xrp\_payment\_volume\_xrp**         | decimal(38,6) | Total volume of single-currency (XRP-only) payments, denominated in XRP.                   |
| **dex\_traded\_tokens\_count\_daily** | integer       | Number of unique tokens (currency.issuer) traded on the DEX.                               |
| **dex\_traders\_count\_daily**        | integer       | Number of unique addresses that executed trades on the DEX.                                |
| **dex\_pairs\_count\_daily**          | integer       | Number of unique trading pairs on the DEX.                                                 |
| **dex\_xrp\_pairs\_count\_daily**     | integer       | Number of unique trading pairs on the DEX that include XRP as one of the assets.           |
| **dex\_xrp\_pair\_volume\_xrp**       | decimal(38,6) | Total trading volume on the DEX for pairs involving XRP, denominated in XRP.               |
| **amm\_pools\_count\_daily**          | integer       | Number of distinct AMM pools.                                                              |
| **amm\_xrp\_pools\_count\_daily**     | integer       | Number of distinct AMM pools where at least one asset is XRP.                              |
| **amm\_tvl\_xrp**                     | decimal(38,6) | Total Value Locked (TVL) in all AMM pools, denominated in XRP.                             |
| **amm\_users\_count\_daily**          | integer       | Number of unique addresses that interacted with AMMs (e.g., swaps, deposits, withdrawals). |
| **amm\_xrp\_volume\_xrp**             | decimal(38,6) | Total trading volume through AMMs involving XRP, denominated in XRP.                       |

## Table Sample

<TableSample />


# xrpl.amm_events
Source: https://docs.dune.com/data-catalog/xrpl/amm_events

The 'xrpl.amm_events' table is a unified view of all activity in XRP Ledger AMM liquidity pools, combining deposits, withdrawals, fee-setting votes, and auction-slot bids.

## Table Description

A unified view of all activity in XRP Ledger AMM liquidity pools, combining deposits, withdrawals, fee-setting votes, and auction-slot bids in a single table for cross-event analytics. Each row represents one AMM event with the event category identified by event\_type; columns specific to a particular event kind are null for rows of other types. Covers all AMM events recorded on the XRPL mainnet since the AMM amendment was activated.

## Column Descriptions

| **Column**                               | **type**  | **Description**                                                                                                                                              |
| ---------------------------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **pool\_id**                             | bigint    | Surrogate key identifying the AMM liquidity pool in which this event occurred.                                                                               |
| **pool\_address**                        | string    | On-ledger XRP Ledger account address of the AMM pool (the pool's own account), provided for direct lookup on explorers.                                      |
| **transaction\_id**                      | bigint    | Internal surrogate key for the on-ledger transaction that triggered this event.                                                                              |
| **transaction\_hash**                    | string    | Cryptographic hash of the XRP Ledger transaction that triggered this event, usable for direct ledger lookup.                                                 |
| **account\_id**                          | bigint    | Internal surrogate key for the account that submitted the transaction.                                                                                       |
| **account\_address**                     | string    | XRP Ledger account address of the wallet that submitted the transaction.                                                                                     |
| **transaction\_type**                    | string    | XRPL transaction type (e.g. AMMDeposit, AMMWithdraw, AMMBid, AMMVote) as recorded on the ledger.                                                             |
| **event\_type**                          | string    | Business category of this AMM event: Deposit or Withdraw for liquidity changes, AMMBid for auction-slot bids, AMMVote for fee-setting votes.                 |
| **timestamp**                            | timestamp | UTC timestamp of the ledger close in which this event was confirmed.                                                                                         |
| **date**                                 | date      | Calendar date (UTC) of the ledger close, used for daily partitioning and time-series analysis.                                                               |
| **event\_id**                            | varchar   | Unique identifier for liquidity events (Deposit or Withdraw); null for bids and votes.                                                                       |
| **token\_a\_amount**                     | double    | Amount of Token A deposited or withdrawn in this liquidity event; null for bids and votes.                                                                   |
| **token\_b\_amount**                     | double    | Amount of Token B deposited or withdrawn in this liquidity event; null for bids and votes.                                                                   |
| **lp\_token\_amount**                    | double    | Amount of LP tokens minted (Deposit), burned (Withdraw), or bid in an auction-slot contest (AMMBid); null for votes.                                         |
| **token\_a\_amount\_before**             | double    | Pool balance of Token A immediately before this liquidity event; null for bids and votes.                                                                    |
| **token\_a\_amount\_after**              | double    | Pool balance of Token A immediately after this liquidity event; null for bids and votes.                                                                     |
| **token\_b\_amount\_before**             | double    | Pool balance of Token B immediately before this liquidity event; null for bids and votes.                                                                    |
| **token\_b\_amount\_after**              | double    | Pool balance of Token B immediately after this liquidity event; null for bids and votes.                                                                     |
| **lp\_token\_amount\_before**            | double    | Total LP token supply outstanding immediately before this event; null for votes.                                                                             |
| **lp\_token\_amount\_after**             | double    | Total LP token supply outstanding immediately after this liquidity event; null for bids and votes.                                                           |
| **bid\_id**                              | bigint    | Surrogate key for the auction-slot bid record; populated only for AMMBid events, null otherwise.                                                             |
| **is\_winning\_bid**                     | boolean   | True if this bid successfully claimed the AMM auction slot; populated only for AMMBid events.                                                                |
| **slot\_duration**                       | integer   | Duration in seconds that the bidder holds the auction slot after winning, capped at 86,400 (24 hours); populated only for AMMBid events.                     |
| **replaced\_by\_bid\_id**                | bigint    | Surrogate key of the subsequent bid that displaced this auction slot; populated only for AMMBid events.                                                      |
| **replaced\_by\_bid\_transaction\_hash** | string    | Transaction hash of the bid that replaced this auction slot, enabling chain-of-custody tracing; populated only for AMMBid events.                            |
| **vote\_id**                             | bigint    | Surrogate key for the fee-vote record; populated only for AMMVote events, null otherwise.                                                                    |
| **vote\_trading\_fee**                   | integer   | Trading fee requested by the voting liquidity provider, in units of 1/100,000 (e.g. 1000 = 1%); populated only for AMMVote events.                           |
| **final\_trading\_fee**                  | integer   | Effective pool trading fee in units of 1/100,000 after incorporating this vote's LP-weighted influence; populated only for AMMVote events.                   |
| **auction\_slot**                        | string    | JSON snapshot of the pool's auction-slot state at the time of this vote, showing the current slot holder and expiry time; populated only for AMMVote events. |

## Table Sample

<TableSample />


# xrpl.amm_pools
Source: https://docs.dune.com/data-catalog/xrpl/amm_pools

The 'xrpl.amm_pools' table contains all Automated Market Maker (AMM) liquidity pools on the XRP Ledger, one row per pool.

## Table Description

Contains all Automated Market Maker (AMM) liquidity pools on the XRP Ledger, one row per pool. Each pool pairs two assets and issues LP tokens to liquidity providers in return for their deposit. Use this table to analyze pool composition, trading fees, liquidity depth, and pool lifecycle events.

## Column Descriptions

| **Column**                       | **type**  | **Description**                                                                                                                                                                             |
| -------------------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **pool\_id**                     | bigint    | Unique surrogate primary key for the AMM pool record                                                                                                                                        |
| **amm\_account\_id**             | bigint    | The on-ledger account that represents this AMM pool (→ accounts)                                                                                                                            |
| **amm\_account\_address**        | string    | XRPL address of the AMM pool's on-ledger account                                                                                                                                            |
| **token\_a\_id**                 | bigint    | Surrogate key for the first asset in the pool (→ tokens)                                                                                                                                    |
| **token\_a\_currency**           | string    | Currency code of the first pool asset (e.g. XRP, USD, or a hex-encoded custom code)                                                                                                         |
| **token\_a\_issuer\_address**    | string    | XRPL address of the account that issued the first pool asset; null if the asset is XRP                                                                                                      |
| **token\_a\_pool\_balance**      | double    | Current reserve of the first asset held in the pool; shifts with each swap                                                                                                                  |
| **token\_b\_id**                 | bigint    | Surrogate key for the second asset in the pool (→ tokens)                                                                                                                                   |
| **token\_b\_currency**           | string    | Currency code of the second pool asset (e.g. XRP, USD, or a hex-encoded custom code)                                                                                                        |
| **token\_b\_issuer\_address**    | string    | XRPL address of the account that issued the second pool asset; null if the asset is XRP                                                                                                     |
| **token\_b\_pool\_balance**      | double    | Current reserve of the second asset held in the pool; shifts with each swap                                                                                                                 |
| **lp\_token\_id**                | bigint    | Surrogate key for the LP token issued to liquidity providers in exchange for their deposit (→ tokens)                                                                                       |
| **lp\_token\_currency**          | string    | Currency code of the LP token representing a proportional share of this pool                                                                                                                |
| **lp\_token\_balance**           | varchar   | Total outstanding LP token supply across all liquidity providers, stored as a string to preserve XRPL IOU precision; cast to a numeric type for arithmetic. Decreases as providers withdraw |
| **trading\_fee**                 | double    | Percentage fee charged on each swap through this pool; collected and shared among liquidity providers                                                                                       |
| **created\_ledger\_index**       | bigint    | Ledger index at which this AMM pool was created                                                                                                                                             |
| **created\_timestamp**           | timestamp | Timestamp when this AMM pool was created                                                                                                                                                    |
| **last\_updated\_ledger\_index** | bigint    | Ledger index of the most recent swap, deposit, or withdrawal that changed this pool's state                                                                                                 |
| **last\_updated\_timestamp**     | timestamp | Timestamp of the most recent change to this pool's state                                                                                                                                    |
| **current\_xrp\_balance**        | double    | Current XRP balance of the AMM pool account, if one of the paired assets is XRP                                                                                                             |
| **is\_deleted**                  | boolean   | Whether this pool has been dissolved and is no longer active on the ledger                                                                                                                  |
| **deleted\_timestamp**           | timestamp | Timestamp when this pool was dissolved; null if still active                                                                                                                                |

## Table Sample

<TableSample />


# xrpl.annotations
Source: https://docs.dune.com/data-catalog/xrpl/annotations

The 'xrpl.annotations' table is a lookup of labeled addresses providing human-readable names for known XRPL wallets, exchanges, and entities.

## Table Description

A lookup table of labeled addresses providing human-readable names for known XRPL wallets, exchanges, and entities. Used to enrich account and transaction data with contextual identity information. Referenced by accounts to annotate well-known addresses.

## Column Descriptions

| **Column**         | **type** | **Description**                                                         |
| ------------------ | -------- | ----------------------------------------------------------------------- |
| **annotation\_id** | bigint   | Unique surrogate primary key for the annotation record                  |
| **source**         | string   | Origin of the annotation (e.g. third-party data provider)               |
| **name**           | string   | Human-readable label for the address (e.g., exchange name, institution) |
| **address**        | string   | The XRPL account address this annotation describes                      |

## Table Sample

<TableSample />


# xrpl.dex_ohlcv_daily
Source: https://docs.dune.com/data-catalog/xrpl/dex_ohlcv_daily

The 'xrpl.dex_ohlcv_daily' table contains daily OHLCV price data for all trading pairs on the XRP Ledger DEX, combining CLOB and AMM activity.

## Table Description

Daily OHLCV (open, high, low, close, volume) price data for all trading pairs on the XRP Ledger decentralized exchange (DEX), combining both the central limit order book (CLOB) and automated market maker (AMM) pools. Each row represents one trading pair per calendar day, with all prices expressed as counter token units per one unit of base token. Pair direction is normalized for consistency so the same pair always appears with the same base/counter assignment regardless of which side initiated the trade. Use this table for price charting, liquidity analysis, and DEX volume reporting.

## Column Descriptions

| **Column**                   | **type** | **Description**                                                                                                        |
| ---------------------------- | -------- | ---------------------------------------------------------------------------------------------------------------------- |
| **ledger\_close\_date**      | date     | Calendar date of the trading day; all trades for this pair on this date are aggregated into one row                    |
| **base\_token\_id**          | bigint   | Surrogate key for the base token in the trading pair (→ tokens)                                                        |
| **base\_token\_currency**    | string   | Currency code of the base token; 'XRP' for native XRP                                                                  |
| **base\_token\_issuer**      | string   | XRPL address of the base token issuer; null for native XRP                                                             |
| **counter\_token\_id**       | bigint   | Surrogate key for the counter (quote) token in the trading pair (→ tokens)                                             |
| **counter\_token\_currency** | string   | Currency code of the counter token; 'XRP' for native XRP                                                               |
| **counter\_token\_issuer**   | string   | XRPL address of the counter token issuer; null for native XRP                                                          |
| **open\_price**              | double   | Price of the first trade of the day, expressed as counter token units per one base token                               |
| **high\_price**              | double   | Highest trade price recorded during the day, expressed as counter token units per one base token                       |
| **low\_price**               | double   | Lowest trade price recorded during the day, expressed as counter token units per one base token                        |
| **close\_price**             | double   | Price of the last trade of the day, expressed as counter token units per one base token                                |
| **vwap\_price**              | double   | Volume-weighted average price for the day, calculated as the sum of (price × base amount) divided by total base volume |
| **volume**                   | double   | Total base token amount traded across all CLOB and AMM activity on this day                                            |
| **clob\_trade\_count**       | bigint   | Number of order-book trades (OfferCreate and Payment transactions) included in this day's aggregation                  |
| **amm\_swap\_count**         | bigint   | Number of automated market maker (AMM) pool swaps included in this day's aggregation                                   |
| **total\_dex\_tx\_count**    | bigint   | Total number of DEX transactions for this pair on this day, combining CLOB trades and AMM swaps                        |

## Table Sample

<TableSample />


# xrpl.dex_swaps
Source: https://docs.dune.com/data-catalog/xrpl/dex_swaps

The 'xrpl.dex_swaps' table is a unified view of all token exchanges on the XRP Ledger DEX, combining AMM pool swaps and order-book offer executions.

## Table Description

A unified view of all token exchanges on the XRP Ledger DEX, combining AMM pool swaps and order-book offer executions into a single table for cross-venue trade analytics. Each row represents one trade execution, with the execution venue identified by fulfilled\_by (AMM for pool swaps, OfferCreate or Payment for order-book fills). Token amounts are expressed in human-readable units (XRP in XRP, issued currencies in their native denomination). Columns specific to a venue are null for rows from the other venue.

## Column Descriptions

| **Column**                               | **type**  | **Description**                                                                                                                        |
| ---------------------------------------- | --------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| **offer\_id**                            | bigint    | Surrogate key for the order-book offer execution record; null for AMM swaps.                                                           |
| **swap\_id**                             | bigint    | Surrogate key for the AMM pool swap record; null for order-book trades.                                                                |
| **pool\_id**                             | bigint    | Surrogate key for the AMM pool that fulfilled the swap; null for order-book trades.                                                    |
| **pool\_address**                        | string    | On-ledger account address of the AMM pool that executed the swap; null for order-book trades.                                          |
| **transaction\_id**                      | bigint    | Internal surrogate key for the on-ledger transaction that triggered this trade.                                                        |
| **transaction\_hash**                    | string    | Cryptographic hash of the XRP Ledger transaction, usable for direct ledger lookup.                                                     |
| **node\_index**                          | integer   | Position of this trade within the transaction's AffectedNodes list, distinguishing multiple fills in a single transaction.             |
| **transaction\_type**                    | string    | XRPL transaction type that generated this trade (e.g. OfferCreate, Payment, AMMSwap).                                                  |
| **transaction\_result**                  | string    | XRPL engine result code for the transaction (e.g. tesSUCCESS); only successful trades are included in this view.                       |
| **memo**                                 | string    | Decoded MemoData from the first memo attached to the transaction, often used by apps to tag orders with routing or platform metadata.  |
| **transaction\_fee**                     | varchar   | Network fee paid by the submitter for this transaction, denominated in XRP. Stored as a string; cast to a numeric type for arithmetic. |
| **account\_id**                          | bigint    | Internal surrogate key for the wallet that submitted the transaction.                                                                  |
| **account\_address**                     | string    | XRP Ledger account address of the wallet that submitted the transaction.                                                               |
| **destination\_id**                      | bigint    | Internal surrogate key for the destination account specified in the transaction, if any; typically the recipient in a Payment.         |
| **destination\_address**                 | string    | XRP Ledger account address of the transaction destination (e.g. payment recipient); null if no destination was specified.              |
| **base\_token\_id**                      | bigint    | Surrogate key of the base token in the trading pair; the base token is the one whose currency code comes first alphabetically.         |
| **base\_token**                          | string    | Human-readable currency code of the base token (e.g. XRP, USD, BTC).                                                                   |
| **base\_token\_issuer**                  | string    | XRP Ledger account address of the entity that issued the base token; null for XRP, which has no issuer.                                |
| **counter\_token\_id**                   | bigint    | Surrogate key of the counter (quote) token in the trading pair.                                                                        |
| **counter\_token**                       | string    | Human-readable currency code of the counter token (e.g. XRP, USD, EUR).                                                                |
| **counter\_token\_issuer**               | string    | XRP Ledger account address of the entity that issued the counter token; null for XRP.                                                  |
| **base\_token\_amount**                  | double    | Amount of the base token exchanged in this trade, in human-readable units (XRP in XRP, not drops).                                     |
| **counter\_token\_amount**               | double    | Amount of the counter token exchanged in this trade, in human-readable units.                                                          |
| **price**                                | double    | Trade price expressed as counter\_token\_amount divided by base\_token\_amount.                                                        |
| **base\_receiver\_id**                   | bigint    | Internal surrogate key of the account that received the base token in this trade.                                                      |
| **base\_receiver**                       | string    | XRP Ledger address of the account that received the base token in this trade.                                                          |
| **counter\_receiver\_id**                | bigint    | Internal surrogate key of the account that received the counter token in this trade.                                                   |
| **counter\_receiver**                    | string    | XRP Ledger address of the account that received the counter token in this trade.                                                       |
| **fulfilled\_by**                        | string    | Execution venue: AMM for AMM pool swaps, or the triggering transaction type (OfferCreate or Payment) for order-book fills.             |
| **amm\_base\_token\_balance\_before**    | double    | AMM pool balance of the base token immediately before this swap; null for order-book trades.                                           |
| **amm\_base\_token\_balance\_after**     | double    | AMM pool balance of the base token immediately after this swap; null for order-book trades.                                            |
| **amm\_base\_token\_balance\_delta**     | double    | Change in the AMM pool's base token balance from this swap; negative when the pool sold base token, null for order-book trades.        |
| **amm\_counter\_token\_balance\_before** | double    | AMM pool balance of the counter token immediately before this swap; null for order-book trades.                                        |
| **amm\_counter\_token\_balance\_after**  | double    | AMM pool balance of the counter token immediately after this swap; null for order-book trades.                                         |
| **amm\_counter\_token\_balance\_delta**  | double    | Change in the AMM pool's counter token balance from this swap; negative when the pool sold counter token, null for order-book trades.  |
| **timestamp**                            | timestamp | UTC timestamp of the ledger close in which this trade was confirmed.                                                                   |
| **date**                                 | date      | Calendar date (UTC) of the ledger close, used for daily partitioning and time-series analysis.                                         |

## Table Sample

<TableSample />


# xrpl.ledger
Source: https://docs.dune.com/data-catalog/xrpl/ledger

XRP Ledger data — ledger index, close time, transaction count, and fees.

## Table Description

The `xrpl.ledger` table contains core ledger data from the XRP Ledger including ledger headers, consensus information, and validation details.

## Column Descriptions

| **Column**                  | **type**  | **Description**                                     |
| --------------------------- | --------- | --------------------------------------------------- |
| **ledger\_hash**            | string    | Unique hash identifier for the ledger               |
| **ledger\_index**           | bigint    | Sequential index number of the ledger               |
| **validated**               | boolean   | Whether the ledger has been validated by consensus  |
| **account\_hash**           | string    | Hash of the account state tree                      |
| **close\_flags**            | bigint    | Flags indicating how the ledger was closed          |
| **close\_time**             | bigint    | Unix timestamp when the ledger was closed           |
| **close\_time\_human**      | string    | Human-readable timestamp when the ledger was closed |
| **close\_time\_resolution** | bigint    | Resolution of the close time in seconds             |
| **close\_time\_iso**        | string    | ISO 8601 formatted close time                       |
| **parent\_close\_time**     | bigint    | Close time of the parent ledger                     |
| **parent\_hash**            | string    | Hash of the parent ledger                           |
| **total\_coins**            | string    | Total XRP supply in the ledger                      |
| **transaction\_hash**       | string    | Hash of the transaction tree                        |
| **closed**                  | boolean   | Whether the ledger is closed                        |
| **transaction\_count**      | bigint    | Number of transactions included in this ledger      |
| **event\_created\_at**      | timestamp | Timestamp when the ledger event was created         |
| **ledger\_close\_date**     | date      | Date when the ledger was closed                     |
| **\_inserted\_at**          | timestamp | Record insertion timestamp                          |
| **\_ingested\_at**          | timestamp | Data ingestion timestamp                            |

## Table Sample

<TableSample />


# XRPL Data
Source: https://docs.dune.com/data-catalog/xrpl/overview

XRP Ledger data on Dune

## What is XRPL?

The XRP Ledger (XRPL) is a decentralized, open-source blockchain technology that enables fast, energy-efficient, and reliable digital asset transfers. Developed by Ripple, XRPL is designed to be a sustainable blockchain for payments and financial services, capable of processing 1,500 transactions per second with settlement times of 3-5 seconds.

XRPL operates on a unique consensus protocol that doesn't require mining, making it significantly more energy-efficient than proof-of-work blockchains. The network is maintained by a global community of validators who work together to validate transactions and maintain the integrity of the ledger. This consensus mechanism ensures fast finality while maintaining decentralization and security.

## Key Concepts of XRPL

XRPL's infrastructure is built on several key components that ensure its efficiency, security, and scalability for financial applications. These components work together to provide a robust platform for payments, tokenization, and decentralized finance.

### **Consensus Protocol**

XRPL uses a unique consensus mechanism called the XRP Ledger Consensus Protocol, which doesn't rely on mining or proof-of-work. Instead, validators work together to agree on the order and validity of transactions. This approach provides fast finality (3-5 seconds), high throughput (1,500 TPS), and energy efficiency while maintaining decentralization.

### **Built-in Decentralized Exchange (DEX)**

XRPL includes a native decentralized exchange that allows users to trade any issued tokens directly on the ledger without requiring smart contracts. This built-in DEX supports limit orders, offers, and automatic market making, enabling efficient token trading and liquidity provision.

### **Tokenization and Issued Currencies**

XRPL supports the creation of custom tokens (called "issued currencies" or "IOUs") by any account. These tokens can represent fiat currencies, cryptocurrencies, or any other asset. Each token is identified by a currency code and issuer, allowing for flexible tokenization of real-world assets.

### **Multi-Signing and Security**

XRPL provides advanced security features including multi-signing capabilities, allowing accounts to require multiple signatures for transactions. This feature is essential for institutional use cases and provides enhanced security for high-value transactions.

### **Escrow and Time-Delayed Payments**

XRPL includes built-in escrow functionality that allows for time-delayed payments and conditional transactions. This feature enables complex financial instruments like time-locked payments, conditional releases, and automated financial agreements.

### **Payment Channels**

XRPL supports payment channels for high-frequency, low-latency payments. Payment channels allow parties to conduct numerous off-ledger payments that can be settled on the ledger later, reducing transaction costs and improving performance for micro-payments.

### **Transaction Types and Use Cases**

XRPL supports various transaction types including:

* **Payment**: Transfer XRP or issued currencies between accounts
* **OfferCreate/OfferCancel**: Create or cancel trading offers on the DEX
* **TrustSet**: Establish trust lines for issued currencies
* **AccountSet**: Configure account settings and flags
* **EscrowCreate/EscrowFinish/EscrowCancel**: Manage escrow transactions
* **PaymentChannelCreate/PaymentChannelFund/PaymentChannelClaim**: Manage payment channels

<CardGroup>
  <Card title="XRP Ledger documentation" icon="link" href="https://xrpl.org/docs">
    Explore comprehensive documentation on XRP Ledger, detailing its architecture, protocol, and resources for developers.
  </Card>
</CardGroup>

## XRPL Data on Dune

XRP Ledger data is organized into tables that capture account lifecycle data, transactions, payments, token issuance, AMM liquidity, DEX trading, ledger metadata, and daily network metrics. These tables provide comprehensive insights into network activity, trading patterns, and ecosystem health.

<CardGroup>
  <Card title="Transactions" icon="arrow-right-arrow-left" href="/data-catalog/xrpl/transactions">
    Detailed transaction data including payment types, account changes, and transaction metadata. Contains all transaction types from payments to DEX trades and account modifications.
  </Card>

  <Card title="Transactions Base" icon="list" href="/data-catalog/xrpl/transactions_base">
    Every validated XRPL transaction with transaction type, result, fee, ledger position, sender, destination, and core metadata.
  </Card>

  <Card title="Transfers" icon="right-left" href="/data-catalog/xrpl/transfers">
    Successful direct same-asset Payment transactions, including sender, recipient, delivered amount, and partial-payment fields.
  </Card>

  <Card title="Accounts" icon="wallet" href="/data-catalog/xrpl/accounts">
    XRPL accounts observed on the ledger, including creation and deletion history, current XRP balance, and known entity labels.
  </Card>

  <Card title="Ledger" icon="cube" href="/data-catalog/xrpl/ledger">
    Core ledger data including ledger headers, consensus information, and validation details. Provides insights into network consensus and ledger-level statistics.
  </Card>

  <Card title="Tokens" icon="coins" href="/data-catalog/xrpl/tokens">
    Fungible IOUs and Multi-Purpose Tokens issued on XRPL, with issuer details, supply, holder counts, and lifecycle metadata.
  </Card>

  <Card title="Token Holders Daily" icon="users" href="/data-catalog/xrpl/token_holders_daily">
    Daily token holder snapshots with total supply, issued supply, holder counts, and concentration metrics.
  </Card>

  <Card title="DEX Swaps" icon="repeat" href="/data-catalog/xrpl/dex_swaps">
    Unified XRPL DEX trade executions across AMM pool swaps and order-book offer fills.
  </Card>

  <Card title="DEX OHLCV Daily" icon="chart-candlestick" href="/data-catalog/xrpl/dex_ohlcv_daily">
    Daily open, high, low, close, volume, and trade-count metrics for XRPL DEX pairs.
  </Card>

  <Card title="AMM Pools" icon="water" href="/data-catalog/xrpl/amm_pools">
    XRPL AMM liquidity pools with pool composition, reserves, LP token supply, fees, and lifecycle metadata.
  </Card>

  <Card title="AMM Events" icon="arrows-spin" href="/data-catalog/xrpl/amm_events">
    AMM deposits, withdrawals, auction-slot bids, and fee-setting votes in one event table.
  </Card>

  <Card title="Annotations" icon="tag" href="/data-catalog/xrpl/annotations">
    Labeled XRPL addresses for known wallets, exchanges, and entities.
  </Card>

  <Card title="Aggregated Metrics Daily" icon="chart-line" href="/data-catalog/xrpl/aggregated_metrics_daily">
    Daily aggregated metrics and statistics for network activity and performance. Includes token issuance, trading volume, DEX activity, and AMM metrics.
  </Card>
</CardGroup>


# xrpl.token_holders_daily
Source: https://docs.dune.com/data-catalog/xrpl/token_holders_daily

The 'xrpl.token_holders_daily' table is a daily snapshot of token holder metrics for all IOU and MPT tokens on the XRP Ledger.

## Table Description

Daily snapshot of token holder metrics for all IOU and MPT tokens on the XRP Ledger, including AMM LP tokens (which are a type of IOU). Each row represents one token and captures holder count, supply distribution, and concentration metrics as of the current date.

## Column Descriptions

| **Column**                    | **type** | **Description**                                                                                                                             |
| ----------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| **ledger\_close\_date**       | date     | Date of the most recent ledger state available in the data, derived from the latest trustline timestamp; may lag the current calendar date  |
| **token\_id**                 | bigint   | Surrogate key for the token (→ tokens)                                                                                                      |
| **token\_currency**           | string   | Raw currency code of the token as stored on the ledger                                                                                      |
| **token\_issuer**             | string   | XRPL address of the account that issued this token                                                                                          |
| **token\_mpt\_id**            | string   | Unique issuance identifier for Multi-Purpose Tokens (MPTs); null for traditional IOU trust-line tokens                                      |
| **total\_supply**             | double   | Total outstanding supply of the token as reported by the issuer's ledger state                                                              |
| **total\_issued**             | double   | Sum of all positive holder balances at this snapshot date; may differ from total\_supply if supply has been burned or not fully distributed |
| **total\_holders**            | bigint   | Number of distinct accounts holding a non-zero balance of this token                                                                        |
| **top\_10\_holders\_percent** | double   | Percentage of total supply held by the 10 largest holders; a measure of concentration risk                                                  |
| **whale\_accounts\_count**    | bigint   | Number of accounts each holding more than 1% of the total outstanding supply                                                                |

## Table Sample

<TableSample />


# xrpl.tokens
Source: https://docs.dune.com/data-catalog/xrpl/tokens

The 'xrpl.tokens' table contains all fungible tokens (IOUs) and Multi-Purpose Tokens (MPTs) issued on the XRP Ledger, one row per token.

## Table Description

Represents all fungible tokens (IOUs) and Multi-Purpose Tokens (MPTs) issued on the XRP Ledger, one row per token. Tracks token supply, holder counts, compliance flags, and lifecycle metadata for token analytics, issuer monitoring, and market analysis. Links to accounts for issuer identity.

## Column Descriptions

| **Column**                     | **type**  | **Description**                                                                                                       |
| ------------------------------ | --------- | --------------------------------------------------------------------------------------------------------------------- |
| **token\_id**                  | bigint    | Unique surrogate primary key for the token record                                                                     |
| **currency**                   | string    | Raw currency code as stored on the ledger                                                                             |
| **currency\_iso**              | string    | ISO 4217 currency code representation, if applicable (e.g., USD, EUR)                                                 |
| **currency\_hex**              | string    | Hexadecimal representation of the currency code                                                                       |
| **currency\_ascii**            | string    | Human-readable ASCII representation of the currency code                                                              |
| **issuer**                     | bigint    | Surrogate key for the account that issued this token (→ accounts)                                                     |
| **issuer\_address**            | string    | XRPL address of the token issuer                                                                                      |
| **is\_active**                 | boolean   | Whether the token currently has active supply or trust lines on the ledger                                            |
| **is\_blackholed**             | boolean   | Whether the issuing account's keys have been disabled, making the supply immutable (a trust signal for token holders) |
| **created\_transaction\_hash** | string    | Hash of the transaction that first created this token                                                                 |
| **created\_ledger\_index**     | bigint    | Ledger index when the token was first issued                                                                          |
| **created\_timestamp**         | timestamp | Timestamp when the token was first issued                                                                             |
| **last\_seen\_timestamp**      | timestamp | Timestamp of the most recent ledger activity involving this token                                                     |
| **total\_outstanding\_supply** | double    | Total circulating supply of this token across all trust lines or MPT holdings                                         |
| **has\_positive\_supply**      | boolean   | Flag indicating whether total outstanding supply is greater than zero                                                 |
| **holders\_count**             | bigint    | Number of accounts currently holding a non-zero balance of this token                                                 |
| **trustline\_count**           | bigint    | Number of open trust lines established for this token (IOU tokens only)                                               |
| **is\_mpt**                    | boolean   | Whether this token is a Multi-Purpose Token (MPT) rather than a traditional IOU trust-line token                      |
| **mpt\_issuance\_id**          | string    | Unique issuance identifier for MPT tokens on the ledger                                                               |
| **mptoken\_count**             | bigint    | Number of MPToken objects held by accounts for this MPT issuance                                                      |
| **maximum\_value\_mpt**        | bigint    | Maximum supply cap defined at issuance for MPT tokens                                                                 |
| **mpt\_metadata**              | string    | Arbitrary metadata attached to the MPT issuance at creation                                                           |
| **transfer\_fee**              | double    | Fee charged on peer-to-peer transfers of this token, expressed as a percentage                                        |
| **clawback\_enabled**          | boolean   | Whether the issuer has enabled the ability to reclaim tokens from holder accounts                                     |
| **burnable**                   | boolean   | Whether token holders or the issuer can permanently destroy (burn) tokens                                             |
| **token\_script**              | string    | On-chain script or logic associated with the token, if applicable                                                     |

## Table Sample

<TableSample />


# xrpl.transactions
Source: https://docs.dune.com/data-catalog/xrpl/transactions

XRP Ledger transactions — payments, offers, trust sets, and other transaction types.

## Table Description

The `xrpl.transactions` table contains all transaction data from the XRP Ledger including payment types, account changes, and transaction metadata.

## Column Descriptions

| **Column**                       | **type**                                                                                                 | **Description**                                                      |
| -------------------------------- | -------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- |
| **account**                      | string                                                                                                   | The account that initiated the transaction                           |
| **account\_txn\_id**             | string                                                                                                   | Unique identifier for the transaction from the account's perspective |
| **amount**                       | struct(currency: string, issuer: string, value: string)                                                  | The amount being transferred (for payment transactions)              |
| **amount2**                      | struct(currency: string, issuer: string, value: string)                                                  | Secondary amount field for complex transactions                      |
| **asset**                        | struct(currency: string, issuer: string)                                                                 | Asset information for token-related transactions                     |
| **asset2**                       | struct(currency: string, issuer: string)                                                                 | Secondary asset information                                          |
| **asset\_class**                 | string                                                                                                   | Classification of the asset being traded                             |
| **auth\_accounts**               | array(struct(authaccount: struct(account: string)))                                                      | Accounts authorized for this transaction                             |
| **authorize**                    | string                                                                                                   | Account to be authorized                                             |
| **balance**                      | struct(currency: string, value: string)                                                                  | Balance information                                                  |
| **bid\_max**                     | struct(currency: string, issuer: string, value: string)                                                  | Maximum bid amount for auction transactions                          |
| **bid\_min**                     | struct(currency: string, issuer: string, value: string)                                                  | Minimum bid amount for auction transactions                          |
| **cancel\_after**                | long                                                                                                     | Timestamp after which the transaction should be cancelled            |
| **channel**                      | string                                                                                                   | Payment channel identifier                                           |
| **check\_id**                    | string                                                                                                   | Unique identifier for a check                                        |
| **clear\_flag**                  | long                                                                                                     | Flag to be cleared from the account                                  |
| **condition**                    | string                                                                                                   | Condition for conditional transactions                               |
| **deliver\_max**                 | struct(currency: string, issuer: string, value: string)                                                  | Maximum amount to deliver in a payment                               |
| **deliver\_min**                 | struct(currency: string, issuer: string, value: string)                                                  | Minimum amount to deliver in a payment                               |
| **destination**                  | string                                                                                                   | Destination account for the transaction                              |
| **destination\_tag**             | long                                                                                                     | Tag for the destination account                                      |
| **domain**                       | string                                                                                                   | Domain associated with the account                                   |
| **email\_hash**                  | string                                                                                                   | Hash of the email address                                            |
| **expiration**                   | long                                                                                                     | Expiration timestamp for the transaction                             |
| **fee**                          | string                                                                                                   | Transaction fee in drops                                             |
| **finish\_after**                | long                                                                                                     | Timestamp after which the transaction should be finished             |
| **flags**                        | long                                                                                                     | Transaction flags                                                    |
| **fulfillment**                  | string                                                                                                   | Fulfillment condition for conditional transactions                   |
| **invoice\_id**                  | string                                                                                                   | Invoice identifier                                                   |
| **issuer**                       | string                                                                                                   | Issuer of the token                                                  |
| **lp\_token\_in**                | struct(currency: string, issuer: string, value: string)                                                  | Liquidity pool token input amount                                    |
| **lp\_token\_out**               | struct(currency: string, value: string)                                                                  | Liquidity pool token output amount                                   |
| **last\_ledger\_sequence**       | long                                                                                                     | Last ledger sequence number                                          |
| **last\_update\_time**           | long                                                                                                     | Last update timestamp                                                |
| **ledger\_sequence**             | long                                                                                                     | Ledger sequence number                                               |
| **limit\_amount**                | struct(currency: string, issuer: string, value: string)                                                  | Limit amount for trust lines                                         |
| **memos**                        | array(struct(Memo: struct(MemoData: string, MemoFormat: string, MemoType: string)))                      | Transaction memos                                                    |
| **metadata**                     | string                                                                                                   | Transaction metadata in JSON format                                  |
| **nf\_token\_broker\_fee**       | struct(currency: string, issuer: string, value: string)                                                  | NFT broker fee                                                       |
| **nf\_token\_buy\_offer**        | string                                                                                                   | NFT buy offer identifier                                             |
| **nf\_token\_id**                | string                                                                                                   | NFT token identifier                                                 |
| **nf\_token\_minter**            | string                                                                                                   | NFT token minter                                                     |
| **nf\_token\_offers**            | array(string)                                                                                            | NFT token offers                                                     |
| **nf\_token\_sell\_offer**       | string                                                                                                   | NFT sell offer identifier                                            |
| **nf\_token\_taxon**             | long                                                                                                     | NFT token taxon                                                      |
| **offer\_sequence**              | long                                                                                                     | Offer sequence number                                                |
| **operation\_limit**             | long                                                                                                     | Operation limit                                                      |
| **oracle\_document\_id**         | long                                                                                                     | Oracle document identifier                                           |
| **owner**                        | string                                                                                                   | Owner of the account or asset                                        |
| **paths**                        | string                                                                                                   | Payment paths for cross-currency payments                            |
| **previous\_txn\_id**            | string                                                                                                   | Previous transaction identifier                                      |
| **price\_data\_series**          | array(struct(PriceData: struct(AssetPrice: string, BaseAsset: String, QuoteAsset: string, Scale: long))) | Price data series                                                    |
| **provider**                     | string                                                                                                   | Provider information                                                 |
| **public\_key**                  | string                                                                                                   | Public key of the account                                            |
| **quality\_in**                  | long                                                                                                     | Quality in for exchange transactions                                 |
| **quality\_out**                 | long                                                                                                     | Quality out for exchange transactions                                |
| **regular\_key**                 | string                                                                                                   | Regular key for the account                                          |
| **send\_max**                    | struct(currency: string, issuer: string, value: string)                                                  | Maximum amount to send                                               |
| **sequence**                     | long                                                                                                     | Account sequence number                                              |
| **set\_flag**                    | long                                                                                                     | Flag to be set on the account                                        |
| **settle\_delay**                | long                                                                                                     | Settlement delay                                                     |
| **signature**                    | string                                                                                                   | Transaction signature                                                |
| **signer\_entries**              | array(struct(SignerEntry: struct(Account: String, SignerWeight: long)))                                  | Signer entries for multi-signing                                     |
| **signer\_quorum**               | long                                                                                                     | Signer quorum                                                        |
| **signers**                      | array(struct(Signer: struct(Account: string, SigningPubKey: string, TxnSignature: string)))              | Transaction signers                                                  |
| **signing\_pub\_key**            | string                                                                                                   | Signing public key                                                   |
| **source\_tag**                  | long                                                                                                     | Source tag                                                           |
| **taker\_gets**                  | struct(currency: string, issuer: string, value: string)                                                  | Amount the taker gets in an offer                                    |
| **taker\_pays**                  | struct(currency: string, issuer: string, value: string)                                                  | Amount the taker pays in an offer                                    |
| **tick\_size**                   | long                                                                                                     | Tick size for trading                                                |
| **ticket\_count**                | long                                                                                                     | Number of tickets                                                    |
| **ticket\_sequence**             | long                                                                                                     | Ticket sequence number                                               |
| **trading\_fee**                 | long                                                                                                     | Trading fee                                                          |
| **transaction\_type**            | string                                                                                                   | Type of transaction                                                  |
| **transfer\_fee**                | long                                                                                                     | Transfer fee                                                         |
| **transfer\_rate**               | long                                                                                                     | Transfer rate                                                        |
| **txn\_signature**               | string                                                                                                   | Transaction signature                                                |
| **unl\_modify\_disabling**       | long                                                                                                     | UNL modify disabling flag                                            |
| **unl\_modify\_validator**       | string                                                                                                   | UNL modify validator                                                 |
| **uri**                          | string                                                                                                   | URI associated with the account                                      |
| **hash**                         | string                                                                                                   | Transaction hash                                                     |
| **ledger\_index**                | long                                                                                                     | Ledger index                                                         |
| **\_event\_created\_at**         | timestamp                                                                                                | Event creation timestamp                                             |
| **\_ledger\_close\_time\_human** | string                                                                                                   | Human-readable ledger close time                                     |
| **ledger\_close\_date**          | date                                                                                                     | Date when the ledger closed                                          |
| **\_inserted\_at**               | timestamp                                                                                                | Record insertion timestamp                                           |
| **message\_key**                 | string                                                                                                   | Message key                                                          |
| **e\_price**                     | struct(currency: string, value: string)                                                                  | Exchange price                                                       |
| **unauthorize**                  | string                                                                                                   | Account to be unauthorized                                           |
| **amendment**                    | string                                                                                                   | Amendment identifier                                                 |
| **\_ingested\_at**               | timestamp                                                                                                | Data ingestion timestamp                                             |

## Table Sample

<TableSample />


# xrpl.transactions_base
Source: https://docs.dune.com/data-catalog/xrpl/transactions_base

The 'xrpl.transactions_base' table contains every validated transaction recorded on the XRP Ledger, covering payments, token operations, DEX trades, NFT activity, and more.

## Table Description

Contains every validated transaction recorded on the XRP Ledger, covering payments, token operations, DEX trades, NFT activity, and more. Use this table to analyze on-chain transaction volume, fees, outcomes, and account behavior over time.

## Column Descriptions

| **Column**                   | **type**                                                                           | **Description**                                                                                                                  |
| ---------------------------- | ---------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| **transaction\_id**          | bigint                                                                             | Unique surrogate primary key for the transaction record                                                                          |
| **transaction\_hash**        | string                                                                             | Cryptographic hash uniquely identifying the transaction on the XRP Ledger; used for cross-referencing with on-chain data         |
| **transaction\_type**        | string                                                                             | Transaction category (e.g., Payment, OfferCreate, TrustSet, NFTokenMint); determines applicable fields and behavior              |
| **transaction\_result**      | string                                                                             | Final outcome code (e.g., tesSUCCESS, tecNO\_DST), indicating whether the transaction succeeded or the reason for failure        |
| **ledger\_close\_date**      | date                                                                               | Calendar date the ledger containing this transaction was closed                                                                  |
| **ledger\_close\_time**      | timestamp                                                                          | Precise timestamp the ledger was closed and the transaction was confirmed                                                        |
| **ledger\_index**            | bigint                                                                             | Sequence number of the ledger in which this transaction was included                                                             |
| **transaction\_index**       | bigint                                                                             | Position of this transaction within its ledger, reflecting execution order                                                       |
| **transaction\_fee**         | decimal(38,6)                                                                      | XRP fee consumed by this transaction, expressed in XRP                                                                           |
| **account\_id**              | bigint                                                                             | Surrogate key for the sending account (→ accounts)                                                                               |
| **account\_address**         | string                                                                             | XRPL address of the transaction sender                                                                                           |
| **destination\_id**          | bigint                                                                             | Surrogate key for the receiving account (→ accounts)                                                                             |
| **destination\_address**     | string                                                                             | XRPL address of the transaction recipient                                                                                        |
| **destination\_tag**         | bigint                                                                             | Off-ledger routing tag identifying the intended beneficiary at the destination address (e.g., a customer account at an exchange) |
| **account\_transaction\_id** | string                                                                             | Chained hash linking to the sender's previous transaction, used to enforce transaction ordering                                  |
| **delivered\_amount**        | struct(currency: string, issuer: string, value: string, mpt\_issuance\_id: string) | Actual amount delivered to the destination, structured with currency, issuer, value, and MPT issuance ID                         |
| **flags**                    | bigint                                                                             | Bitwise integer encoding transaction-specific behavior modifiers                                                                 |
| **last\_ledger\_sequence**   | bigint                                                                             | Maximum ledger index at which the transaction remains valid; used to bound transaction expiry                                    |
| **memos**                    | array(json)                                                                        | Array of arbitrary key-value memo objects attached to the transaction for off-ledger annotation or metadata                      |
| **signers**                  | array(json)                                                                        | Array of signers for multi-signature transactions, each containing account, public key, and signature                            |
| **signing\_pub\_key**        | string                                                                             | Hex-encoded public key used to authorize a single-signed transaction                                                             |
| **source\_tag**              | bigint                                                                             | Off-ledger routing tag identifying the originating customer or purpose at the sending address                                    |
| **ticket\_sequence**         | bigint                                                                             | Sequence number of the ticket used in place of a standard account sequence, enabling out-of-order transaction submission         |
| **transaction\_sequence**    | bigint                                                                             | Account sequence number ensuring replay protection and ordering for transactions from the same sender                            |
| **transaction\_signature**   | string                                                                             | Cryptographic signature proving the transaction was authorized by the account's private key                                      |
| **uri**                      | string                                                                             | URI associated with the transaction, typically used in NFT-related transactions to reference off-chain metadata                  |

## Table Sample

<TableSample />


# xrpl.transfers
Source: https://docs.dune.com/data-catalog/xrpl/transfers

The 'xrpl.transfers' table contains all successful direct, same-asset Payment transactions on the XRP Ledger, one row per transfer.

## Table Description

Contains all successful direct, same-asset Payment transactions on the XRP Ledger, one row per transfer. Only includes transfers where the sender and recipient transact in the same currency — cross-currency and DEX-routed payments are excluded.

## Column Descriptions

| **Column**                             | **type**  | **Description**                                                                                                                                     |
| -------------------------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| **transfer\_id**                       | bigint    | Unique surrogate primary key for this transfer record                                                                                               |
| **ledger\_close\_date**                | date      | Calendar date the ledger containing this transfer was closed                                                                                        |
| **transaction\_id**                    | bigint    | Surrogate key linking to the transaction (→ transactions)                                                                                           |
| **transaction\_hash**                  | string    | Cryptographic hash uniquely identifying this transaction on the XRP Ledger                                                                          |
| **transaction\_type**                  | string    | Type of transaction that generated this transfer (e.g. Payment)                                                                                     |
| **timestamp**                          | timestamp | Precise timestamp when the ledger containing this transfer was closed and confirmed                                                                 |
| **memo**                               | string    | First memo attached to the transaction, decoded from hex; used for off-ledger context such as payment references or identifiers                     |
| **transaction\_fee**                   | double    | XRP fee consumed by this transaction, expressed in XRP                                                                                              |
| **account\_id**                        | bigint    | Surrogate key for the account that sent this transfer (→ accounts)                                                                                  |
| **account\_address**                   | string    | XRPL address of the sending account                                                                                                                 |
| **account\_balance\_before**           | double    | Sender's asset balance immediately before this transfer was applied                                                                                 |
| **account\_balance\_after**            | double    | Sender's asset balance immediately after this transfer was applied                                                                                  |
| **destination\_id**                    | bigint    | Surrogate key for the account that received this transfer (→ accounts)                                                                              |
| **destination\_address**               | string    | XRPL address of the receiving account                                                                                                               |
| **destination\_balance\_before**       | double    | Recipient's asset balance immediately before this transfer was applied                                                                              |
| **destination\_balance\_after**        | double    | Recipient's asset balance immediately after this transfer was applied                                                                               |
| **amount\_token\_id**                  | bigint    | Surrogate key for the token specified as the intended transfer amount (→ tokens)                                                                    |
| **amount\_currency**                   | string    | Currency code of the intended transfer amount                                                                                                       |
| **amount\_currency\_iso**              | string    | ISO 4217 currency code of the intended transfer amount, if applicable                                                                               |
| **amount\_issuer\_address**            | string    | XRPL address of the issuer of the intended transfer currency; null if XRP                                                                           |
| **amount\_value**                      | double    | Intended amount to deliver; for partial payments this is a maximum, not a guarantee — use delivered\_amount\_value for the actual amount received   |
| **delivered\_amount\_token\_id**       | bigint    | Surrogate key for the token actually delivered to the destination (→ tokens)                                                                        |
| **delivered\_amount\_currency**        | string    | Currency code of the amount actually received by the destination                                                                                    |
| **delivered\_amount\_currency\_iso**   | string    | ISO 4217 currency code of the delivered amount, if applicable                                                                                       |
| **delivered\_amount\_issuer\_address** | string    | XRPL address of the issuer of the delivered currency; null if XRP                                                                                   |
| **delivered\_amount\_value**           | double    | Actual amount received by the destination after fees and exchange rates; always use this field — not amount\_value — to measure true transfer value |
| **deliver\_min\_token\_id**            | bigint    | Surrogate key for the token used to express the minimum delivery threshold (→ tokens); only set on partial payments                                 |
| **deliver\_min\_currency**             | string    | Currency code of the minimum delivery threshold                                                                                                     |
| **deliver\_min\_currency\_iso**        | string    | ISO 4217 currency code of the deliver minimum, if applicable                                                                                        |
| **deliver\_min\_issuer\_address**      | string    | XRPL address of the issuer of the deliver minimum currency; null if XRP                                                                             |
| **deliver\_min\_value**                | double    | Minimum amount the sender required to be delivered for the partial payment to succeed; null for non-partial payments                                |
| **send\_max\_token\_id**               | bigint    | Surrogate key for the token used to express the sender's spending cap (→ tokens)                                                                    |
| **send\_max\_currency**                | string    | Currency code the sender was willing to spend                                                                                                       |
| **send\_max\_currency\_iso**           | string    | ISO 4217 currency code of the send maximum, if applicable                                                                                           |
| **send\_max\_issuer\_address**         | string    | XRPL address of the issuer of the send maximum currency; null if XRP                                                                                |
| **send\_max\_value**                   | double    | Maximum amount the sender was willing to spend, including transfer fees and exchange costs                                                          |

## Table Sample

<TableSample />


# Block Events
Source: https://docs.dune.com/data-catalog/yominet/block_events

Yominet blockchain block events data

# Table Description

This table contains data about block-level events and attributes in the Yominet blockchain, including event types, sources, and associated metadata. The schema is modeled after Cosmos block events.

## Column Descriptions

| Column name          | Data Type                   | Description                                          |
| -------------------- | --------------------------- | ---------------------------------------------------- |
| **block\_date**      | date                        | The date of the block.                               |
| **block\_height**    | bigint                      | The height of the block where the event occurred.    |
| **block\_timestamp** | timestamp(3) with time zone | Timestamp when the block was validated.              |
| **chain\_id**        | varchar                     | The ID of the chain where the block belongs.         |
| **event\_index**     | bigint                      | A unique index for events within the block.          |
| **event\_type**      | varchar                     | The type of event that was triggered.                |
| **event\_source**    | varchar                     | The source of the event.                             |
| **attribute\_key**   | varchar                     | The key of the event attribute.                      |
| **attribute\_value** | varchar                     | The value of the event attribute.                    |
| **attribute\_index** | bigint                      | A unique index for attributes within the event.      |
| **updated\_at**      | timestamp(3) with time zone | Timestamp of when the record was last updated.       |
| **ingested\_at**     | timestamp(3) with time zone | Timestamp of when the record was ingested into Dune. |

## Table Sample

<TableSample />


# Blocks
Source: https://docs.dune.com/data-catalog/yominet/blocks

Yominet blockchain blocks data

# Table Description

This table contains data about blocks in the Yominet blockchain, including block headers, consensus data, and transaction information.

## Column Descriptions

| Column name           | Data Type                   | Description                                                  |
| --------------------- | --------------------------- | ------------------------------------------------------------ |
| **block\_date**       | date                        | The date of the block.                                       |
| **block\_height**     | bigint                      | The height of the block, a unique identifier for each block. |
| **block\_timestamp**  | timestamp(3) with time zone | Timestamp when the block was validated.                      |
| **chain\_id**         | varchar                     | The ID of the chain where the block belongs.                 |
| **proposer\_address** | varchar                     | The address of the validator proposing the block.            |
| **validators\_hash**  | varchar                     | The hash of the validators set for the block.                |
| **updated\_at**       | timestamp(3) with time zone | Timestamp of when the record was last updated.               |
| **ingested\_at**      | timestamp(3) with time zone | Timestamp of when the record was ingested into Dune.         |

## Table Sample

<TableSample />


# Message Events
Source: https://docs.dune.com/data-catalog/yominet/message_events

Yominet blockchain message events data

# Table Description

This table contains data about message-related events in the Yominet blockchain, including message types, attributes, and associated metadata. Because block events run on initia, this table just has a few entries by design at this point.

## Table Schema

| Column name          | Description                                           | Type                        |
| -------------------- | ----------------------------------------------------- | --------------------------- |
| **block\_date**      | The date of the block.                                | date                        |
| **block\_height**    | The height of the block where the event occurred.     | bigint                      |
| **block\_timestamp** | Timestamp when the block was validated.               | timestamp(3) with time zone |
| **chain\_id**        | The ID of the chain where the block belongs.          | varchar                     |
| **tx\_id**           | The hash of the transaction where the event occurred. | varchar                     |
| **tx\_index**        | The index of the transaction in the block.            | bigint                      |
| **message\_index**   | The index of the message in the transaction.          | bigint                      |
| **event\_index**     | A unique index for events within the message.         | bigint                      |
| **event\_type**      | The type of event that was triggered.                 | varchar                     |
| **attribute\_key**   | The key of the event attribute.                       | varchar                     |
| **attribute\_value** | The value of the event attribute.                     | varchar                     |
| **attribute\_index** | A unique index for attributes within the event.       | bigint                      |
| **updated\_at**      | Timestamp of when the record was last updated.        | timestamp(3) with time zone |
| **ingested\_at**     | Timestamp of when the record was ingested into Dune.  | timestamp(3) with time zone |

## Table Sample

<TableSample />


# Yominet Data
Source: https://docs.dune.com/data-catalog/yominet/overview

Yominet blockchain data on Dune

## What is Yominet?

Yominet is a blockchain network that serves as the foundation for applications like Kamigotchi and other decentralized applications. Yominet uses ETH as gas, making it easy for users familiar with Ethereum to interact with the network. Users can bridge \$ETH to Yominet using Initia's official bridge or gas.zip.

Yominet features a flat 0.005 gwei gas fee, providing predictable and low-cost transactions. The network supports popular wallets including Metamask and Rabby, making it accessible to a wide range of users.

## Key Features

* **Ethereum-Compatible Gas**: Uses \$ETH as gas, familiar to Ethereum users
* **Low Gas Fees**: Flat 0.005 gwei gas fee for predictable transaction costs
* **Wallet Support**: Compatible with Metamask and Rabby wallets
* **Easy Bridging**: Bridge \$ETH using Initia's official bridge or gas.zip
* **Application Platform**: Supports various decentralized applications including gaming platforms like Kamigotchi

## Yominet Data on Dune

Yominet blockchain data is organized into several key tables that capture different aspects of on-chain activity:

<CardGroup>
  <Card title="Blocks" icon="cube" href="/data-catalog/yominet/blocks">
    <p>Contains each validated block in the chain</p>
  </Card>

  <Card title="Block Events" icon="bolt" href="/data-catalog/yominet/block_events">
    <p>Contains all block-level events and attributes in the chain, partitioned by event\_index</p>
  </Card>

  <Card title="Message Events" icon="message" href="/data-catalog/yominet/message_events">
    <p>Contains all events and their corresponding attributes partitioned by message\_index</p>
  </Card>

  <Card title="Transactions" icon="arrow-right-arrow-left" href="/data-catalog/yominet/transactions">
    <p>Contains relevant data associated with each transaction</p>
  </Card>

  <Card title="Transaction Messages" icon="envelope" href="/data-catalog/yominet/tx_messages">
    <p>Contains all messages submitted to the blockchain</p>
  </Card>
</CardGroup>


# Transactions
Source: https://docs.dune.com/data-catalog/yominet/transactions

Yominet blockchain transactions data

# Table Description

This table contains data about transactions in the Yominet blockchain, including transaction details, gas usage, and execution status.

## Column Descriptions

| Column name            | Data Type                   | Description                                             |
| ---------------------- | --------------------------- | ------------------------------------------------------- |
| **block\_height**      | bigint                      | The height of the block where the transaction occurred. |
| **chain\_id**          | varchar                     | The ID of the chain where the transaction occurred.     |
| **tx\_id**             | varchar                     | The unique ID of the transaction.                       |
| **tx\_info**           | varchar                     | Information related to the transaction.                 |
| **tx\_log\_message**   | varchar                     | The log message associated with the transaction.        |
| **memo**               | varchar                     | A memo associated with the transaction.                 |
| **fee**                | varchar                     | The fee associated with the transaction.                |
| **tx\_code**           | bigint                      | The result code of the transaction.                     |
| **tx\_index**          | bigint                      | The index of the transaction within the block.          |
| **gas\_used**          | bigint                      | The amount of gas used by the transaction.              |
| **gas\_wanted**        | bigint                      | The amount of gas requested by the transaction.         |
| **schema\_version**    | bigint                      | The schema version for the transaction data.            |
| **fee\_coins**         | varchar                     | The coins used to pay the transaction fee.              |
| **fee\_granter**       | varchar                     | The address granting the fee for the transaction.       |
| **fee\_payer**         | varchar                     | The address paying the fee for the transaction.         |
| **gas\_limit**         | bigint                      | The gas limit set for the transaction.                  |
| **single\_sign\_mode** | bigint                      | The signing mode for single-signature transactions.     |
| **multi\_sign\_json**  | varchar                     | JSON structure for multi-signature transactions.        |
| **timeout\_height**    | varchar                     | The timeout height set for the transaction.             |
| **updated\_at**        | timestamp(3) with time zone | Timestamp of when the record was last updated.          |
| **ingested\_at**       | timestamp(3) with time zone | Timestamp of when the record was ingested into Dune.    |

## Table Sample

<TableSample />


# Transaction Messages
Source: https://docs.dune.com/data-catalog/yominet/tx_messages

Yominet blockchain transaction messages data

# Table Description

This table contains data about messages contained within transactions in the Yominet blockchain, including message types, content, and associated metadata.

<Tip>
  On execution, transactions from Cosmos emit data in two formats:

  * Messages (`yominet.tx_messages`): These provide a high-level, readable summary of actions, such as "send money" or "execute contract." They are easier to understand and track transaction types.
  * Events (`yominet.message_events`): These capture detailed, low-level changes at the chain level, including underlying blockchain modifications that may not always be directly related to state changes.
  * Use Messages for a general overview and Events when you need detailed insights. The two tables are complementary.
</Tip>

## Column Descriptions

| Column name          | Data Type                   | Description                                          |
| -------------------- | --------------------------- | ---------------------------------------------------- |
| **block\_date**      | date                        | The date of the block.                               |
| **block\_height**    | bigint                      | The height of the block where the message occurred.  |
| **block\_timestamp** | timestamp(3) with time zone | Timestamp when the block was validated.              |
| **chain\_id**        | varchar                     | The ID of the chain where the message belongs.       |
| **tx\_id**           | varchar                     | The hash of the transaction containing the message.  |
| **tx\_index**        | bigint                      | The index of the transaction in the block.           |
| **message\_index**   | bigint                      | The index of the message in the transaction.         |
| **message\_type**    | varchar                     | The type of message.                                 |
| **message**          | varchar                     | The value/content of the message.                    |
| **schema\_version**  | bigint                      | The version of the schema in provider database.      |
| **updated\_at**      | timestamp(3) with time zone | Timestamp of when the record was last updated.       |
| **ingested\_at**     | timestamp(3) with time zone | Timestamp of when the record was ingested into Dune. |

## Table Sample

<TableSample />


# Datashare Overview
Source: https://docs.dune.com/datashare/datashare

Access all of Dune's blockchain data directly in your data warehouse for privacy and control.

Datashare brings our complete blockchain dataset (1.5M+ tables, 100+ chains) directly into your data warehouse. Query blockchain data in your own environment with complete privacy and control.

## How Datashare Works

Datashare replicates Dune's processed blockchain data directly into your cloud data warehouse:

<img alt="Datashare Architecture" />

1. **Data Replication**: We maintain live copies of all Dune tables in your Snowflake or BigQuery environment
2. **Native Integration**: Data appears as regular tables/datasets in your warehouse - no APIs or external connections
3. **Fresh Data**: Automatic updates keep your data in sync with Dune's platform (hourly/daily refresh)
4. **Your Environment**: Query using your warehouse's native SQL, compute, and security controls

<Info>
  This is the same curated, decoded blockchain data that powers dune.com - optimized for analytics with proper data types and indexing.
</Info>

## Platforms

| **Platform**                                       | **Access Method**           | **Trial Available** |
| -------------------------------------------------- | --------------------------- | ------------------- |
| ❄️ **[Snowflake](/datashare/datashare-snowflake)** | Marketplace or Direct Share | 30-day free trial   |
| 🔍 **[BigQuery](/datashare/datashare-bigquery)**   | Dataset Sharing             | Contact for trial   |

## Why Choose Datashare

* **Complete Privacy**: Query in your warehouse - Dune never sees your queries or results
* **Join Your Data**: Seamlessly combine blockchain data with your internal datasets
* **Cost Control**: Use your existing warehouse compute and manage costs directly
* **No Rate Limits**: Query as much as you need without API constraints
* **Enterprise Security**: Leverage your warehouse's existing security and compliance controls
* **dbt Integration**: Publish dbt-managed transformation outputs from Dune directly into your warehouse with [dbt to Datashare](/api-reference/connectors/dbt/datashares)

## Working with Dune

### Getting Started

**For Trials:**

* **Snowflake**: Self-service via [Snowflake Marketplace](https://app.snowflake.com/marketplace/providers/GZSVZMYSCO/Dune)
* **BigQuery**: Email [datashares-sales@dune.com](mailto:datashares-sales@dune.com) with your requirements

**For Production:** Contact our enterprise team at [dune.com/enterprise](https://dune.com/enterprise) or [datashares-sales@dune.com](mailto:datashares-sales@dune.com)

### What We Need From You

To set up datashare access, we need specific identifiers from your cloud environment:

<AccordionGroup>
  <Accordion title="Snowflake Requirements">
    Please provide your Snowflake data sharing account identifier so I can grant you access to a listing. To find this identifier log in to your Snowflake account and click at your user profile at the bottom of the screen > *Account* > *View account details* > Copy data sharing account identifier (you can view a visual path [here](https://docs.snowflake.com/en/alias/client/account-identifier-listing)). You can also run the following SQL command:

    ```sql theme={null}
    SELECT CURRENT_ORGANIZATION_NAME() || '.' || CURRENT_ACCOUNT_NAME();
    ```

    Then, share your identifier with me.
  </Accordion>

  <Accordion title="BigQuery Requirements">
    **Required Information:**

    * **GCP Project ID** (not project name - the unique ID)
    * **Principal for access** (user email, service account, or domain)
    * **Preferred region** (US Central 1 or EU West 2)
    * **Chains of interest** (optional - we can share all by default)

    **Principal Examples:**

    * User: `user:alice@company.com`
    * Service Account: `serviceAccount:etl-service@my-project.iam.gserviceaccount.com`
    * Domain: `domain:company.com` (all users in domain)
  </Accordion>
</AccordionGroup>

### Setup Process

1. **Share Identifiers**: Provide the required identifiers for your platform
2. **Access Configuration**: We configure sharing permissions on our side
3. **Verification**: We'll confirm when data is available in your environment
4. **Support**: Ongoing technical support for queries and optimization

<Warning>
  **Security Note**: We only need identifiers to grant access - never passwords, keys, or other sensitive credentials.
</Warning>

## Platform-Specific Access

<CardGroup>
  <Card title="Snowflake Guide" icon="snowflake" href="/datashare/datashare-snowflake">
    Marketplace access, data types, and query examples
  </Card>

  <Card title="BigQuery Guide" icon="cloud" href="/datashare/datashare-bigquery">
    Dataset sharing, principals, and optimization tips
  </Card>

  <Card title="dbt to Datashare" icon="share-nodes" href="/api-reference/connectors/dbt/datashares">
    Sync dbt-managed tables from your Dune namespace into your warehouse
  </Card>
</CardGroup>

## Next Steps

1. **[Try a free trial](/datashare/datashare-trial)** - Test our data on your platform
2. **[Review platform guides](/datashare/datashare-snowflake)** - Learn about data types and querying
3. **[Contact enterprise team](https://dune.com/enterprise)** - Discuss production requirements
4. **[Check FAQs](/datashare/datashare-faqs)** - Common questions and troubleshooting

Need a different platform or have questions? [Contact us](https://dune.com/enterprise) or email [support@dune.com](mailto:support@dune.com).


# BigQuery Datashare
Source: https://docs.dune.com/datashare/datashare-bigquery

Access Dune's blockchain data directly in your BigQuery environment

Access 1.5M+ blockchain tables across 100+ chains directly in your BigQuery environment.

## How It Works

BigQuery Datashare uses Google Cloud's dataset sharing to replicate Dune's data into your project:

* **Cross-Project Sharing**: Dune grants your project access to shared datasets containing our blockchain data
* **Regional Replication**: Data is replicated to your preferred region (US Central 1 or EU West 2)
* **Native Integration**: Shared datasets appear as regular BigQuery datasets in your project
* **Automatic Sync**: Fresh data arrives daily/hourly without manual intervention

## Get Started

**Trial:** Email [datashares-sales@dune.com](mailto:datashares-sales@dune.com) or [contact enterprise team](https://dune.com/enterprise)

**Requirements:**

* GCP Project ID
* Preferred region (US Central 1 or EU West 2)
* Chains of interest

## Sharing Identifiers

BigQuery uses dataset sharing for accessing Dune data:

* **Data Hub**: Shared datasets appear in your project's Data Hub
* **Direct sharing**: We grant access to specific dataset IDs in your project

## Principal Types

We need a "Principal" to grant access. This can be:

| **Type**                     | **Format**                                                                                       | **Example**                                               |
| ---------------------------- | ------------------------------------------------------------------------------------------------ | --------------------------------------------------------- |
| **User**                     | `user:email@domain.com`                                                                          | `user:bob@acme.com`                                       |
| **Service Account**          | `serviceAccount:name@project.iam.gserviceaccount.com`                                            | `serviceAccount:etl-sa@cust-proj.iam.gserviceaccount.com` |
| **Domain**                   | `domain:domain.com`                                                                              | `domain:acme.com`                                         |
| **Project Service Accounts** | `principalSet://cloudresourcemanager.googleapis.com/projects/PROJECT_NUMBER/type/ServiceAccount` | All service accounts for project                          |

<Info>
  Most common: provide your email address or a service account email. We can share complete blockchain history in seconds.
</Info>

See [GCP Principal Identifiers documentation](https://cloud.google.com/iam/docs/principal-identifiers) for more details.

## Data Types

BigQuery uses native types for blockchain data:

### Addresses & Hashes

```sql theme={null}
-- Query using BYTES
WHERE tx_hash = FROM_HEX('efb2e2c26974f72d9f3f04c693db73ecc679dd60')
-- Or STRING
WHERE tx_hash_hex = '0xefb2e2c26974f72d9f3f04c693db73ecc679dd60'
```

### Large Integers

BigQuery's `BIGNUMERIC` handles uint256/int256 natively:

```sql theme={null}
WHERE value > CAST('1000000000000000000000' AS BIGNUMERIC)
```

### Event Logs

```sql theme={null}
SELECT block_number, topics, data
FROM `project.ethereum.logs`
WHERE topics[OFFSET(0)] = FROM_HEX('ddf252ad...')
```

## Query Optimization

* Use `block_time` in WHERE clauses for partitioning
* Select only needed columns
* Tables are clustered by common query patterns

## Regions

| Region       | Chains | Freshness |
| ------------ | ------ | --------- |
| US Central 1 | 50+    | 24 hours  |
| EU West 2    | 50+    | 24 hours  |

Need other regions? [Contact us](https://dune.com/enterprise)

**Support:** [datashares-sales@dune.com](mailto:datashares-sales@dune.com) | [support@dune.com](mailto:support@dune.com) | [Discord](https://discord.gg/2VCqwzzF7u)


# Databricks Datashare
Source: https://docs.dune.com/datashare/datashare-databricks

Access Dune's blockchain data directly in your Databricks environment

Access 1.5M+ blockchain tables across 100+ chains directly in your Databricks environment.

## How It Works

Databricks Datashare brings Dune's blockchain data directly into your existing warehouse setup:

* **Cross-Region Replication**: Data is replicated to your preferred region for dependable low-latency performance
* **Full Historical Coverage**: Complete blockchain history across major chains, including Solana
* **Continuous Syncs**: Data stays current with automatic updates for production-scale use cases
* **Native Integration**: Query using standard Databricks SQL alongside your internal datasets with zero ETL overhead
* **Governance Controls**: Integrates with your existing security and access controls for secure enterprise rollout

## Get Started

**Trial:** Email [datashares-sales@dune.com](mailto:datashares-sales@dune.com) or [contact enterprise team](https://dune.com/enterprise)

**Requirements:**

* Databricks workspace details
* Preferred cloud region
* Chains of interest

## Use Cases

* **Machine Learning**: Build ML pipelines with comprehensive blockchain data
* **Advanced Analytics**: Combine onchain data with internal datasets for deeper insights
* **Data Science**: Run complex analyses using Databricks notebooks and SQL
* **Production Pipelines**: Integrate blockchain data into existing Databricks workflows

## Details

* **Freshness**: Hourly or daily depending on requirements
* **Regions**: Available across major cloud regions, contact us for specific availability
* **Support**: [datashares-sales@dune.com](mailto:datashares-sales@dune.com) | [support@dune.com](mailto:support@dune.com) | [Discord](https://discord.gg/2VCqwzzF7u)


# Datashare FAQs
Source: https://docs.dune.com/datashare/datashare-faqs

Frequently Asked Questions about Dune Datashare

<AccordionGroup>
  <Accordion title="How does datashare work technically?">
    **Snowflake**: Uses Snowflake's native data sharing - data stays in our account but appears as tables in yours. Zero storage costs, only compute charges.

    **BigQuery**: We replicate data to shared datasets in your GCP project. Data is copied to your region for performance.

    Both provide the same curated blockchain data that powers dune.com.
  </Accordion>

  <Accordion title="What identifiers do I need to share with Dune?">
    **Snowflake**: Account locator (e.g., `ABC12345.US-EAST-1`) - found in your Snowflake URL

    **BigQuery**: GCP Project ID and a Principal (your email, service account, or domain)

    We never need passwords or sensitive credentials - just sharing identifiers.
  </Accordion>

  <Accordion title="How do I get started?">
    **Snowflake**: Self-service via [Snowflake Marketplace](https://app.snowflake.com/marketplace/providers/GZSVZMYSCO/Dune) for 30-day trial

    **BigQuery**: Email [datashares-sales@dune.com](mailto:datashares-sales@dune.com) with your GCP Project ID

    **Enterprise**: Visit [dune.com/enterprise](https://dune.com/enterprise)
  </Accordion>

  <Accordion title="What platforms do you support?">
    * **Snowflake** (marketplace access, all regions)
    * **BigQuery** (custom setup, US Central 1 & EU West 2)

    Need Databricks, Redshift, or another platform? [Contact us](https://dune.com/enterprise)
  </Accordion>

  <Accordion title="How fresh is the data?">
    **Standard**: 24 hours for most tables
    **Enterprise**: Hourly updates available
    **Real-time**: Some key tables update every few minutes

    Freshness varies by chain and table type.
  </Accordion>

  <Accordion title="Is it the same data as Dune's platform?">
    Yes, identical curated data. Data types are optimized for each platform:

    * BigQuery: Uses BIGNUMERIC for large integers, BYTES for addresses
    * Snowflake: Uses VARBINARY for addresses/hashes, DOUBLE for calculations
  </Accordion>

  <Accordion title="Can I join with my existing data?">
    Yes - that's the main benefit! Query blockchain data alongside your internal datasets using your warehouse's native SQL.
  </Accordion>

  <Accordion title="Do you see my queries or data?">
    No. You query in your own warehouse environment. Dune cannot see your queries, results, or any data you join with ours.
  </Accordion>

  <Accordion title="What does it cost?">
    **Trials**: Free (Snowflake 30 days, BigQuery by request)
    **Production**: Contact sales for pricing
    **Compute**: You pay your cloud provider's standard rates for querying
  </Accordion>

  <Accordion title="[Snowflake] Get button didn't work?">
    Click "Get" twice if needed. Snowflake sometimes requires:

    1. First click: Copies data to your region
    2. Second click: Adds share to your account
  </Accordion>

  <Accordion title="[BigQuery] How do I find shared datasets?">
    Shared datasets appear in your BigQuery console under your project. Look for datasets with names like `dune_ethereum` or `dune_polygon`.
  </Accordion>

  <Accordion title="Need help?">
    * **Technical Support**: [support@dune.com](mailto:support@dune.com)
    * **Sales/Trials**: [datashares-sales@dune.com](mailto:datashares-sales@dune.com)
    * **Discord**: [#datashare channel](https://discord.gg/2VCqwzzF7u)
    * **Enterprise**: [dune.com/enterprise](https://dune.com/enterprise)
  </Accordion>
</AccordionGroup>


# Snowflake Datashare
Source: https://docs.dune.com/datashare/datashare-snowflake

Access Dune's blockchain data through the Snowflake Marketplace

Access 1.5M+ blockchain tables across 100+ chains directly in your Snowflake environment.

## How It Works

Snowflake Datashare uses Snowflake's native data sharing capabilities to provide instant access to Dune's data:

* **Shared Storage**: Data lives in Dune's Snowflake account but appears as regular tables in your environment
* **Zero-Copy Sharing**: No data transfer fees or storage duplication - you only pay for compute
* **Live Updates**: Shared data automatically reflects our latest blockchain processing
* **Native Access**: Query using standard Snowflake SQL with full performance optimization

## Get Started

**Trial (Free):**

1. Go to [Dune on Snowflake Marketplace](https://app.snowflake.com/marketplace/providers/GZSVZMYSCO/Dune)
2. Click "Get" on any dataset for 30-day free trial
3. Start querying

**Production:** [Contact enterprise team](https://dune.com/enterprise) or email [datashares-sales@dune.com](mailto:datashares-sales@dune.com)

## Sharing Identifiers

Please provide your Snowflake data sharing account identifier so I can grant you access to a listing. To find this identifier log in to your Snowflake account and click at your user profile at the bottom of the screen > *Account* > *View account details* > Copy data sharing account identifier (you can view a visual path [here](https://docs.snowflake.com/en/alias/client/account-identifier-listing)). You can also run the following SQL command:

```sql theme={null}
SELECT CURRENT_ORGANIZATION_NAME() || '.' || CURRENT_ACCOUNT_NAME();
```

Then, share your identifier with me.

## Data Types

Blockchain data types are adapted for Snowflake:

### Addresses & Hashes

* `column_name` (VARBINARY) - use for queries (faster)
* `column_name_hex` (STRING) - for convenience

```sql theme={null}
-- Recommended:
WHERE hash = X'efb2e2c26974f72d9f3f04c693db73ecc679dd60'
-- Slower:
WHERE hash_hex = '0xefb2e2c26974f72d9f3f04c693db73ecc679dd60'
```

### Large Integers (uint256/int256)

* `column_name` (DOUBLE) - for most calculations
* `column_name_binary` (VARBINARY) - for exact precision

Use VARBINARY for exact matching (e.g., token IDs), DOUBLE for calculations.

If you need full precision when doing arithmetic, you must work with the VARBINARY field:

• You can convert the binary to `DECIMAL(38,0)` if you are fine with the smaller range (up to 38 digits vs. 78 for `UINT256`).

• Any values larger than `DECIMAL(38,0)` will overflow and must be handled as `NULL` or excluded.

Here is an example conversion query:

```sql theme={null}
select 
  IFF(
    SUBSTR(amount_raw, 1, 17) != TO_BINARY(REPEAT('0', 34), 'HEX'), -- check for overflow
    NULL, -- if overflow, return null
    TO_NUMBER(
      TO_VARCHAR(SUBSTR(amount_raw, 18, 15), 'HEX'),
      REPEAT('X', 30)
    )::NUMBER(38,0) -- convert last 15 bytes to decimal
  ) AS amount_raw_converted,
  amount_raw,
  amount,
  tx_hash
from prod_datashares.tokens.transfers
limit 100;
```

## Details

* **Freshness**: hourly or daily depending on requirements
* **Regions**: Available worldwide, contact us for specific region availability
* **Support**: [support@dune.com](mailto:support@dune.com) | [Discord](https://discord.gg/2VCqwzzF7u)


# Getting Started with Datashare
Source: https://docs.dune.com/datashare/datashare-trial

Interested in Dune Datashare? Test out our data on Snowflake or BigQuery!

Test Dune's blockchain data on your preferred platform:

<CardGroup>
  <Card title="Snowflake Trial" icon="snowflake">
    **Self-service** - Available now

    * 100+ chains, 30-day free trial
    * Via Snowflake Marketplace

    [Get Started →](#snowflake)
  </Card>

  <Card title="BigQuery Trial" icon="cloud">
    **Custom setup** - Contact required

    * 100+ chains in US/EU regions
    * Email for trial access

    [Request Access →](#bigquery)
  </Card>
</CardGroup>

## Snowflake

1. Go to [Dune on Snowflake Marketplace](https://app.snowflake.com/marketplace/providers/GZSVZMYSCO/Dune)
2. Click "Get" on any dataset for 30-day trial
3. Configure database name and roles
4. Start querying

<Warning>
  You may need to click "Get" twice - once to copy data, then again to add to your Snowflake.
</Warning>

See [Snowflake guide](/datashare/datashare-snowflake) for data types and query examples.

## BigQuery

Email [datashares-sales@dune.com](mailto:datashares-sales@dune.com) or use our [Enterprise form](https://dune.com/enterprise)

**Include:**

* GCP Project ID
* Preferred region (US Central 1 or EU West 2)
* Chains of interest

We'll set up trial access in your BigQuery project with technical support.

See [BigQuery guide](/datashare/datashare-bigquery) for data types and query examples.

## Support

Questions? Email [support@dune.com](mailto:support@dune.com) or join [Discord](https://discord.gg/2VCqwzzF7u)


# Changelog
Source: https://docs.dune.com/docs/changelog



# Product updates

> New releases and improvements

<Update label="April 2026">
  ## Visualization Management (MCP & CLI)

  The Dune MCP and CLI now fully support visualization management. In addition to creating visualizations, you can now list, update, and delete them — giving agents complete control over the visualization lifecycle. See the [MCP documentation](/api-reference/agents/mcp) and [CLI & Skills documentation](/api-reference/agents/cli-and-skills).

  ## Trust Center

  Visit the [Trust Center](https://trust.dune.com) for a public-facing view of Dune's security posture. Customers and prospects can review security documentation and request access to the engagement letter and other compliance documents.

  ## Connectors Usage Visibility

  A new page in the Usage section tracks connector usage (dbt, SQLMesh, etc.) on a daily basis — broken down by model, connector, operation type, environment, or API key. Credits usage for `Datashare Syncs` and `Datashare Storage` are now also tracked in the Usage activity table.

  ## Disable In-App AI Features (Enterprise)

  A new team-level setting disables in-app AI features (Debug, Dune Agent) for Enterprise customers with contractual requirements to opt out. MCP access is not affected by this flag.

  ## ERC-4626 Vault Support

  ERC-4626 Deposit and Withdraw events are now decoded across all EVM chains under `erc4626_<chain>.evt_Deposit` and `erc4626_<chain>.evt_Withdraw`. Full coverage of ERC-4626 deposit/withdraw flows has also been added to `tokens.transfers`, including non-compliant contracts that don't emit ERC20 Transfer events on vault operations (e.g. sDAI from Sky).

  ## Improvements

  * **Dataset search in global search** — Datasets now appear in global search results, with curated datasets prioritized to improve result quality
  * **Search modal UI (Phase 2)** — Results are grouped by content type with tabs, advanced filters are surfaced directly in the UI, and the modal has responsive design improvements across viewports
  * **MCP folder & search support** — You can now create queries under specific folders via MCP, and search Dashboards and Queries via MCP
  * **Credits usage chart toggle** — Credits usage charts now support toggling between cumulative usage and daily spend, making it easier to track both quota progress and day-by-day consumption
  * **dex\_solana.trades updates** — Fixes for Tessera, SolFiV2, BisonFi, and Whalestreet, plus added JupiterZ as a new AMM on `dex_solana.trades`
  * **Faster Data Explorer search** — Reduced search query latency in the Data Explorer from \~24s to \~3s
</Update>

<Update label="March 2026">
  ## dbt to Datashare

  You can now use dbt to publish transformed tables from Dune directly into Snowflake or BigQuery via Datashare. Keep your transformation logic on Dune and consume the outputs in your own warehouse — with incremental sync support, post-hook automation, and full lifecycle management through SQL. See the [dbt to Datashare documentation](/api-reference/connectors/dbt/datashares) and read the [announcement blog post](https://dune.com/blog/dbt-datashare).

  ## Organizations

  Introducing Organizations — manage multiple teams under a single Enterprise subscription with consolidated usage, centralized billing, and consistent security policies, without changing how teams collaborate day to day. See the [Organizations documentation](/web-app/organizations).

  ## DeFi Positions

  The DeFi Positions API now includes five new protocol families — Morpho, Pendle, VeNFT (Velodrome/Aerodrome), FluidVault, and Compound v2 — along with BSC chain support. See the [DeFi Positions documentation](https://docs.sim.dune.com/evm/defi-positions) on Sim.

  ## Dune MCP OAuth

  The Dune MCP now supports OAuth authentication for one-click setup in Claude and ChatGPT — no API key copy-paste or config files required. Connect your AI agent to 100+ blockchains of onchain data in seconds. See the [MCP documentation](/api-reference/agents/mcp).

  ## Machine Payments Protocol (MPP)

  Introducing MPP (Machine Payments Protocol by Tempo & Stripe) — agents can now execute queries and pay via crypto. This enables both agentic and manual integration flows for machine-to-machine payments. See the [MPP documentation](/api-reference/agents/mpp).

  ## Dune CLI + Skills

  Introducing the Dune CLI and agent skills — a lightweight alternative to MCP for agents running in Claude Code, Codex, OpenCode, and similar tools. Combine multiple CLIs together with typically fewer tokens than MCP protocol overhead. Install with `curl https://dune.com/cli/install.sh | sh`. See the [CLI & Skills documentation](/api-reference/agents/cli-and-skills).

  ## Insert Data API Improvements

  The Insert Data API now includes a new upsert endpoint for merging data and preventing duplicates, an upgraded storage engine with extensive bug fixes, and a simplified architecture that removes external locking dependencies. See the [Insert Data documentation](/api-reference/tables/endpoint/uploads-insert).

  ## Tempo Chain Support

  [Tempo](/data-catalog/evm/tempo/overview) mainnet and testnet are now fully supported on both Dune and [Sim](https://docs.sim.dune.com), including raw blocks, transactions, logs, traces, and decoded tables.

  ## Stablecoin Research Report

  Explore [Beyond Dollarization](https://dune.com/stablecoin-report), a research report with Visa on the rise of local currency stablecoins. Built on Dune's [stablecoins dataset](/data-catalog/curated/stablecoins/overview) (200+ tokens, 30+ chains), the report reveals that while supply grew 3x, holders grew 30x and volume grew 16x — distribution is massively outpacing issuance.

  ## System Theme

  You can now select System theme on dune.com. The interface automatically follows your OS light/dark preference.

  ## Dataset API Endpoints

  Two new API endpoints for dataset discovery: [Search datasets](/api-reference/datasets/endpoint/search) and [Search datasets by contract address](/api-reference/datasets/endpoint/search-by-contract). Find tables by keyword or look up all decoded tables for a specific contract.

  ## Read Query Endpoint — Contributors

  The [Read Query endpoint](/api-reference/queries/endpoint/read) now returns a `contributors` field with contribution counts and handles for users who have created or saved a query. Enable it with the `include_contributors=true` query parameter.

  ## Improvements

  * **Regex search in query editor** — Use regex patterns to search and replace in the query editor, including support for capture groups
  * **Data Explorer UX** — Reworked top-level categories, switched from breadcrumbs to a tree structure, and search results now appear within the tree so you can see where tables live before selecting them
  * **Dataset descriptions** — Added descriptions to 140+ curated datasets, improving discoverability across the MCP, Data Explorer, and data pages
  * **Expandable search on Discovery** — Search results on [Discovery pages](https://dune.com/discover/content/trending) now expand inline for content, creators, data, and blockchains
  * **Query version history** — Version history now lives in the query settings panel instead of the sidebar, freeing up space for a more focused Data Explorer
  * **tokens\_ethereum.transfers** — Now includes block miner rewards (pre-merge) and staking reward withdrawals
</Update>

<Update label="February 2026">
  ## Dune MCP

  We launched the Dune MCP (Model Context Protocol), enabling AI agents to query, execute, and interact with Dune directly. Connect the MCP to Claude, Cursor, or any compatible AI agent and let it search tables, execute queries, generate visualizations, and more — all without leaving your workflow. See the [MCP documentation](/api-reference/agents/mcp) for setup instructions.

  ## DeFi Positions API

  The DeFi Positions API is now available on [Sim](https://docs.sim.dune.com/evm/defi-positions). Get a wallet's active DeFi positions — liquidity pools, lending, and yield strategies — with USD valuations and protocol metadata. Supports Uniswap V2/V3/V4 (and forks), Aave v2/v3, and ERC-4626 vaults across 9 EVM chains.

  ## Stablecoin Dataset & Showcase Page

  A first-class stablecoin analytics product built on 346 SQL models across 38 chains. The classification layer matches every transfer to its onchain trigger (DEX swap, lending event, bridge deposit, CEX movement) and labels every holder address by venue type. Premium tables include `activity_enriched` and `balances_enriched` for EVM and Solana. Free foundation tables — `transfers` and `balances` — are available for EVM, Solana, and Tron. Explore the [Stablecoin Showcase](https://dune.com/collection/stablecoins/overview) or see the [Stablecoins documentation](/data-catalog/curated/stablecoins/overview).

  ## Raw Solana Data in BigQuery US (Datashare)

  All raw Solana data is now synced to BigQuery in the US region via Datashare — over 600TB across 9 tables including `solana.account_activity`, `solana.instruction_calls`, `solana.transactions`, and more. Existing US multi-region customers can access this data at no extra cost.

  ## Credit-Based Pricing Model

  We've transitioned all self-serve plans to the new credit-based pricing model. This update consolidates exports, writes, and storage under a single credit-based system, removing datapoint conversions and simplifying billing. See [Billing](/api-reference/overview/billing) for details.

  ## Datasets in Discover

  Shipped [dune.com/discover/data](https://dune.com/discover/data) to surface Datasets in the Discover page. Browse and search curated datasets with chain coverage badges and direct links to documentation — part of a broader effort to drive visibility and traffic to Dune's data products.

  ## Sidebar Navigation Redesign

  Elevated key pages from Library to the primary sidebar on dune.com. Dashboards, Queries, Schedules, Alerts, Uploaded data, Materialized views, Connectors, Custom endpoints, Folders, Contracts, and APIs are now directly accessible from the sidebar, making it easier to find and manage your content.

  ## Improvements

  * **Pie chart upgrade** — New color palette with blockchain color mapping, redesigned tooltips, and adjusted legend layout, bringing pie charts on par with other chart types
  * **Chart duplicate x handling** — New chart option to visualize and control how duplicate x values within a series are handled, with options to sum across duplicates
  * **9 new Solana DEX AMMs** — Added 9 new projects to `dex_solana.trades` under a unified prop AMM design
  * **Usage activity table** — The usage table now persists all modifications (search, filter, columns, sorting, pagination, time range) in the URL, so you can bookmark and share filtered views
  * **Datashare status page** — Datashare now has its own section on the [Dune status page](https://status.dune.com) with per-target data warehouse status monitoring
</Update>

<Update label="January 2026">
  ## Incremental Queries

  Incremental Queries allow you to write SQL that processes only recent data and merges it with previous query results. This enables fresh data analysis at a fraction of the cost, making it ideal for dashboards and reports that need regular updates. The feature supports complex queries including group bys and cumulative sums. See the [Incremental Queries documentation](/query-engine/incremental-queries) for details.

  ## Mermaid Charts in Dashboards

  You can now create Mermaid diagrams directly in dashboard text widgets. Use the `mermaid` code block syntax to add flowcharts, sequence diagrams, and other visualizations to your dashboards.

  ## New Curated Table: tokens.fdv\_latest

  A new curated table for Fully Diluted Valuation (FDV) data across all EVM chains. The table shows ERC20 tokens with onchain transfers, their latest supply (updated on mint/burn events), and FDV calculated. This table is in open beta as we continue to work and improve it.

  ## Data Sources Visibility

  Queries now display their data sources in the sidebar. Additionally Dashboards include a new "Data" button showing all datasets used to build the dashboard.

  ## dbt Connector Video Tutorial

  A new [video tutorial](https://www.youtube.com/watch?v=TRqqPC0PcZU) for the dbt Connector is now available, providing step-by-step guidance for setting up and using dbt on Dune.

  ## Improvements

  * **Dune AI** — Improved Dune AI with a modern agentic approach for better query generation and assistance
  * **Curated Data Explorer** — Reorganized curated data section with revamped categories and a new "More curated data" section
  * **Okta real-time sync (Enterprise)** — Users removed from an Okta organization are now immediately logged out of Dune
  * **Dashboard timestamps** — Dashboards now display "updated at" timestamps instead of "created at" on profile pages
  * **Simplified authentication** — Removed "Sign in with Ethereum" option to streamline the login experience (wallet linking remains available after signup)
</Update>

<Update label="December 2025">
  ## Domain-Restricted Google SSO (Enterprise)

  Team admins can now enable domain restriction via Google SSO in team settings. This forces team members to log in using their company email (e.g., @company.com), preventing non-employees from accessing the workspace. When enabled, all team members are logged out and must re-authenticate with Google SSO. See the [Google SSO documentation](/web-app/google-sso-domain-restriction) for setup details.

  ## Okta SSO (Enterprise)

  We now support Okta SSO for Enterprise customers, a frequently requested feature for enterprise security requirements. You can enable Okta SSO via team settings under the new "Settings & Privacy" tab. We also extended this feature to support multiple domains for organizations with complex Okta tenant configurations. See the [Okta SSO documentation](/web-app/okta-sso) for setup details.

  ## Usage Table

  A new Usage table is now available, containing records of metered App, API, and Connector events. Users can search, filter, and export these records for detailed usage analysis and cost tracking.

  ## Private Content by Default (Enterprise)

  Enterprise customers can now control the default privacy mode for team content with three options:

  * **Public by default** — Team members choose per content
  * **Private by default** — New content defaults to private, can be made public individually
  * **Private only** — All content forced private, external sharing disabled

  This helps teams working with sensitive data ensure privacy is the default, making link sharing an explicit opt-in.

  ## Improvements

  * **Export CSV downloads** — Improved CSV export experience for usage data
  * **Folder filtering** — Filter by Dashboards or Queries inside folders
  * **Embed fix** — Fixed an issue where embeds did not show username/avatar when the query belonged to a user
  * **EVM Contract resubmission** — Resubmission actions (rename, upgrade, delete) now gated to paid team plans
  * **Query editor UX** — Click the drag icon to expand the query editor (in addition to dragging)
</Update>

<Update label="November 2025">
  ## Databricks Support for Datashare (Enterprise)

  Datashare now supports Databricks, expanding our data warehouse integrations beyond Snowflake and BigQuery. Stream Dune's complete blockchain dataset directly into your Databricks environment. See the [Databricks documentation](/datashare/datashare-databricks) and read the [announcement blog post](https://dune.com/blog/expanding-dune-datashare-with-databricks).

  ## dbt Connector (Enterprise)

  Enterprise customers can now use dbt for in-platform data transformations with incremental runs. Build production data pipelines, version control your models, and run transformations directly on Dune. See the [dbt Connector documentation](/api-reference/connectors/dbt/overview) and read the [announcement blog post](https://dune.com/blog/run-dbt-on-dune-your-crypto-data-warehouse).

  ## New Chain Support

  Added support for [Initia](/data-catalog/initia/overview), [Kalshi](/data-catalog/kalshi/overview), [Story](/data-catalog/evm/story/overview), [Mezo](/data-catalog/evm/mezo/overview), and [Monad](/data-catalog/evm/monad/overview). Explore raw, decoded, and curated data for these new chains in the Data Catalog.

  ## New API Landing Page

  A new [API landing page](https://dune.com/apis) provides a unified view of all endpoints with quick curl/preview actions and documentation links.

  ## New API Endpoints

  New endpoints for executing arbitrary SQL, pipeline executions, usage data, and dataset metadata. See the [API documentation](/api-reference/overview/introduction) for details.

  ## Improvements

  * **Improved usage overview** — Charts and copyable API keys for better visibility
  * **Increased max query result size** — From 8GB to 32GB
  * **Restructured [API documentation](/api-reference/overview/introduction)** — Scannable for newcomers while keeping advanced details discoverable
  * **Updated SDKs** — All new endpoints included
  * **Deprecated `/v1/tables` endpoints** — Moved to `/v1/uploads`. See the [Tables API documentation](/api-reference/tables/endpoint/overview) for migration details
</Update>


# Products Overview
Source: https://docs.dune.com/docs/product-comparison

Compare Dune's core products: Data Hub, Datashare, and Sim (Realtime APIs)

Dune delivers blockchain data via three core products: **Data Hub**, **Datashare**, and **Sim (Realtime APIs)**. Each product serves different use cases, from ad-hoc analytics to real-time wallet application development.

## Capabilities

What each product is best suited for.

|                     | <a href="/web-app/overview">Data Hub</a>                                                                                      | <a href="/datashare/datashare">Datashare</a>  | <a href="https://sim.dune.com">Sim (Realtime APIs)</a> |
| ------------------- | ----------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------- | ------------------------------------------------------ |
| **Best For**        | Primary onchain data warehouse, Analytic workflows, <a href="/api-reference/connectors/dbt/overview">Data transformations</a> | Data warehouse integration & Interoperability | Build realtime wallets, portfolio apps                 |
| **SQL Access**      | ✓ Full SQL                                                                                                                    | ✓ Full SQL                                    | REST APIs                                              |
| **Historical Data** | ✓ Full historical                                                                                                             | ✓ Full historical                             | Realtime                                               |
| **Authentication**  | Dune account, API key                                                                                                         | Warehouse credentials                         | Sim account, API key                                   |

## Query & Architecture

How each product handles queries and processes data under the hood.

|                  | <a href="/web-app/overview">Data Hub</a> | <a href="/datashare/datashare">Datashare</a> | <a href="https://sim.dune.com">Sim (Realtime APIs)</a> |
| ---------------- | ---------------------------------------- | -------------------------------------------- | ------------------------------------------------------ |
| **Query Infra**  | DuneSQL / Trino                          | Snowflake, BigQuery, Databricks              | N/A                                                    |
| **Query Speed**  | \~3 seconds                              | N/A                                          | N/A                                                    |
| **Engine**       | Custom Trino (Small, Medium, Large)      | N/A                                          | N/A                                                    |
| **Architecture** | OLAP, Delta parquet                      | OLAP, mostly Iceberg parquet                 | Real-time                                              |

## Data Coverage

What data is available and how fresh it is across each product.

|                 | <a href="/web-app/overview">Data Hub</a>                                                                                                                                                                                                                                                                                                                                                  | <a href="/datashare/datashare">Datashare</a>         | <a href="https://sim.dune.com">Sim (Realtime APIs)</a> |
| --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------- | ------------------------------------------------------ |
| **Freshness**   | EVM: \~1-15 min<br />Solana: \~1-5 min<br />Curated: \~1 hour                                                                                                                                                                                                                                                                                                                             | Hourly or daily                                      | \< 1 second                                            |
| **Blockchains** | <a href="/data-catalog/evm/overview">100+ chains</a>                                                                                                                                                                                                                                                                                                                                      | <a href="/data-catalog/evm/overview">100+ chains</a> | 60+ chains                                             |
| **Schemas**     | <a href="/data-catalog/evm/ethereum/raw/transactions">Raw</a>, <a href="/data-catalog/evm/ethereum/decoded/overview">Decoded</a>, Curated (<a href="/data-catalog/curated/dex-trades">DEX Trades</a>, <a href="/data-catalog/curated/prices">Prices</a>, <a href="/data-catalog/curated/token-transfers/overview">Token Transfers</a>, <a href="/data-catalog/curated/overview">more</a>) | Same as Data Hub                                     | Curated (Balances, Activity, DeFi, Token Info)         |

## Interface & Pricing

How you access each product and pricing.

|               | <a href="/web-app/overview">Data Hub</a>                                                                                                                              | <a href="/datashare/datashare">Datashare</a>                                                                                                                           | <a href="https://sim.dune.com">Sim (Realtime APIs)</a> |
| ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------ |
| **Interface** | <a href="https://dune.com">Dune App</a>, <a href="/api-reference/api-overview">Data API</a>, <a href="/api-reference/connectors/trino/overview">External BI Tools</a> | <a href="/datashare/datashare-bigquery">BigQuery</a>, <a href="/datashare/datashare-snowflake">Snowflake</a>, <a href="/datashare/datashare-databricks">Databricks</a> | REST APIs                                              |
| **Pricing**   | Credits (compute-based)                                                                                                                                               | Flat Subscription Fees                                                                                                                                                 | API Call Volume (CUs)                                  |

***

## Quick Selection Guide

<CardGroup>
  <Card title="Data Hub" icon="chart-line" href="/web-app/overview">
    **Best for:** Your primary onchain data warehouse, analytic workflows, and data transformations

    Full SQL access with 100+ chains, flexible schemas, and compute-based pricing
  </Card>

  <Card title="Datashare" icon="database" href="/datashare/datashare">
    **Best for:** Data warehouse integration and interoperability

    Direct access via Snowflake, BigQuery, or Databricks with full historical data
  </Card>

  <Card title="Sim (Realtime APIs)" icon="bolt" href="https://sim.dune.com">
    **Best for:** Building realtime wallets, portfolio trackers, and DeFi applications

    Sub-second response times with 60+ chains via REST APIs
  </Card>

  <Card title="Catalyst" icon="rocket" href="/catalyst/overview">
    **Best for:** Blockchain integration and data infrastructure

    Dune's toolkit for chains and protocols to get indexed and make their data accessible
  </Card>
</CardGroup>

<Note>
  **Why is Catalyst not in the comparison tables?** Catalyst is Dune's blockchain integration toolkit designed for chains and protocols, not end-user data consumption. It powers how blockchains get indexed into Dune rather than how users query data, so it serves a fundamentally different purpose than Data Hub, Datashare, and Sim (Realtime APIs).
</Note>


# Sim (Realtime APIs)
Source: https://docs.dune.com/docs/sim-real-time-apis





# Accounting, Audit & AML
Source: https://docs.dune.com/docs/use-cases/accounting-audit-aml

Power transaction monitoring, reconciliation, and compliance workflows with onchain data

Accounting, audit, and compliance teams depend on Dune for transaction monitoring, data reconciliation, financial reporting, and AML investigations across blockchain networks.

## Common Use Cases

<CardGroup>
  <Card title="Transaction Monitoring" icon="magnifying-glass-chart">
    Track onchain transactions, wallet flows, and cross-chain movements for compliance
  </Card>

  <Card title="Account Reconciliation" icon="scale-balanced">
    Verify token balances, staking positions, and DeFi holdings at any point in time
  </Card>

  <Card title="Financial Reporting" icon="file-invoice-dollar">
    Calculate realized gains/losses from DEX trades, staking rewards, and LP positions
  </Card>

  <Card title="Market Manipulation Detection" icon="triangle-exclamation">
    Pump and dump analysis, wash trading on DEXs, prediction market wash trading, LP manipulation
  </Card>

  <Card title="AML & Fraud Investigation" icon="shield-halved">
    Wallet clustering, sybil detection, sanctions screening, illicit fund tracing
  </Card>
</CardGroup>

## Who This Is For

<CardGroup>
  <Card title="Accounting & Finance" icon="calculator">
    Transaction monitoring, reconciliation, and financial reporting for crypto treasuries
  </Card>

  <Card title="Risk & Compliance" icon="shield-halved">
    AML/KYC workflows, sanctions screening, and regulatory compliance monitoring
  </Card>

  <Card title="Brokerages & Exchanges" icon="building-columns">
    Trade reconciliation, compliance reporting, and market surveillance
  </Card>

  <Card title="Custodians" icon="vault">
    Asset verification, balance audits, and custody reporting
  </Card>

  <Card title="Professional Services" icon="briefcase">
    Big 4 auditors, tax preparers, and consulting firms serving crypto clients
  </Card>

  <Card title="Public Sector" icon="landmark">
    Regulators, policymakers, and government agencies monitoring crypto markets
  </Card>
</CardGroup>

## How It Works

Dune provides the data infrastructure to power your accounting, audit, and compliance workflows:

<CardGroup>
  <Card title="Datashare" icon="database" href="/datashare/datashare">
    Stream Dune's complete blockchain dataset to Snowflake, BigQuery, or Databricks. Query historical balances, transactions, and DeFi activity in your existing compliance infrastructure.

    [Learn more →](/datashare/datashare)
  </Card>

  <Card title="Data Hub" icon="chart-line" href="/web-app/overview">
    Build custom queries and dashboards for transaction monitoring, balance verification, and compliance reporting with full SQL access.

    [Learn more →](/web-app/overview)
  </Card>

  <Card title="Data API" icon="code" href="/api-reference/api-overview">
    Integrate Dune data into your compliance systems, automate reporting workflows, and build custom monitoring pipelines.

    [Learn more →](/api-reference/api-overview)
  </Card>

  <Card title="Data Catalog" icon="book" href="/data-catalog/overview">
    Access raw transactions, decoded events, token transfers, DEX trades, and staking data across 100+ blockchains.

    [Learn more →](/data-catalog/overview)
  </Card>
</CardGroup>

## Case Studies

See how teams use Dune for compliance and monitoring:

<CardGroup>
  <Card title="CoW Protocol" icon="cow" href="https://dune.com/case-studies/cow-protocols-journey-into-automated-payments-and-understanding-user-behavior">
    CoW Protocol uses Dune queries and alerts to monitor malicious solver behavior, triggering Slack notifications when thresholds are met. They also automate weekly solver reward calculations with transparent, publicly verifiable data.
  </Card>
</CardGroup>

## Get Started

<CardGroup>
  <Card title="Contact Sales" icon="phone" href="https://dune.com/enterprise">
    Talk to our team about enterprise solutions for accounting, audit, and compliance
  </Card>

  <Card title="Datashare Trial" icon="database" href="/datashare/datashare-trial">
    Get started with a free trial of Dune Datashare
  </Card>
</CardGroup>


# Analytics
Source: https://docs.dune.com/docs/use-cases/analytics

Query, visualize, and analyze blockchain data with Data Hub and Datashare

Analytics teams use Dune's enriched data, query interface, and visualization layer to understand blockchain ecosystems, track protocol performance, analyze market trends, and generate insights from onchain activity.

## Common Use Cases

<CardGroup>
  <Card title="Protocol Metrics" icon="cube">
    Track TVL, user activity, revenue, and ecosystem growth for protocols and DAOs
  </Card>

  <Card title="Trading Intelligence" icon="chart-candlestick">
    Analyze DEX volumes, token flows, whale movements, and market trends
  </Card>

  <Card title="Stablecoin & Payments Intelligence" icon="coins">
    Flow analysis, payment tracking, peg stability, and adoption metrics
  </Card>

  <Card title="Ecosystem Benchmarking" icon="scale-balanced">
    Competitive analysis, market positioning, and chain comparisons
  </Card>

  <Card title="User Behavior Analytics" icon="users">
    Wallet activity patterns, cohort analysis, retention, and user journeys
  </Card>
</CardGroup>

## Who This Is For

<CardGroup>
  <Card title="Protocols & DAOs" icon="cube">
    Track TVL, user activity, and ecosystem metrics to inform product and governance decisions
  </Card>

  <Card title="L1s, L2s & Appchains" icon="layer-group">
    Monitor network health, adoption, developer activity, and ecosystem growth
  </Card>

  <Card title="Trading & Research Teams" icon="chart-candlestick">
    Analyze DEX volumes, token flows, and market dynamics for trading strategies
  </Card>

  <Card title="Investment Research" icon="magnifying-glass-chart">
    Track portfolio performance, analyze market trends, and identify opportunities
  </Card>

  <Card title="Stablecoins" icon="coins">
    Monitor flows, peg stability, adoption metrics, and payment volumes
  </Card>

  <Card title="Web3 Ecosystems & Growth" icon="rocket">
    Analyze competitive landscape, partnerships, and growth opportunities
  </Card>
</CardGroup>

## How It Works

Dune provides multiple products to power your analytics workflows:

<CardGroup>
  <Card title="Data Hub" icon="chart-line" href="/web-app/overview">
    Query blockchain data with SQL, build visualizations, and share dashboards with your team and stakeholders. Access 100+ chains with raw, decoded, and curated data.

    [Learn more →](/web-app/overview)
  </Card>

  <Card title="Datashare" icon="database" href="/datashare/datashare">
    Stream Dune's curated blockchain data directly to Snowflake, BigQuery, or Databricks for analysis in your existing data warehouse environment.

    [Learn more →](/datashare/datashare)
  </Card>

  <Card title="Data Catalog" icon="book" href="/data-catalog/overview">
    Explore 100+ blockchains with raw transactions, decoded events, and curated tables like DEX trades, token transfers, and prices.

    [Learn more →](/data-catalog/overview)
  </Card>

  <Card title="External BI Tools" icon="chart-mixed" href="/api-reference/connectors/trino/overview">
    Connect Hex, Metabase, DBeaver, PowerBI and other tools via Dune's Trino connector for analysis in your preferred environment.

    [Learn more →](/api-reference/connectors/trino/overview)
  </Card>
</CardGroup>

## Case Studies

See how leading teams use Dune for analytics:

<CardGroup>
  <Card title="Blockworks" icon="newspaper" href="https://dune.com/case-studies/blockworks">
    Blockworks Research powers institutional crypto research with Dune's Data API and dbt Connector, moving from concept to production in hours instead of weeks.
  </Card>

  <Card title="OP Labs (Optimism)" icon="layer-group" href="https://dune.com/case-studies/how-op-labs-use-dune-to-power-ecosystem-growth-and-transparency">
    OP Labs uses Dune to define North Star metrics, track developer activity, and evaluate grant program effectiveness with full transparency.
  </Card>

  <Card title="1inch" icon="shuffle" href="https://dune.com/case-studies/how-dune-helps-1inch-to-make-data-transparent-and-accessible">
    1inch makes DeFi data transparent and accessible with Dune dashboards, Spellbooks, and real-time API integrations across all their products.
  </Card>

  <Card title="Polygon" icon="hexagon" href="https://dune.com/case-studies/how-dune-enabled-polygon-labs-to-illuminate-community-engagement-and-rapidly-deliver-on-chain-insights">
    Polygon Labs achieved 75% faster turnaround on data insights, tracking Reddit Avatars launch and validator rewards with Dune.
  </Card>

  <Card title="CoW Protocol" icon="cow" href="https://dune.com/case-studies/cow-protocols-journey-into-automated-payments-and-understanding-user-behavior">
    CoW Protocol discovered they have the highest retention rates in the aggregator ecosystem and built automated solver rewards with Dune.
  </Card>
</CardGroup>

## Get Started

<CardGroup>
  <Card title="Create an Account" icon="user-plus" href="https://dune.com/auth/register">
    Sign up for free and start querying blockchain data in minutes
  </Card>

  <Card title="Quickstart Guide" icon="rocket" href="/quickstart">
    Learn the basics of querying and visualizing data on Dune
  </Card>
</CardGroup>


# Engineering
Source: https://docs.dune.com/docs/use-cases/engineering

Transform, model, and pipeline onchain data with dbt, Datashare, and APIs

Data engineering teams use Dune to build production data pipelines, transform blockchain data, and integrate onchain insights into their applications and workflows.

## Common Use Cases

<CardGroup>
  <Card title="Build Data Pipelines" icon="diagram-project">
    Create production-grade data models and transformation pipelines with dbt on Dune
  </Card>

  <Card title="Stream to Your Warehouse" icon="arrow-right-to-arc">
    Export blockchain data to Snowflake, BigQuery, or Databricks via Datashare
  </Card>

  <Card title="Programmatic Access" icon="code">
    Execute queries, manage data, and integrate Dune into your applications via Data API
  </Card>

  <Card title="Power Wallet & App Backends" icon="mobile">
    Build realtime wallet experiences and DeFi apps with sub-second latency via Sim APIs
  </Card>
</CardGroup>

## Who This Is For

<CardGroup>
  <Card title="Data Engineering Teams" icon="database">
    Build and maintain data pipelines, models, and transformations on blockchain data
  </Card>

  <Card title="Wallets & Apps Engineering" icon="mobile">
    Power wallet backends, portfolio trackers, and DeFi applications with onchain data
  </Card>

  <Card title="AI & Derived Analytics" icon="robot">
    Build ML models, derived datasets, and AI-powered analytics on blockchain data
  </Card>

  <Card title="Product Teams" icon="cube">
    Integrate onchain data into product workflows, dashboards, and customer-facing features
  </Card>
</CardGroup>

## How It Works

Dune provides multiple products to power your data engineering workflows:

<CardGroup>
  <Card title="dbt Connector" icon="hammer" href="/api-reference/connectors/dbt/overview">
    Build production data pipelines with dbt on Dune. Create models, run tests, and schedule transformations with full SQL access to blockchain data.

    [Learn more →](/api-reference/connectors/dbt/overview)
  </Card>

  <Card title="Datashare" icon="database" href="/datashare/datashare">
    Stream Dune's curated blockchain data directly to Snowflake, BigQuery, or Databricks. Integrate onchain data into your existing data warehouse.

    [Learn more →](/datashare/datashare)
  </Card>

  <Card title="Data API" icon="code" href="/api-reference/api-overview">
    Programmatically execute queries, manage data, and integrate Dune into your applications. Full REST API access for automation and integration.

    [Learn more →](/api-reference/api-overview)
  </Card>

  <Card title="Sim (Realtime APIs)" icon="bolt" href="https://docs.sim.dune.com">
    Build realtime applications with sub-second latency. Access balances, transactions, DeFi positions, and more via REST APIs.

    [Explore Sim Docs →](https://docs.sim.dune.com)
  </Card>
</CardGroup>

## Case Studies

See how engineering teams build with Dune:

<CardGroup>
  <Card title="Blockworks" icon="newspaper" href="https://dune.com/case-studies/blockworks">
    Blockworks builds data pipelines with dbt Connector and Data API, exporting aggregated data to their Postgres environment seamlessly.
  </Card>

  <Card title="CoW Protocol" icon="cow" href="https://dune.com/case-studies/cow-protocols-journey-into-automated-payments-and-understanding-user-behavior">
    CoW Protocol automates weekly solver rewards using Dune's data upload, API, and query capabilities to calculate and distribute payments.
  </Card>
</CardGroup>

## Get Started

<CardGroup>
  <Card title="Quickstart Guide" icon="rocket" href="/quickstart">
    Learn the basics of querying and working with data on Dune
  </Card>

  <Card title="dbt Setup Guide" icon="hammer" href="/api-reference/connectors/dbt/overview">
    Get started with dbt on Dune for data transformations
  </Card>

  <Card title="Sim Documentation" icon="bolt" href="https://docs.sim.dune.com">
    Build realtime apps with Sim APIs
  </Card>
</CardGroup>


# Enterprise Plan
Source: https://docs.dune.com/enterprise/data-hub/overview

Enterprise features for crypto native or crypto adjacent teams with advanced security, unlimited resources, and dedicated support.

Dune's Enterprise plan is designed for crypto native or crypto adjacent teams that need advanced security, higher limits, and dedicated support. Enterprise unlocks capabilities not available on Free, Analyst, or Plus plans.

<Card title="Contact Sales" icon="phone" href="https://dune.com/enterprise">
  Talk to our team about Enterprise pricing and features
</Card>

## Enterprise-Only Features

These features are **exclusively available** on the Enterprise plan:

### Security & Access Control

<CardGroup>
  <Card title="Organizations" icon="building" href="/web-app/organizations">
    Multiple Enterprise teams under one subscription, shared usage, and centralized admin
  </Card>

  <Card title="Okta SSO" icon="key" href="/web-app/okta-sso">
    Configure Okta SSO (OIDC) for secure team authentication
  </Card>

  <Card title="Domain-Restricted SSO" icon="google" href="/web-app/google-sso-domain-restriction">
    Restrict Google SSO to your organization's email domain
  </Card>

  <Card title="Granular Permissions" icon="lock">
    Fine-grained access control for queries, dashboards, and data
  </Card>

  <Card title="Private Query Views" icon="eye-slash">
    Control who can view your query results and execution history
  </Card>
</CardGroup>

### Data & Storage

<CardGroup>
  <Card title="Unlimited Storage" icon="database">
    200 GB and up for data uploads and materialized views
  </Card>

  <Card title="Private Data Uploads" icon="upload">
    Upload proprietary data with full privacy controls
  </Card>

  <Card title="Private Materialized Views" icon="layer-group">
    Create materialized views that are private to your team
  </Card>

  <Card title="dbt Connector" icon="hammer" href="/api-reference/connectors/dbt/overview">
    Build production data pipelines with dbt on Dune
  </Card>
</CardGroup>

### Performance & Limits

| Feature                             | Plus    | Enterprise |
| ----------------------------------- | ------- | ---------- |
| **Credits per month**               | 25,000  | Custom     |
| **Price per credit**                | \$0.014 | Custom     |
| **Total data storage**              | 15 GB   | 200 GB+    |
| **Concurrent SQL queries**          | 10      | Custom     |
| **Private queries**                 | 100     | Custom     |
| **Private dashboards**              | 10      | Custom     |
| **Datapoints per credit (API/CSV)** | 5,000   | Custom     |
| **API calls per minute**            | 200     | Custom     |
| **Alerts**                          | 5       | Custom     |

### Additional Benefits

* **Volume Discounts** — Best pricing on queries and exports
* **Hide Watermark** — Remove Dune branding from embedded dashboards
* **No Expiration** — Scheduled queries and dashboards never expire
* **Dedicated Support** — Direct access to the Dune team via Slack, Telegram, or email

## Get Started with Enterprise

<CardGroup>
  <Card title="Contact Sales" icon="phone" href="https://dune.com/enterprise">
    Talk to our team about custom pricing and implementation
  </Card>

  <Card title="Compare Plans" icon="table" href="https://dune.com/pricing">
    See the full feature comparison across all plans
  </Card>
</CardGroup>


# Datashare Enterprise
Source: https://docs.dune.com/enterprise/datashare/overview

Enterprise data delivery with SLAs and dedicated support.

# Datashare Enterprise

Enterprise-grade data delivery for organizations requiring guaranteed data freshness and dedicated support.

<Card title="Contact Sales" icon="phone" href="https://dune.com/enterprise">
  Talk to our team about Datashare Enterprise pricing and features
</Card>

## Features

* **SLA-backed Data Freshness** - Guaranteed data delivery times
* **Custom Data Pipelines** - Tailored data transformations
* **Dedicated Support** - Priority account management
* **dbt to Datashare** - Publish dbt-managed transformation outputs from Dune into your warehouse with [dbt to Datashare](/api-reference/connectors/dbt/datashares)
* **Volume Pricing** - Enterprise pricing for high-volume usage


# Dune Docs
Source: https://docs.dune.com/index

Dune is the onchain data platform for analytics, data engineering, and application development.

Our mission is to make crypto data accessible. We provide the infrastructure, data, and tools so your team can focus on insights and products, not wrangling data pipelines.

With 100+ blockchains indexed, 3+ petabytes of data, and battle-tested by 1,500+ paying customers, Dune is your onchain data warehouse. Whether you're building dashboards, powering applications, streaming data to your existing warehouse, or running transformation pipelines, any time you need to read aggregated data from the blockchain, Dune can serve it.

## Products

Dune offers multiple products to meet your data needs, whether you're building dashboards, powering applications, need a data warehouse, or integrating onchain data into your warehouse.

<CardGroup>
  <Card title="Data Hub" icon="chart-line" href="/web-app/overview">
    Query, visualize, and share blockchain data with our web-based SQL editor and dashboard builder
  </Card>

  <Card title="Datashare" icon="database" href="/datashare/datashare">
    Stream Dune's blockchain data directly to Snowflake, BigQuery, or Databricks
  </Card>

  <Card title="Sim (Realtime APIs)" icon="bolt" href="https://docs.sim.dune.com">
    Build applications with sub-second latency APIs for balances, transactions, and DeFi positions
  </Card>

  <Card title="Catalyst" icon="rocket" href="/catalyst/overview">
    Dune's blockchain integration toolkit for chains and protocols
  </Card>
</CardGroup>

### APIs & Connectors

Beyond the core products, Dune offers APIs and connectors that extend how you can access and work with blockchain data programmatically.

<CardGroup>
  <Card title="Data API" icon="code" href="/api-reference/api-overview">
    Execute queries, retrieve results, and manage data programmatically.
  </Card>

  <Card title="dbt Connector" icon="hammer" href="/api-reference/connectors/dbt/overview">
    Build production data pipelines with dbt on Dune.
  </Card>

  <Card title="External BI Tools" icon="chart-mixed" href="/api-reference/connectors/trino/overview">
    Connect to Hex, Metabase, DBeaver, PowerBI, and other BI tools you already use to query Dune data.
  </Card>
</CardGroup>

For a detailed comparison of products, data freshness, and pricing, see the [Products Overview](/docs/product-comparison) page.

## Use Cases

Explore how teams use Dune to solve real business problems.

<CardGroup>
  <Card title="Analytics" icon="chart-line" href="/docs/use-cases/analytics">
    Query, visualize, and analyze blockchain data for protocols, trading, and ecosystems

    **For:** Protocols, L1s, L2s, Appchains, Trading Teams, Researchers, VCs
  </Card>

  <Card title="Engineering" icon="code" href="/docs/use-cases/engineering">
    Transform, model, and pipeline onchain data into your applications and workflows

    **For:** Data Engineers, Product Teams, App Developers
  </Card>

  <Card title="Accounting, Audit & AML" icon="scale-balanced" href="/docs/use-cases/accounting-audit-aml">
    Transaction monitoring, reconciliation, and compliance workflows

    **For:** Finance Teams, Compliance, Auditors, Regulators
  </Card>

  <Card title="Stream to Your Warehouse" icon="arrow-right-to-arc" href="/datashare/datashare">
    Export blockchain data to Snowflake, BigQuery, or Databricks for unified analytics

    **For:** Data Engineers, Data Scientists, Analytics Teams
  </Card>

  <Card title="Transform Your Data" icon="wand-magic-sparkles" href="/api-reference/connectors/dbt/overview">
    Build production data pipelines and models with dbt on Dune

    **For:** Data Engineers, Data Scientists, Product Teams
  </Card>

  <Card title="Build Wallet Applications" icon="mobile" href="https://docs.sim.dune.com">
    Power wallets, portfolio trackers, and DeFi apps with realtime blockchain data

    **For:** Developers, Product Teams, dApp Builders
  </Card>
</CardGroup>

## Resources

<Card title="Learning Resources & Support" icon="book-open" href="/resources/learning/video-tutorials">
  Video tutorials, guides, community support, and more to help you get the most out of Dune →
</Card>


# Migrating from Flipside to Dune
Source: https://docs.dune.com/learning/flipside-migration-guide

A comprehensive guide for Flipside users transitioning to Dune, including table mappings and SQL syntax differences

# Migrating from Flipside to Dune

With the recent shutdown of Flipside Creator Studio, we extend a warm welcome to all Flipside users exploring Dune. We understand that migrating your queries and workflows can be a challenging task. This guide is designed to help you transition smoothly by mapping Flipside's data tables to Dune's and highlighting the key differences between their respective SQL query engines.

Dune offers a powerful platform for blockchain analytics, powered by a community of thousands of creators. We're excited to have you join us!

## Key Differences at a Glance

For a quick overview, here are some of the main differences between the Flipside and Dune platforms:

| Feature            | Flipside                | Dune                                                                                 |
| ------------------ | ----------------------- | ------------------------------------------------------------------------------------ |
| **Query Engine**   | Snowflake SQL           | Dune SQL (based on Trino)                                                            |
| **Table Naming**   | `database.schema.table` | `schema.table` (e.g., `tokens.transfers`)                                            |
| **Data Structure** | mostly raw tables       | Layered approach: Raw, Decoded, and Curated Data                                     |
| **Community**      | -                       | Active Discord, DuneCon, Bounties, and a vast library of community-generated queries |
| **API Access**     | Yes                     | Yes, with a generous free tier to get you started                                    |

***

## Table Mappings: Flipside to Dune

Below is a comprehensive mapping of Flipside's tables to their Dune equivalents. We've done our best to find the closest match. In Dune, data is often more modular, so a single Flipside table might map to multiple Dune tables or require a `JOIN` operation to achieve the same result. Use the search bar in Dune's data explorer to find these tables.

| Flipside Table                  | Dune Table(s)                                                                                                                                                               | Migration Notes                                                                                                                                                                                                                                                  |
| :------------------------------ | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `EZ_DEPOSITS`                   | `beacon.deposits`                                                                                                                                                           | Contains beacon chain deposit data. The mapping is straightforward. Both tables serve the same purpose of tracking deposits into the consensus layer.                                                                                                            |
| `EZ_WITHDRAWALS`                | `beacon.withdrawals`                                                                                                                                                        | Contains beacon chain withdrawal data. This is a direct one-to-one mapping.                                                                                                                                                                                      |
| `FACT_ATTESTATIONS`             | `beacon.attestations`                                                                                                                                                       | Holds details on validator attestations. This is a direct one-to-one mapping.                                                                                                                                                                                    |
| `FACT_BLOB_SIDECARS`            | `beacon.blobs`                                                                                                                                                              | Contains data on blob sidecars from the beacon chain RPC. This is a direct one-to-one mapping.                                                                                                                                                                   |
| `FACT_BLOCKS`                   | `beacon.blocks`                                                                                                                                                             | Contains consensus layer block data. This is a direct one-to-one mapping for raw block information.                                                                                                                                                              |
| `FACT_DEPOSITS`                 | `beacon.deposits`                                                                                                                                                           | Contains beacon chain deposit data. This is a direct mapping.                                                                                                                                                                                                    |
| `FACT_VALIDATORS`               | `beacon.validators`                                                                                                                                                         | Holds information about consensus layer validators. This is a direct one-to-one mapping.                                                                                                                                                                         |
| `FACT_VALIDATOR_BALANCES`       | `beacon.validator_day_summaries`                                                                                                                                            | Provides validator balance information. **Note the difference in granularity:** Flipside's table offered raw balance data, whereas Dune's `validator_day_summaries` provides balances aggregated by day, which is more efficient for daily trend analysis.       |
| `FACT_WITHDRAWALS`              | `beacon.withdrawals`                                                                                                                                                        | Details withdrawals from the beacon chain. This is a direct one-to-one mapping.                                                                                                                                                                                  |
| `DIM_ORACLE_FEEDS`              | `chainlink_ethereum.oracle_addresses`                                                                                                                                       | Provides metadata for Chainlink oracles. **Note:** Replace `ethereum` with your target chain (e.g., `chainlink_optimism.oracle_addresses` for Optimism).                                                                                                         |
| `EZ_ORACLE_FEEDS`               | `chainlink.price_feeds`                                                                                                                                                     | Contains Chainlink price feed data. Dune's `chainlink.price_feeds` is a curated table that provides similar data, often with a more standardized schema across different chains.                                                                                 |
| `FACT_ORACLE_FEEDS`             | `chainlink.price_feeds`                                                                                                                                                     | Contains Chainlink price feed data. This maps directly to Dune's curated `chainlink.price_feeds` table.                                                                                                                                                          |
| `DIM_CONTRACTS`                 | `ethereum.contracts`                                                                                                                                                        | Contains metadata for deployed contracts. **Note:** Replace `ethereum` with your target chain. Dune also has a cross-chain `evms.contracts` table for multi-chain analysis.                                                                                      |
| `DIM_CONTRACT_ABIS`             | `ethereum.contracts`                                                                                                                                                        | Holds contract ABI data. Flipside had a separate table, but Dune integrates ABI information directly into the contracts table.                                                                                                                                   |
| `DIM_EVENT_SIGNATURES`          | `abi.signatures`; `decoding.evm_signatures`                                                                                                                                 | Contains event signatures for decoding. Dune provides `abi.signatures` for general signatures and `decoding.evm_signatures` for those actively used in decoding EVM data.                                                                                        |
| `DIM_FUNCTION_SIGNATURES`       | `abi.signatures`; `decoding.evm_signatures`                                                                                                                                 | Contains function signatures for decoding. Similar to event signatures, Dune separates these into general and EVM-specific tables.                                                                                                                               |
| `DIM_LABELS`                    | `labels.addresses`; `labels.owner_addresses`; `labels.owner_details`                                                                                                        | Contains address labels. **Note the structural difference:** Flipside used a single table, whereas Dune employs a more granular, multi-table structure that separates labels for addresses from labels for entities/owners. You may need to `JOIN` these tables. |
| `EZ_BALANCE_DELTAS`             | `balances_ethereum.erc20_day`; `ethereum.traces`                                                                                                                            | Provides token and native asset balance changes. On Dune, you can calculate balance deltas from daily balance tables or derive them from transfer tables like `erc20_ethereum.evt_Transfer` and `ethereum.traces` (`value > 0`).                                 |
| `EZ_CURRENT_BALANCES`           | `balances_ethereum.erc20_latest`                                                                                                                                            | Provides current wallet balances. Dune's `balances_ethereum.erc20_latest` table provides the most recent balance for tokens, similar to Flipside's convenience table.                                                                                            |
| `EZ_NATIVE_TRANSFERS`           | `tokens.transfers`                                                                                                                                                          | This is a direct mapping to the `tokens.transfers` table.                                                                                                                                                                                                        |
| `EZ_SNAPSHOT`                   | `dune.shot.dataset_follows`<br />`dune.shot.dataset_proposals_view`<br />`dune.shot.dataset_spaces_view`<br />`dune.shot.dataset_users`<br />`dune.shot.dataset_votes_view` | Contains off-chain Snapshot voting data. **Note the structural difference:** Flipside aggregated this into a single table. Dune ingests Snapshot's data into multiple, more granular tables that you will need to `JOIN` using proposal or space IDs.            |
| `EZ_TOKEN_TRANSFERS`            | `erc20_ethereum.evt_Transfer`                                                                                                                                               | Contains ERC-20 token transfer events. Dune's decoded event tables provide the raw transfer data. For aggregated, cleaned data across all chains, use the curated `tokens.transfers` table.                                                                      |
| `FACT_BLOCKS`                   | `ethereum.blocks`                                                                                                                                                           | Provides execution-layer block data. For raw block data, `ethereum.blocks` is a direct match. For aggregated metrics like daily gas fees, Dune offers pre-computed tables in the `dune` schema.                                                                  |
| `FACT_CONTRACT_READS`           | Decoded call tables (e.g., `aave_v3_ethereum.AToken_call_balanceOf`)                                                                                                        | Contains data from contract reads. On Dune, this corresponds to decoded call tables for specific protocols. Use the data explorer to find the specific contract and function you need.                                                                           |
| `FACT_DECODED_EVENT_LOGS`       | Decoded event tables (e.g., `erc20_ethereum.evt_Transfer`)                                                                                                                  | Contains decoded event logs. This is a core feature of Dune. Instead of one large table, Dune has individual decoded event tables for popular contracts, which are much more efficient to query.                                                                 |
| `FACT_DECODED_TRACES`           | Decoded call tables (e.g., `uniswap_v3_ethereum.Factory_call_createPool`)                                                                                                   | Contains decoded trace/call data. Similar to events, Dune provides decoded call tables for specific function calls on popular contracts.                                                                                                                         |
| `FACT_ETH_BALANCES`             | `balances_ethereum.native_day`                                                                                                                                              | Contains historical ETH balances. Dune's daily balance tables offer daily snapshots of balances, which is often more performant than querying raw transfer data to reconstruct balances.                                                                         |
| `FACT_EVENT_LOGS`               | `ethereum.logs`                                                                                                                                                             | Contains raw, undecoded event logs. This is a direct one-to-one mapping.                                                                                                                                                                                         |
| `FACT_TOKEN_BALANCES`           | `balances_ethereum.erc20_day`                                                                                                                                               | Contains historical token balances. Dune's daily balance tables offer daily snapshots, providing a more efficient way to query historical balances than reconstructing from transfers.                                                                           |
| `FACT_TOKEN_TRANSFERS`          | `erc20_ethereum.evt_Transfer`                                                                                                                                               | Contains raw ERC-20 token transfer events. This maps to the raw decoded event table on Dune for the `Transfer` event on ERC-20 contracts.                                                                                                                        |
| `FACT_TRANSACTIONS`             | `ethereum.transactions`                                                                                                                                                     | Contains execution-layer transaction data. This is a direct one-to-one mapping.                                                                                                                                                                                  |
| `DIM_DEX_LIQUIDITY_POOLS`       | `dex.pools`                                                                                                                                                                 | Contains information on DEX liquidity pools. Dune's `dex.pools` curated table aims to provide standardized pool data across a wide variety of DEXs.                                                                                                              |
| `EZ_BRIDGE_ACTIVITY`            | `bridge.flows`                                                                                                                                                              | Aggregates bridge deposit and withdrawal activity. Dune's `bridge.flows` is a comprehensive curated table that covers a wide array of bridging protocols with a standardized schema.                                                                             |
| `EZ_DEX_SWAPS`                  | `dex.trades`                                                                                                                                                                | Contains DEX swap events. **This is a major improvement on Dune.** The `dex.trades` curated table is a powerful dataset that aggregates and standardizes swap data from a much wider range of protocols than Flipside's table.                                   |
| `EZ_LENDING_BORROWS`            | `lending.borrows`                                                                                                                                                           | Contains asset borrowing events from lending protocols. Dune's `lending.borrows` curated table aggregates this data across many protocols into a standardized format.                                                                                            |
| `EZ_LENDING_DEPOSITS`           | `lending.supplies`                                                                                                                                                          | Contains asset deposit events into lending protocols. Dune's `lending.supplies` curated table aggregates this data across many protocols into a standardized format.                                                                                             |
| `EZ_LENDING_FLASHLOANS`         | `lending.flashloans`                                                                                                                                                        | Contains flash loan transactions. Dune's `lending.flashloans` curated table aggregates this data across protocols that support flash loans.                                                                                                                      |
| `EZ_LENDING_LIQUIDATIONS`       | `lending.liquidations`                                                                                                                                                      | Contains collateral liquidation events. Dune's `lending.liquidations` curated table aggregates liquidation data across multiple lending protocols.                                                                                                               |
| `EZ_LENDING_REPAYMENTS`         | `lending.repayments`                                                                                                                                                        | Contains loan repayment events. Dune's `lending.repayments` curated table aggregates this data across multiple lending protocols.                                                                                                                                |
| `EZ_LENDING_WITHDRAWS`          | `lending.withdraws`                                                                                                                                                         | Contains asset withdrawal events from lending protocols. Dune's `lending.withdraws` curated table aggregates this data across many protocols.                                                                                                                    |
| `EZ_LIQUID_STAKING_DEPOSITS`    | `staking_ethereum.deposits`                                                                                                                                                 | Contains liquid staking deposit events. Dune's liquid staking tables aggregate data from a wide range of liquid staking providers.                                                                                                                               |
| `EZ_LIQUID_STAKING_WITHDRAWALS` | `staking_ethereum.withdrawals`                                                                                                                                              | Contains liquid staking withdrawal events. Dune's liquid staking tables aggregate data from various liquid staking providers.                                                                                                                                    |
| `EZ_ENS_DOMAINS`                | `labels.ens`                                                                                                                                                                | Contains data on ENS domain registrations. This maps well to Dune's `labels.ens` table.                                                                                                                                                                          |
| `FACT_DAO_VOTES`                | `dao.votes`                                                                                                                                                                 | Contains DAO voting records. Dune's `dao.votes` curated table aims to standardize voting data across different DAO frameworks.                                                                                                                                   |
| `FACT_REGISTRATIONS`            | `ens.view_registrations`                                                                                                                                                    | Contains ENS registration records. This is a direct mapping.                                                                                                                                                                                                     |
| `FACT_RENEWALS`                 | `ens.view_renewals`                                                                                                                                                         | Contains ENS domain renewal records. This is a direct mapping.                                                                                                                                                                                                   |
| `FACT_TRANSFERS`                | `tokens.transfers`                                                                                                                                                          | Contains token transfer events. Dune's `tokens.transfers` is a curated table that provides a standardized format for all token transfers.                                                                                                                        |
| `EZ_GOVERNANCE_VOTES`           | `governance.votes`                                                                                                                                                          | Contains records of governance votes. Dune's `governance.votes` curated table covers multiple protocols, including Maker.                                                                                                                                        |
| `FACT_CAT_BITE`                 | `maker_ethereum.cat_evt_bite`                                                                                                                                               | Contains MakerDAO liquidation events. This is a direct mapping to the raw event table in Dune.                                                                                                                                                                   |
| `DIM_NFT_COLLECTION_METADATA`   | `nft.collections`                                                                                                                                                           | Contains metadata for NFT collections. Dune's `nft.collections` curated table provides metadata for a vast number of NFT collections.                                                                                                                            |
| `EZ_NFT_MINTS`                  | `nft.mints`                                                                                                                                                                 | Contains NFT mint events. Dune's `nft.mints` is a curated table that identifies and standardizes minting events across various standards.                                                                                                                        |
| `EZ_NFT_SALES`                  | `nft.trades`                                                                                                                                                                | Contains NFT sale events. **This is another major improvement on Dune.** The `nft.trades` curated table is a powerful abstraction that aggregates sales across dozens of marketplaces into a single, clean table.                                                |
| `EZ_NFT_TRANSFERS`              | `nft.transfers`                                                                                                                                                             | Contains NFT transfer events. Dune's `nft.transfers` curated table is the standard place to find all ERC721 and ERC1155 transfers.                                                                                                                               |
| `EZ_ASSET_METADATA`             | `tokens.erc20`, `tokens.nft`                                                                                                                                                | Contains asset metadata. Dune separates metadata for fungible (`tokens.erc20`) and non-fungible (`tokens.nft`) tokens into dedicated, curated tables.                                                                                                            |
| `EZ_PRICES_HOURLY`              | `prices.hour`                                                                                                                                                               | Provides hourly token prices. This is a direct mapping to Dune's hourly prices table. Dune also offers `prices.usd_daily` and `prices.usd_latest`.                                                                                                               |
| `EZ_SWAPS`                      | `dex.trades`                                                                                                                                                                | Contains DEX swap events. This maps to Dune's comprehensive `dex.trades` curated table, which covers a much wider array of DEXs.                                                                                                                                 |
| `DIM_DATES`                     | `utils.days`, `utils.hours`, `utils.minutes`                                                                                                                                | Provides a table of dates for time-series analysis. Dune offers several utility tables for different time granularities to simplify `JOIN` operations.                                                                                                           |
| `FACT_TRACES`                   | `ethereum.traces`                                                                                                                                                           | Contains raw trace data for internal contract calls. This is a direct one-to-one mapping.                                                                                                                                                                        |

***

## Migrating Queries: From Snowflake to Dune SQL (Trino)

The most significant adjustment you'll make when migrating from Flipside is the query engine. Flipside utilized Snowflake's SQL dialect, whereas Dune is powered by **Dune SQL**, which is based on **Trino** (formerly PrestoSQL). While both are standards-compliant, Trino has its own flavor and functions that differ from Snowflake.

Let's walk through the most common changes you'll need to make to your queries.

### 1. The `0x` Prefix and Byte Arrays: A Critical Difference

In Dune, blockchain addresses, transaction hashes, and other raw byte data are stored as `VARBINARY` types, not simple strings. When you filter by or insert these values in your queries, you **must** prefix them with `0x`. This is one of the most common tripping points for new users.

**Dune SQL (Correct):**

```sql theme={null}
-- Filtering for transactions to a specific address
SELECT *
FROM ethereum.transactions
WHERE "to" = 0x742d35Cc6634C0532925a3b844Bc454e4438f44e -- Uniswap V2: Router 2
```

**Flipside/Snowflake (and incorrect in Dune):**

```sql theme={null}
-- This will fail or return no results in Dune
SELECT *
FROM ethereum.transactions
WHERE "to" = '0x742d35Cc6634C0532925a3b844Bc454e4438f44e'
```

<Note>
  **Pro tip:** When copying addresses from block explorers, they typically include the `0x` prefix. In Dune, simply remove the quotes around the address to use it as a `VARBINARY` literal.
</Note>

### 2. Common Syntax Adjustments

Here are some of the most frequent syntax adjustments you'll encounter.

#### Identifier Quoting

This should be an easy transition. Both Snowflake and Trino follow the ANSI SQL standard and use double quotes (`"`) to quote identifiers (e.g., column names with spaces or reserved words like `"from"` or `"to"`). Your quoting syntax will likely not need to change.

* **Snowflake/Dune SQL (Trino):** `SELECT "from", "to" FROM "my_table";`

#### Data Type Casting

Snowflake commonly uses `::` for casting. Dune SQL uses the ANSI SQL standard `CAST(column AS TYPE)`.

* **Snowflake:** `SELECT '123'::integer, '2023-01-01'::date;`
* **Dune SQL:** `SELECT CAST('123' AS integer), CAST('2023-01-01' AS date);`

#### Accessing JSON Data

Accessing nested data in JSON objects requires specific functions in Trino. While Snowflake uses a colon (`:`), Trino uses `json_extract_scalar`.

* **Snowflake:** `SELECT my_json_column:key::string FROM my_table;`
* **Dune SQL (Trino):** `SELECT json_extract_scalar(my_json_column, '$.key') FROM my_table;`

### 3. Key Function and Pattern Changes

#### Flattening Arrays with `UNNEST`

To un-nest array elements into their own rows, Snowflake uses `LATERAL FLATTEN()`. The Trino equivalent is `UNNEST`.

**Snowflake:**

```sql theme={null}
SELECT t.id, value:name::string
FROM my_table t,
LATERAL FLATTEN(input => t.my_json_array);
```

**Dune SQL (Trino):**

```sql theme={null}
SELECT t.id, item.name
FROM my_table t
CROSS JOIN UNNEST(t.my_json_array) AS t(item)
```

#### Filtering Window Functions (Replacing `QUALIFY`)

Snowflake's `QUALIFY` clause is a convenient way to filter the results of a window function. `QUALIFY` is not available in Dune SQL. The standard approach is to use a subquery or a Common Table Expression (CTE), which works perfectly in Trino.

**Snowflake:**

```sql theme={null}
SELECT *
FROM my_table
QUALIFY ROW_NUMBER() OVER (PARTITION BY id ORDER BY timestamp DESC) = 1;
```

**Dune SQL (Trino):**

```sql theme={null}
WITH ranked_rows AS (
    SELECT *,
        ROW_NUMBER() OVER (PARTITION BY id ORDER BY timestamp DESC) as rn
    FROM my_table
)
SELECT * FROM ranked_rows
WHERE rn = 1;
```

### 4. Common Migration Examples

Here are some practical examples of migrating common Flipside query patterns to Dune:

#### Example 1: Daily DEX Volume Analysis

**Flipside Pattern:**

```sql theme={null}
SELECT 
    block_timestamp::date as date,
    SUM(amount_usd) as volume_usd
FROM ethereum.core.ez_dex_swaps
WHERE block_timestamp >= '2024-01-01'::date
GROUP BY 1
ORDER BY 1;
```

**Dune Equivalent:**

```sql theme={null}
SELECT 
    DATE_TRUNC('day', block_time) as date,
    SUM(amount_usd) as volume_usd
FROM dex.trades
WHERE block_time >= CAST('2024-01-01' AS date)
    AND blockchain = 'ethereum'
GROUP BY 1
ORDER BY 1;
```

#### Example 2: Token Balance Analysis

**Flipside Pattern:**

```sql theme={null}
SELECT 
    user_address,
    symbol,
    current_bal
FROM ethereum.core.ez_current_balances
WHERE contract_address = '0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48'::string;
```

**Dune Equivalent:**

```sql theme={null}
SELECT 
    address as user_address,
    symbol,
    amount_raw / POW(10, decimals) as current_bal
FROM balances_ethereum.erc20_latest
WHERE contract_address = 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48; -- USDC
```

### 5. Query Performance Tips

Many Flipside tables encouraged filtering by `block_timestamp::date` for performance. In Dune, many raw and curated tables are physically partitioned by date-based columns (like `block_day` or `block_time`). Always add a filter on these partitioned columns where available, as it can dramatically speed up your queries by reducing the amount of data scanned.

You can find partition keys in the schema browser in the query editor.

**Performance Best Practices:**

* Always filter by `block_time` or `block_date` when available
* Use the curated tables (like `dex.trades`, `nft.trades`) instead of raw tables when possible
* Limit your date ranges to what you actually need for analysis
* Use `LIMIT` clauses during development to avoid scanning large datasets

***

## Understanding Dune's Data Platform

Dune's approach to data is layered, providing different levels of abstraction to make analysis easier:

1. **Raw Data:** Raw, unprocessed data from the blockchain (e.g., `ethereum.blocks`, `ethereum.transactions`). This is your source of truth.
2. **Decoded Data:** Raw data is decoded into human-readable tables. For example, contract events are decoded into tables like `aave_v3_ethereum.Supply`. This saves you the effort of dealing with logs and topics.
3. **Curated Data:** These are higher-level abstractions built and maintained by the community. Tables like `dex.trades` or `nft.trades` aggregate data across multiple protocols, making cross-platform analysis simple.

We encourage you to explore the [data catalog](/data-catalog/overview) in the Dune app to discover the wealth of datasets available.

## Common Migration Challenges and Solutions

### Challenge 1: Missing Convenience Tables

**Issue:** Flipside provided many "EZ\_" convenience tables that aggregated complex data.
**Solution:** Dune's curated tables (like `dex.trades`, `nft.trades`) often provide even better aggregations. If a specific convenience table doesn't exist, you can often recreate it using raw or decoded data.

### Challenge 2: Different Table Schemas

**Issue:** Column names and data types may differ between platforms.
**Solution:** Use Dune's data explorer to examine table schemas. The `DESCRIBE` command can also help: `DESCRIBE dex.trades;`

### Challenge 3: Cross-Chain Analysis

**Issue:** Flipside often had separate databases per chain.
**Solution:** Dune's curated tables often include a `blockchain` column, making cross-chain analysis much easier. Simply add `WHERE blockchain IN ('ethereum', 'polygon')` to your queries.

## Need More Help?

We know migrating can be tough, but you're not alone. Here are some resources to help you on your journey:

* **Dune Documentation:** [docs.dune.com](https://dune.com/docs/)
* **Dune Discord:** Join our [Discord server](https://discord.gg/dune) to ask questions and connect with thousands of other crypto data analysts.
* **Find a Query:** Fork one of the 600,000+ public queries on Dune to get a head start.
* **Data Catalog:** Explore our comprehensive [data catalog](/data-catalog/overview) to understand available datasets.
* **Query Examples:** Check out our [quickstart guide](/quickstart) for hands-on examples.
* \*\*Onboarding: \*\*Fill out this [onboarding form](https://forms.gle/G3x9mWmW3AYauu6FA) and we’ll schedule a live session to help you.

Welcome to Dune! We can't wait to see what you build.


# Create your first query
Source: https://docs.dune.com/learning/how-tos/create-your-first-query

Learn to analyze daily DEX trading volumes across different blockchains

New to Dune? Let's start your analytics journey by creating an insightful query that analyzes daily DEX trading volumes across different blockchains. This guide will teach you the basics while delivering practical insights about DeFi trading activity.

## Getting Started

**Create a New Query**: Head over to [Create New Query](https://dune.com/queries) to begin. Dune uses DuneSQL, a SQL dialect that is compatible with TrinoSQL. It is a fairly vanilla SQL dialect, but there are some nuances you will eventually encounter. If you are not familiar with SQL, you can learn the basics [here](https://www.w3schools.com/sql/).

## Choosing the Right Table

Choosing the right table is the first step to creating a successful query. You can find the table you need in the [Data Catalog](/data-catalog).

1. **Understanding curated data**: Instead of working with complex raw blockchain data, we'll use Dune's curated data - a collection of pre-built, analytics-ready tables. Curated data standardizes data across chains and makes analysis much easier.

2. **The Perfect Table**: For DEX trading analysis, we'll use the [`dex.trades`](data-catalog/curated/dex-trades/evm/dex-trades) table. This table contains standardized trading data across multiple DEXes and blockchains.

## Building Your Query Step by Step

Let's analyze DEX trading activity across different blockchains. We'll start simple and build up our analysis:

1. **Select Key Metrics**: For our DEX analysis, we'll track:
   * Block date (to see trends over time)
   * Blockchain (to compare activity across networks)
   * Trading volume in USD
   * Number of trades

Here's our query:

```sql theme={null}
SELECT
  block_date,
  blockchain,
  COUNT(*) as number_of_trades,
  SUM(amount_usd) as trading_volume_usd
FROM dex.trades
WHERE
  block_date >= NOW() - INTERVAL '30' day
GROUP BY
  1, 2
ORDER BY
  1 DESC, 4 DESC
```

<DuneEmbed />

## Understanding the Query Components

Each part of this query helps us analyze DEX activity:

* `block_date`: Groups all trades into daily buckets
* `blockchain`: Helps us compare activity across Ethereum, Polygon, Arbitrum, etc.
* `COUNT(*)`: Gives us the trading frequency
* `SUM(amount_usd)`: Shows the total value traded in USD
* `WHERE block_date >= NOW() - INTERVAL '30 days'`: Focuses on recent activity
* `GROUP BY 1, 2, 3`: Combines trades by day, blockchain, and DEX
* `ORDER BY 1 DESC, 5 DESC`: Shows newest and highest volume trades first

## Making Your Analysis Dynamic with Parameters

Want to focus on your favorite DEX? Let's add the column `project` as a parameter to make the analysis interactive:

```sql theme={null}
SELECT
  block_date,
  blockchain,
  project,
  COUNT(*) as number_of_trades,
  SUM(amount_usd) as trading_volume_usd
FROM dex.trades
WHERE
  block_date >= NOW() - INTERVAL '30' day
  AND project = '{{Project Name}}' -- Try 'uniswap' or 'curve'
GROUP BY
  1, 2, 3
ORDER BY
  1 DESC, 5 DESC
```

To add the parameter:

1. Click "Add Parameter" below the query editor
2. Create a text parameter named "Project Name"
3. Set default value to "Uniswap"

Now you can instantly switch between different DEXes to compare their performance!

<DuneEmbed />

## Visualizing Results

After running your query, you can create powerful visualizations:

1. Click "New Visualization"
2. Choose "Bar Chart"
3. Set X-axis to `trading_day`
4. Set Y-axis to `trading_volume_usd`
5. Group by `blockchain`

This will create a stacked bar chart showing daily trading volumes by blockchain!

<DuneEmbed />

<Note>
  Want to explore more? Try:

  * Removing the project filter to see all DEXes
  * Changing the time period to 7 days or 90 days
  * Adding token filters to focus on specific cryptocurrencies
</Note>

## Next Steps

Congratulations on creating your first DEX analysis query! 🎉

You can find many more queries related to DEX trading activity in this dashboard: [DEX Trading Activity](https://dune.com/hagaetc/dex-metrics)

Save your query by clicking **Save** in the upper right corner. You can revisit and modify it anytime to explore different aspects of DEX trading activity.

<Note>
  Ready to create more advanced queries? Check out our other guides to learn
  more about Dune
</Note>


# Create your first visualization
Source: https://docs.dune.com/learning/how-tos/create-your-first-visualization

How to create a combination bar chart and line chart to visualize the monthly $ gas spent for your wallet

After executing a query, you'll be presented with a set of results. The next logical step? Visualize that data for a clearer insight. This guide will show you how to layer a combined bar and line chart atop the data from [Create your first query](/learning/how-tos/create-your-first-query).

Here is a visual click-through version if you are more of a visual learner. Below is a written version.

<div>
  <iframe />
</div>

1. **Begin Visualization**: Click on "New" and select your desired chart type. For this tutorial, initiate with a bar chart and click "Bar Chart."
2. **Display Data**: By default, the chart will showcase `monthly_gas_spent`. To augment the depth of insights, include the `cumulative_gas_spent` column.
3. **Adjust Chart Type**: Transition the representation of `cumulative_gas_spent` from a bar to a line chart, offering a more nuanced view.
4. **Fine-tune Your Chart**: Customize the display values for a polished look. For detailed formatting guidance, [refer to this resource](/web-app/visualizations/charts-graphs).

<div>
  <iframe />
</div>

You can also use the AI Chart Builder to automatically generate the charts for your data.

1. **Click Generate** When you click generate, the AI Chart Builder will suggest a title and chart type based on your data.
2. If you are happy with the recommendation, click **Create** to add the chart to your dashboard.
3. Otherwise, you can edit the title or the chart type and then click **Create** to create the chart.
4. (Optional) **Fine-tune Your Chart**: Customize the display values for a polished look. For detailed formatting guidance, [refer to this resource](/web-app/visualizations/charts-graphs).


# Export Data
Source: https://docs.dune.com/learning/how-tos/export-data-out

Export query results from Dune via CSV download or the API.

This guide provides a step-by-step process on exporting data from Dune, either through CSV downloads or the API.

<Note>
  Need a recurring warehouse sync instead of downloading query results? Enterprise teams can publish dbt-managed tables from Dune into Snowflake or BigQuery with [dbt to Datashare](/api-reference/connectors/dbt/datashares).
</Note>

## Export Methods and File Formats

You can export data from Dune using two primary methods. Each offers different capabilities and file formats:

* **CSV Downloads:** Ideal for static data exports, CSV downloads allow you to save query results in a spreadsheet-compatible format. You can easily open these files in spreadsheet software like Microsoft Excel or Google Sheets.
* **API Exports**: API exports offer more flexibility and customization options. You can retrieve data in JSON or CSV formats, making it suitable for integration with third-party tools or custom analytics platforms.

## Understanding Credit Usage for Data Export

Before you start exporting data from Dune, it's essential to understand how credits are consumed during the export process. Each export action, whether through CSV downloads or the API, deducts credits from your account based on the amount of data and the method used.

For a comprehensive overview of how credits work in Dune, please refer to our [detailed guide on the credit system](https://docs.dune.com/learning/how-tos/credit-system-on-dune). Teams can also [export detailed credit usage data](https://docs.dune.com/learning/how-tos/credit-system-on-dune#export-credit-usage-data) to analyze consumption patterns and optimize their usage.

### Costs for Exporting Data:

Credits are consumed when exporting query results via API or CSV, based on the amount of data exported:

| Plan       | Credits per MB Exported |
| ---------- | ----------------------- |
| Free       | 20                      |
| Analyst    | 10                      |
| Plus       | 2                       |
| Enterprise | Custom                  |

<Note>
  CSV exports are available **only** to users on [Plus and Enterprise plans](https://dune.com/pricing). API exports are available across all plans, but with varying rate limits.
</Note>

For more details on each plan, visit our [pricing page](https://dune.com/pricing). For comprehensive billing information, see our [API billing guide](/api-reference/overview/billing).

### Rate Limits:

Rate limits determine how frequently you can initiate data exports and at what volume. For detailed information on adjusting your export activities to stay within these limits while managing your credits efficiently, refer to our [API rate limits guide](https://docs.dune.com/api-reference/overview/rate-limits).

## Identify the Dataset for Export

Begin by pinpointing the dataset or query result you wish to export. For instance, given the recent buzz around Friend.Tech, you might want to export the results from this query: [https://dune.com/queries/2945343](https://dune.com/queries/2945343).

## Export via CSV

* Navigate to the query interface.
* Simply click the "Export to CSV" button.

<div>
  <iframe title="Export Dune query results to a CSV file" />
</div>

## Export via API

To export data via the API, you'll need an API key. For details on how to generate and manage your API key, visit the [Authentication](/api-reference/overview/authentication) section of the API reference.

When viewing a query on Dune, click the **Try API** button in the header of the query results panel to see your options for retrieving that data via API. You can copy endpoint URLs and use your API key to start pulling data right away.

<div>
  <iframe title="Generate API Code Snippets for Query Results" />
</div>

There are various ways to get your data via the API:

* **Get Latest Query Result** — Use the [Get Latest Query Result](/api-reference/executions/endpoint/get-query-result) endpoint to retrieve data in JSON or CSV format without needing to trigger a new execution.
* **SDKs** — Dune offers official SDKs for Python, TypeScript, and Go that handle authentication, polling, and pagination for you. Check out the [SDK Quickstart](/api-reference/quickstart/results-eg) to get up and running quickly.


# FAQs
Source: https://docs.dune.com/learning/how-tos/pricing-faqs

Frequently asked questions about Dune's pricing, credits, billing, plans, and more

# Frequently Asked Questions

Find answers to common questions about Dune's pricing, credits, billing cycles, and subscription plans.

## General Questions

<AccordionGroup>
  <Accordion title="Where can I see my billing history?">
    Your billing history can be found under "Billing" in your Subscription Settings. Follow the steps below for a complete view:

    1. Go to dune.com
    2. Sign in to your Dune account
    3. Click your avatar in the middle of the top bar where your user or team badge is
    4. Click the Settings icon and then "Subscription"
  </Accordion>

  <Accordion title="How are upgrades and downgrades handled?">
    Upgrading to a new paid tier resets your billing cycle start date. On the date of your upgrade, you will be billed the full new plan price and refunded a prorated amount corresponding to the number of unused days of your current plan. If you upgrade from Analyst to Plus on day 15 of your billing cycle, you will be billed a month of Plus minus 15 days of Analyst (roughly half the monthly Analyst cost).

    Downgrades to lower tiers are applied at the end of your billing cycle. Benefits from your current tier remain until the end of your billing cycle. At the end of your billing cycle, you will automatically be downgraded to the lower tier of your choice.
  </Accordion>

  <Accordion title="How do I upgrade, downgrade, or cancel my team's subscription?">
    Only administrators of teams with paid plans can change team subscriptions. To change your team's subscription:

    1. Go to dune.com
    2. Sign in to your Dune account
    3. Click your avatar in the middle of the top bar where your team badge is
    4. Click the Settings icon and then "Subscription"
    5. Click the plan you want to upgrade or downgrade to

    To cancel your subscription, follow these steps:

    1. Go to dune.com
    2. Sign in to your Dune account
    3. Click your avatar in the middle of the top bar where your user or team badge is
    4. Click the Settings icon and then "Subscription"
    5. Change your plan to Free

    Your subscription will remain active for 30 days after your last payment.
  </Accordion>

  <Accordion title="Do you offer paid plans for individuals?">
    If you are a single user with higher requirements than what's offered in the free tier, you can create a team of one to access paid tiers. Note that we hope to change this in the future, so individuals don't need to create a plan to upgrade.
  </Accordion>

  <Accordion title="What if I have more questions?">
    For general info on how to use Dune, please see our [docs](https://docs.dune.com). For specific questions on how to do a query, please join our [Discord](https://discord.com/invite/dunecom). If you have other issues or questions not listed on this page, please contact [support@dune.com](mailto:support@dune.com).
  </Accordion>
</AccordionGroup>

## Credits and Spending

<AccordionGroup>
  <Accordion title="What is a credit?">
    Credits are the measurement unit for usage on Dune. They provide flexibility across query performance, programmatic executions, and API exports. Credits are consumed proportionally to the actual compute resources your queries use—simple queries cost fewer credits while complex ones use more.
  </Accordion>

  <Accordion title="Can I view my credit usage and balance?">
    To view your credit usage and balance go to Settings and select Subscription; here you will see used and remaining credits.
  </Accordion>

  <Accordion title="How do credits and billing cycles work with annual plans?">
    Annual billing enables customers to pay for their plan yearly at a reduced rate. Customers on this plan will still have their credits reset on a monthly basis, as well as receive monthly charges for any potential extra credits incurred.
  </Accordion>

  <Accordion title="How do I calculate my potential monthly credit usage?">
    Credit usage is determined by the actual compute resources your queries consume. Your credit consumption directly reflects each query's complexity and resource requirements.

    **Query Execution (App & API)**

    * Credits are charged based on CPU-seconds and network resources used
    * Simple, efficient queries use fewer credits
    * Complex queries with large data scans require more credits
    * Queries cost the same whether executed manually or programmatically

    **API Export**

    * Free and Analyst: 1 credit = 1,000 data points
    * Plus: 1 credit = 5,000 data points
    * Legacy Premium: 1 credit = 25,000 data points (no longer available)
  </Accordion>

  <Accordion title="How can I manage and reduce my credit usage?">
    There are several ways to control and optimize your credit consumption:

    **Monitor Your Usage**

    * Check the usage tab regularly to track your credit consumption patterns
    * Review which queries and users consume the most credits
    * Set extra credit limits to control how many additional credits can be purchased beyond your plan's included amount

    **Control Spending**

    * Set query cost caps in Settings to limit the maximum credits any single query can consume
    * Configure team-level caps to prevent accidental high-usage queries
    * Use these caps while testing new queries or during development

    **Optimize Your Queries**

    * Write efficient SQL to dramatically reduce credit consumption
    * Review our [query optimization guide](https://docs.dune.com/query-engine/writing-efficient-queries) for specific techniques
  </Accordion>

  <Accordion title="What happens if my credit quota runs out?">
    Once your monthly credit quota runs out, we'll continue to bill you for additional credits at your plan's extra credit rate. There's no separate "extra credit pricing", you pay the same rate per 100 credits as shown for your plan:

    * Free: \$5.00 per 100 credits
    * Analyst: $1.875 per 100 credits (monthly) / $1.625 per 100 credits (annual)
    * Plus: $1.596 per 100 credits (monthly) / $1.396 per 100 credits (annual)
    * Legacy Premium: \$0.999 per 100 credits (no longer available)
    * Enterprise: Custom pricing per your agreement

    You can set query cost caps in Settings to control your credit usage and prevent unexpected charges.
  </Accordion>

  <Accordion title="Can I purchase extra credits in bulk?">
    No, once your quota runs out, extra credits will be billed on an ongoing basis as you use Dune. Credits are not available to purchase in bulk once you reach your quota.
  </Accordion>

  <Accordion title="If I have leftover credits at the end of the billing cycle can I use them later?">
    Remaining credits at the end of a billing cycle do not rollover to the next month.
  </Accordion>

  <Accordion title="Can I 'pay as I go' without upgrading?">
    Yes, you can pay as you go. Both individuals and teams in the free tier can continue using Dune beyond their 2,500 monthly credits by paying \$5.00 per 100 additional credits. This allows you to handle occasional larger workloads without committing to a monthly subscription. If you find yourself consistently purchasing additional credits, consider upgrading to a paid plan for better value, paid plans offer significantly lower per-credit rates and additional features like API access and unlimited concurrent executions.
  </Accordion>

  <Accordion title="How can I limit my spending?">
    To limit monthly spend, go to your subscription page in Settings and set the limit to the desired amount. Setting your limit to \$0 will prevent additional usage billing.
  </Accordion>

  <Accordion title="What if I lower my spend limit below my current spend level?">
    If you lower your spend limit below your current spending level, you will not be charged any additional fees beyond your new spend limit. However, any usage that has accrued does not rollover and will still be billed based on the previous spend limit.
  </Accordion>
</AccordionGroup>

## Query Engines & Executions

<AccordionGroup>
  <Accordion title="How is my query execution usage counted?">
    When you manually trigger an execution by pressing Run in the Query Editor, dashboard, or via the API, we accrue that usage to the user or team account. To ensure you are accruing usage in the correct account, view your selected account in the account switcher located in the middle of the top navigation bar on Dune.
  </Accordion>

  <Accordion title="What are the differences between query engine sizes?">
    We have three different query engine sizes that you can use on Dune, each consuming credits based on actual compute resources used:

    **Small Engine (0 credits to run)**

    * Run simple queries manually in the Dune app for free
    * Credits consumed from your monthly allowance based on actual usage
    * 2-minute timeout limit
    * Maximum of three (3) concurrent executions
    * No performance guarantees

    **Medium Engine**

    * Run queries with a larger timeout, manually or programmatically
    * Credits consumed based on actual compute resources used
    * No limit on concurrent executions
    * Suitable for most standard queries and dashboards

    **Large Engine**

    * Optimized for complex workloads requiring more computational power
    * Credits consumed based on actual compute resources used (more compute and resource than Medium for the same query)
    * Best for data-intensive queries and complex analytics

    The Large engine provides approximately 2x the computational capacity of the Medium engine. While both Medium and Large engines charge based on actual usage, the Large engine will typically consume more credits for the same query due to the additional resources allocated, but will complete faster. The Small engine is limited in capacity and has stricter timeout constraints.

    **Note:** Exact credit consumption varies based on query complexity, data volume scanned, and processing required rather than being a fixed rate per execution.
  </Accordion>

  <Accordion title="What is a programmatic execution?">
    Programmatic executions are query executions done through the Dune API, scheduled executions, materialized view refreshes, or dashboard runs. Programmatic executions consume credits based on actual compute resources used, just like manual queries. Both manual and programmatic executions are charged based on the complexity and resources required by your query, ensuring consistent and fair pricing across all execution methods.
  </Accordion>

  <Accordion title="What are the limitations of the Free query engine size?">
    The Free query engine on Dune is available to anyone at no cost, but it does come with limitations. First, there are no performance or queue priority guarantees, which means executions may take longer to run during times of high demand. Additionally, the Free query engine is limited to manual query editor executions only; automated executions (API, scheduling, refreshing) are not available. Lastly, there is a maximum limit of three (3) ongoing executions (executing or queued) at any given time for Free executions, and executions are timed out at 120 seconds.
  </Accordion>
</AccordionGroup>

## Features

<AccordionGroup>
  <Accordion title="Can I add a private query to a public dashboard?">
    If you add a private query to a public dashboard, other Dune users will be able to see the visualization in the public dashboard, but won't see your code when they click the query. The results table, other visualizations you might have, and the underlying query are all private.
  </Accordion>

  <Accordion title="Do archived private queries count towards my limit?">
    No, you can archive private queries that you no longer need to increase your existing private queries quota. Archived queries are not accessible by anyone else and cannot be run. You can unarchive them later if you change your mind.
  </Accordion>

  <Accordion title="Can I embed private queries on other websites?">
    Yes, anyone visiting the website with the embed can see the visualization you chose to embed and nothing else.
  </Accordion>

  <Accordion title="As an Enterprise team, what will happen to watermarks?">
    When logged in to the team on Dune, work you've created will not have watermarks. Public dashboards URLs always have watermarks.
  </Accordion>
</AccordionGroup>

## Teams

<AccordionGroup>
  <Accordion title="What is an Editor seat?">
    Owners of editor seats can create and edit content owned by their team, but they cannot access team management features; those are reserved for admins. Viewers have read-only access to the team's content and can still benefit from their team plan features and quotas.
  </Accordion>

  <Accordion title="Do my team's benefits apply to all content on Dune?">
    Yes, team benefits apply to all Dune content, as long as your team is in the correctly selected account which is viewable in the middle of the top navigation bar on Dune.
  </Accordion>

  <Accordion title="How is a team's usage or feature quota applied?">
    Quotas are applied to all team usage.
  </Accordion>

  <Accordion title="Can I invite unlimited collaborators?">
    Yes, you can invite as many people as you need into your Dune team at no additional cost. All team members will need a Dune account to collaborate with you.
  </Accordion>

  <Accordion title="Can I create unlimited Free teams?">
    You can create 1 Free team on Dune.
  </Accordion>
</AccordionGroup>

## API

<AccordionGroup>
  <Accordion title="What is a datapoint?">
    A datapoint can, in most cases, be thought of as rows \* columns with an additional limit of 100 average bytes per cell in a set of results. This can be expressed as:

    `datapoints = max(rows * columns, ceil(total_bytes / 100))`
  </Accordion>

  <Accordion title="Do I get charged data points for every time I read a result?">
    Yes, we accrue the resulting datapoints returned from every request to your credit quota.
  </Accordion>

  <Accordion title="How do query executions work in the API?">
    Query executions are identical to those triggered on dune.com. Please note: free executions are not supported via the API.
  </Accordion>

  <Accordion title="Can my team use the API?">
    Yes, the API is included in all Dune plans. This means that all teams and users, including those in the Free plan, can access the API to trigger executions and export data, provided their spend limit has not been exceeded. Please note: credits still apply for API usage, regardless of the plan you are on.
  </Accordion>

  <Accordion title="Should I link back to the source when using the API?">
    We strongly believe Dune analysts should be credited for their work's impact. We encourage you to credit the analyst, or perhaps to link to the original query. Linking to transparent data sources like Dune is a great way of building trust.
  </Accordion>
</AccordionGroup>


# Query Templates
Source: https://docs.dune.com/learning/how-tos/query-templates

Pre-built query templates to jumpstart your Dune journey with common blockchain analytics patterns

Jump start your Dune journey with our collection of pre-built query templates. These templates let you easily select wallets, tokens, and contracts and track their key actions over time.

<Note>
  **Need a specific template?** Don't see what you're looking for? [Request a new template](https://docs.google.com/forms/d/e/1FAIpQLSeDjR0908lRRroCzRHSD9SnBKSS5hox-_AbLJahH7ZmBuf5hA/viewform?usp=header) and we'll consider adding it to our collection.
</Note>

## Tokens

Track token flows, balances, and holder activity across different token standards.

<AccordionGroup>
  <Accordion title="Contract Balance and Flow Monitoring - ERC20 Token" icon="coins">
    Track the net flows of an ERC20 token into contracts, over a given time period.

    <iframe />

    [Open in Dune →](https://dune.com/queries/5823843)
  </Accordion>

  <Accordion title="Wallet Balance and Flow Monitoring - ERC20 Token" icon="wallet">
    Track the net flows of top holders (or a list of addresses) for an ERC20 token, over a given time period.

    <iframe />

    [Open in Dune →](https://dune.com/queries/5823857)
  </Accordion>

  <Accordion title="Contract Balance and Flow Monitoring - NFT Token (721/1155)" icon="image">
    Track the net flows of an NFT token into contracts, over a given time period.

    <iframe />

    [Open in Dune →](https://dune.com/queries/5823861)
  </Accordion>

  <Accordion title="Wallet Balance and Flow Monitoring - NFT Token (721/1155)" icon="user">
    Track the net flows of top holders (or a list of addresses) for an NFT token, over a given time period.

    <iframe />

    [Open in Dune →](https://dune.com/queries/5833534)
  </Accordion>
</AccordionGroup>

## Trades

Monitor trading activity across DEXs and NFT marketplaces.

<AccordionGroup>
  <Accordion title="DEX Trade Monitoring" icon="chart-line">
    Track trading volume, price movements, and liquidity patterns for token pairs.

    <iframe />

    [Open in Dune →](https://dune.com/queries/5833536)
  </Accordion>

  <Accordion title="NFT Trade Monitoring" icon="image">
    Monitor NFT trading activity, floor prices, and collection performance.

    <iframe />

    [Open in Dune →](https://dune.com/queries/5833538)
  </Accordion>
</AccordionGroup>

## Contracts

Analyze smart contract interactions and usage patterns.

<AccordionGroup>
  <Accordion title="New Wallets Calling a Contract" icon="user-plus">
    Identify new users interacting with a specific smart contract over time.

    <iframe />

    [Open in Dune →](https://dune.com/queries/5833540)
  </Accordion>

  <Accordion title="New Contracts Calling Another Contract" icon="code">
    Track which new contracts are calling a specific contract.

    <iframe />

    [Open in Dune →](https://dune.com/queries/5833541)
  </Accordion>

  <Accordion title="Trending Contracts Called by Tracked Wallet" icon="chart-line">
    Discover which contracts a tracked wallet is calling most frequently.

    <iframe />

    [Open in Dune →](https://dune.com/queries/5833544)
  </Accordion>
</AccordionGroup>

## Farcaster

Analyze social activity and user behavior on the Farcaster protocol.

<AccordionGroup>
  <Accordion title="Identify trending users who hold a token" icon="users">
    Find Farcaster users who hold specific tokens and are gaining social traction.

    <iframe />

    [Open in Dune →](https://dune.com/queries/5833549)
  </Accordion>

  <Accordion title="Identify trending channels" icon="hashtag">
    Discover which Farcaster channels are gaining popularity and activity.

    <iframe />

    [Open in Dune →](https://dune.com/queries/5833553)
  </Accordion>

  <Accordion title="Track trending users someone has interacted with" icon="users">
    Analyze the social network of a specific user to find trending connections.

    <iframe />

    [Open in Dune →](https://dune.com/queries/5833555)
  </Accordion>
</AccordionGroup>

## How to Use Templates

1. **Expand any template** above to see a preview of the query results
2. **Click "Open in Dune"** to open the query in the Dune editor
3. **Customize the parameters** using the template's input fields:
   * **Token Symbol**: Choose the token you want to track
   * **Token Contract**: Paste the contract address if the token isn't in our database
   * **Blockchain**: Select the blockchain network
   * **Time Period**: Set the number of days to analyze
   * **Filters**: Adjust minimum thresholds and other parameters
4. **Run the query** to see your results
5. **Save and share** your customized query

## Template Categories Explained

### **Tokens**

Perfect for analyzing token economics, holder behavior, and token flows. Use these templates to understand how tokens move between wallets and contracts.

### **Trades**

Ideal for market analysis, price tracking, and trading pattern identification. Essential for understanding market dynamics and liquidity.

### **Contracts**

Great for smart contract analytics, user adoption tracking, and protocol interaction analysis. Use these to understand how users interact with specific protocols.

### **Farcaster**

Designed for social analytics on the Farcaster protocol. Perfect for understanding community dynamics, influencer identification, and social trends.

## Getting Started

1. **Choose your category** based on what you want to analyze
2. **Select a template** that matches your use case
3. **Customize the parameters** to fit your specific needs
4. **Run and iterate** to refine your analysis

<Info>
  **Pro Tip**: Start with a template and modify it to create your own unique queries. Templates are designed to be building blocks for more complex analysis.
</Info>

## Need Help?

* **Query Editor Guide**: Learn how to use the Dune query editor effectively
* **Writing Efficient Queries**: Optimize your queries for better performance
* **Data Catalog**: Explore available data sources and tables
* **Community**: Join our Discord for help and inspiration

***

**Don't see what you need?** [Request a new template](https://docs.google.com/forms/d/e/1FAIpQLSeDjR0908lRRroCzRHSD9SnBKSS5hox-_AbLJahH7ZmBuf5hA/viewform?usp=header) and we'll consider adding it to our collection.


# Aggregate functions
Source: https://docs.dune.com/query-engine/Functions-and-operators/aggregate



Aggregate functions operate on a set of values to compute a single
result.

Except for `count`, `count_if`, `max_by`, `min_by` and `approx_distinct`, all of these aggregate functions ignore null values and return null for no input rows or when all values are null. For example, `sum` returns null rather than zero and `avg` does not include null values in the count. The `coalesce` function can be used to convert null into zero.

## Ordering during aggregation

Some aggregate functions such as `array_agg` produce different results depending on the order of input values. This ordering can be specified by writing an `order-by-clause` within the aggregate function:

```sql theme={null}
    array_agg(x ORDER BY y DESC)
    array_agg(x ORDER BY x, y, z)
```

## Filtering during aggregation

The `FILTER` keyword can be used to remove rows from aggregation
processing with a condition expressed using a `WHERE` clause. This is
evaluated for each row before it is used in the aggregation and is
supported for all aggregate functions.

```sql theme={null}
aggregate_function(...) FILTER (WHERE <condition>)
```

A common and very useful example is to use `FILTER` to remove nulls from
consideration when using `array_agg`:

```sql theme={null}
    SELECT array_agg(name) FILTER (WHERE name IS NOT NULL)
    FROM region;
```

As another example, imagine you want to add a condition on the count for
Iris flowers, modifying the following query:

```sql theme={null}
    SELECT species,
           count(*) AS count
    FROM iris
    GROUP BY species;
```

```text theme={null}
species    | count
-----------+-------
setosa     |   50
virginica  |   50
versicolor |   50
```

If you just use a normal `WHERE` statement you lose information:

```sql theme={null}
    SELECT species,
        count(*) AS count
    FROM iris
    WHERE petal_length_cm > 4
    GROUP BY species;
```

```text theme={null}
species    | count
-----------+-------
virginica  |   50
versicolor |   34
```

Using a filter you retain all information:

```sql theme={null}
    SELECT species,
           count(*) FILTER (where petal_length_cm > 4) AS count
    FROM iris
    GROUP BY species;
```

```text theme={null}
species    | count
-----------+-------
virginica  |   50
setosa     |    0
versicolor |   34
```

## General aggregate functions

#### arbitrary()

**`arbitrary(x)`** → \[same as input]

Returns an arbitrary non-null value of `x`, if one exists.

#### any\_value()

**`any_value(x)`** → \[same as input]

Returns an arbitrary non-null value of `x`, if one exists. This is an alias for `arbitrary`.

#### array\_agg()

**`array_agg(x)`** → \[same as input]

Returns an array created from the input `x` elements.

#### avg()

**`avg(x)`** → double

Returns the average (arithmetic mean) of all input values.

**`avg(time interval type)`** → time interval type

Returns the average interval length of all input values.

#### bool\_and()

**`bool_and(boolean)`** → boolean

Returns `TRUE` if every input value is `TRUE`, otherwise `FALSE`.

#### bool\_or()

**`bool_or(boolean)`** → boolean

Returns `TRUE` if any input value is `TRUE`, otherwise `FALSE`.

#### checksum()

**`checksum(x)`** → varbinary

Returns an order-insensitive checksum of the given values.

#### count()

**`count(*)`** → bigint

Returns the number of input rows.

**`count(x)`** → bigint

Returns the number of non-null input values.

#### count\_if()

**`count_if(x)`** → bigint

Returns the number of `TRUE` input values. This function is equivalent to `count(CASE WHEN x THEN 1 END)`.

#### every()

**`every(boolean)`** → boolean

This is an alias for `bool_and`.

#### geometric\_mean()

**`geometric_mean(x)`** → double

Returns the geometric mean of all input values.

#### listagg()

**`listagg(x, separator)`** → varchar

Returns the concatenated input values, separated by the `separator` string.

Synopsis:

```sql theme={null}
    LISTAGG( expression [, separator] [ON OVERFLOW overflow_behaviour])
        WITHIN GROUP (ORDER BY sort_item, [...])
```

If `separator` is not specified, the empty string will be used as
`separator`.

In its simplest form the function looks like:

```sql theme={null}
    SELECT listagg(value, ',') WITHIN GROUP (ORDER BY value) csv_value
    FROM (VALUES 'a', 'c', 'b') t(value);
```

and results in:

```text theme={null}
    csv_value
    -----------
    'a,b,c'
```

The overflow behaviour is by default to throw an error in case that the
length of the output of the function exceeds `1048576` bytes:

```sql theme={null}
    SELECT listagg(value, ',' ON OVERFLOW ERROR) WITHIN GROUP (ORDER
    BY value) csv_value
    FROM (VALUES 'a', 'c', 'b') t(value);
```

and results in:

```text theme={null}
    csv_value
    -----------
    'a,c,b'
```

The overflow behaviour can also be to truncate the output:

```sql theme={null}
    SELECT listagg(value, ',' ON OVERFLOW TRUNCATE) WITHIN GROUP (ORDER
    BY value) csv_value
    FROM (VALUES 'a', 'c', 'b') t(value);
```

and results in:

```text theme={null}
    csv_value
    -----------
    'a,b'
```

The overflow behaviour can also be to skip the overflowed values:

```sql theme={null}
    SELECT listagg(value, ',' ON OVERFLOW SKIP) WITHIN GROUP (ORDER
    BY value) csv_value
```

The current implementation of `LISTAGG` function does not support window
frames.

#### max()

**`max(x)`** → \[same as input]

Returns the maximum value of all input values.

**`max(x, n)`** → array\<\[same as x]>

Returns `n` largest values of all input values of `x`.

#### max\_by()

**`max_by(x, y)`** → \[same as x]

Returns the value of `x` associated with the maximum value of `y` over all input values.

**`max_by(x, y, n)`** → array\<\[same as x]>

Returns `n` values of `x` associated with the `n` largest of all input values of `y` in descending order of `y`.

#### min()

**`min(x)`** → \[same as input]

Returns the minimum value of all input values.

**`min(x, n)`** → array\<\[same as x]>

Returns `n` smallest values of all input values of `x`.

#### min\_by()

**`min_by(x, y)`** → \[same as x]

Returns the value of `x` associated with the minimum value of `y` over all input values.

**`min_by(x, y, n)`** → array\<\[same as x]>

Returns `n` values of `x` associated with the `n` smallest of all input values of `y` in ascending order of `y`.

#### sum()

**`sum(x)`** → \[same as input]

Returns the sum of all input values.

#### try\_sum()

**`try_sum(uint256)`** → uint256

Returns the sum of all input values, or null if an addition overflow occurred.

## Bitwise aggregate functions

#### bitwise\_and\_agg()

**`bitwise_and_agg(x)`** → bigint

Returns the bitwise AND of all input values in 2's complement representation.

#### bitwise\_or\_agg()

**`bitwise_or_agg(x)`** → bigint

Returns the bitwise OR of all input values in 2's complement representation.

#### bitwise\_xor\_agg()

**`bitwise_xor_agg(x)`** → bigint

Returns the bitwise XOR of all input non-NULL values in 2’s complement representation. If all records inside the group are NULL, or if the group is empty, the function returns NULL.

## Map Aggregate Functions

#### histogram()

**`histogram(x)`** → map\<K,bigint>

Returns a map containing the count of the number of times each input value occurs.

#### map\_agg()

**`map_agg(key, value)`** → map\<K,V>

Returns a map created from the input key/value pairs.

#### map\_union()

**`map_union(x(K, V))`** → map\<K,V>

Returns the union of all the input maps. If a key is found in multiple input maps, that key's value in the resulting map comes from an arbitrary input map.

For example, take the following histogram function that creates multiple maps from the Iris dataset:

```sql theme={null}
SELECT histogram(floor(petal_length_cm)) petal_data
FROM memory.default.iris
GROUP BY species;

        petal_data
-- {4.0=6, 5.0=33, 6.0=11}
-- {4.0=37, 5.0=2, 3.0=11}
-- {1.0=50}
```

You can combine these maps using map\_union:

```sql theme={null}
SELECT map_union(petal_data) petal_data_union
FROM (
       SELECT histogram(floor(petal_length_cm)) petal_data
       FROM memory.default.iris
       GROUP BY species
       );

             petal_data_union
--{4.0=6, 5.0=2, 6.0=11, 1.0=50, 3.0=11}
```

If you instead want to have the last value instead of an arbitrary value, use this snippet:

```sql theme={null}
map_concat(map_filter(m.chain_stats, (k, v) -> NOT contains(map_keys(n.chain_stats), k)), n.chain_stats)
```

#### multimap\_agg()

**`multimap_agg(key, value)`** → map\<K,array(V)>

Returns a multimap created from the input key / value pairs. Each key can be associated with multiple values.

## Approximate aggregate functions

#### approx\_distinct()

**`approx_distinct(x)`** → bigint

Returns the approximate number of distinct input values. This function provides an approximation of `count(DISTINCT x)`. Zero is returned if all input values are null.

This function should produce a standard error of 2.3%, which is the standard deviation of the (approximately normal) error distribution over all possible sets. It does not guarantee an upper bound on the error for any specific input set.

**`approx_distinct(x, e)`** → bigint

Returns the approximate number of distinct input values. This function provides an approximation of `count(DISTINCT x)`. Zero is returned if all input values are null.

This function should produce a standard error of no more than `e`, which is the standard deviation of the (approximately normal) error distribution over all possible sets. It does not guarantee an upper bound on the error for any specific input set. The current implementation of this function requires that `e` be in the range of 0.0040625 to 0.26000.

#### approx\_most\_frequent()

**`approx_most_frequent(x, k)`** → map\<\[same as x], bigint>

Computes the top frequent values up to `buckets` elements approximately.
Approximate estimation of the function enables us to pick up the
frequent values with less memory. Larger `capacity` improves the
accuracy of underlying algorithm with sacrificing the memory capacity.
The returned value is a map containing the top elements with
corresponding estimated frequency.

The error of the function depends on the permutation of the values and
its cardinality. We can set the capacity same as the cardinality of the
underlying data to achieve the least error.

`buckets` and `capacity` must be `bigint`. `value` can be numeric or
string type.

The function uses the stream summary data structure proposed in the
paper [Efficient Computation of Frequent and Top-k Elements in Data
Streams](https://www.cse.ust.hk/~raywong/comp5331/References/EfficientComputationOfFrequentAndTop-kElementsInDataStreams.pdf)
by A. Metwalley, D. Agrawl and A. Abbadi.

#### approx\_percentile()

**`approx_percentile(x, percentage)`** → \[same as x]

Returns the approximate percentile for all input values of `x` at the given `percentage`. The value of `percentage` must be between zero and one and must be constant for all input rows.

**`approx_percentile(x, percentages)`** → array\<\[same as x]>

Returns the approximate percentile for all input values of `x` at each of the specified percentages. Each element of the `percentages` array must be between zero and one, and the array must be constant for all input rows.

**`approx_percentile(x, w, percentage)`** → \[same as x]

Returns the approximate weighed percentile for all input values of `x` using the per-item weight `w` at the percentage `percentage`. Weights must be greater or equal to 1. Integer-value weights can be thought of as a replication count for the value `x` in the percentile set. The value of `percentage` must be between zero and one and must be constant for all input rows.

**`approx_percentile(x, w, percentages)`** → array\<\[same as x]>

Returns the approximate weighed percentile for all input values of `x` using the per-item weight `w` at each of the given percentages specified in the array. Weights must be greater or equal to 1. Integer-value weights can be thought of as a replication count for the value `x` in the percentile set. Each element of the `percentages` array must be between zero and one, and the array must be constant for all input rows.

#### approx\_set()

**`approx_set(x)`** → HyperLogLog

See `hyperloglog`.

#### merge()

**`merge(x)`** → HyperLogLog

See `hyperloglog`.

**`merge(qdigest(T))`** → qdigest(T)

See `qdigest`.

**`merge(tdigest)`** → tdigest

See `tdigest`.

#### numeric\_histogram()

**`numeric_histogram(buckets, value)`** → map\<double, double>

Computes an approximate histogram with up to `buckets` number of buckets for all `value`s. This function is equivalent to the variant of `numeric_histogram` that takes a `weight`, with a per-item weight of `1`.

**`numeric_histogram(buckets, value, weight)`** → map\<double, double>

Computes an approximate histogram with up to `buckets` number of buckets for all `value`s with a per-item weight of `weight`. The algorithm is based loosely on:

```text theme={null}
Yael Ben-Haim and Elad Tom-Tov, "A streaming parallel decision tree algorithm", J. Machine Learning Research 11 (2010), pp. 849--872.
```

`buckets` must be a `bigint`. `value` and `weight` must be numeric.

#### qdigest\_agg()

**`qdigest_agg(x)`** → qdigest

See [Quantile digest functions](/query-engine/Functions-and-operators/qdigest).

#### qdigest\_agg()

**`qdigest_agg(x, w)`** → qdigest

See [Quantile digest functions](/query-engine/Functions-and-operators/qdigest).

#### tdigest\_agg()

**`tdigest_agg(x)`** → tdigest

See [T-Digest functions](/query-engine/Functions-and-operators/tdigest).

#### tdigest\_agg()

**`tdigest_agg(x, w)`** → tdigest

See [T-Digest functions](/query-engine/Functions-and-operators/tdigest).

## Statistical aggregate functions

#### corr()

**`corr(x, y)`** → double

Returns correlation coefficient of input values.

#### covar\_pop()

**`covar_pop(y, x)`** → double

Returns the population covariance of input values.

#### covar\_samp()

**`covar_samp(y, x)`** → double

Returns the sample covariance of input values.

#### kurtosis()

**`kurtosis(x)`** → double

Returns the excess kurtosis of all input values. Unbiased estimate using the following expression:

```text theme={null}
kurtosis(x) = n(n+1)/((n-1)(n-2)(n-3))sum[(x_i-mean)^4]/stddev(x)^4-3(n-1)^2/((n-2)(n-3))
```

#### regr\_intercept()

**`regr_intercept(y, x)`** → double

Returns linear regression intercept of input values. `y` is the dependent value and `x` is the independent value.

#### regr\_slope()

**`regr_slope(y, x)`** → double

Returns linear regression slope of input values. `y` is the dependent value and `x` is the independent value.

#### skewness()

**`skewness(x)`** → double

Returns the skewness of all input values. Returns the Fisher’s moment coefficient of [skewness](https://en.wikipedia.org/wiki/Skewness) of all input values.

#### stddev()

**`stddev(x)`** → double

Returns the standard deviation of all input values.

#### stddev\_pop()

**`stddev_pop(x)`** → double

Returns the population standard deviation of all input values.

#### stddev\_samp()

**`stddev_samp(x)`** → double

Returns the sample standard deviation of all input values.

#### variance()

**`variance(x)`** → double

Returns the variance of all input values.

#### var\_pop()

**`var_pop(x)`** → double

Returns the population variance of all input values.

#### var\_samp()

**`var_samp(x)`** → double

Returns the sample variance of all input values.

## Lambda aggregate functions

#### reduce\_agg()

**`reduce_agg(inputValue T, initialState S, inputFunction(S, T, S), combineFunction(S, S, S))`** → S

Reduces all input values into a single value. `inputFunction` will be
invoked for each non-null input value. In addition to taking the input
value, `inputFunction` takes the current state, initially
`initialState`, and returns the new state. `combineFunction` will be
invoked to combine two states into a new state. The final state is
returned:

```sql theme={null}
    SELECT id, reduce_agg(value, 0, (a, b) -> a + b, (a, b) -> a + b)
    FROM (
        VALUES
            (1, 3),
            (1, 4),
            (1, 5),
            (2, 6),
            (2, 7)
    ) AS t(id, value)
    GROUP BY id;
    -- (1, 12)
    -- (2, 13)
```

```sql theme={null}
    SELECT id, reduce_agg(value, 1, (a, b) -> a * b, (a, b) -> a * b)
    FROM (
        VALUES
            (1, 3),
            (1, 4),
            (1, 5),
            (2, 6),
            (2, 7)
    ) AS t(id, value)
    GROUP BY id;
    -- (1, 60)
    -- (2, 42)
```

The state type must be a boolean, integer, floating-point, or
date/time/interval.


# Array functions and operators
Source: https://docs.dune.com/query-engine/Functions-and-operators/array



Subscript operator: \[] \{subscript\_operator}

The `[]` operator is used to access an element of an array and is
indexed starting from one:

```sql theme={null}
    SELECT my_array[1] AS f_element
```

Concatenation operator: || \{concatenation\_operator}

The `||` operator is used to concatenate an array with an array or an
element of the same type:

```sql theme={null}
    SELECT ARRAY[1] || ARRAY[2];
    -- [1, 2]

    SELECT ARRAY[1] || 2;
    -- [1, 2]

    SELECT 2 || ARRAY[1];
    -- [2, 1]
```

### Array functions

#### all\_match()

**`all_match(array(T), function(T,boolean))`** → boolean

Returns whether all elements of an array match the given predicate.
Returns `true` if all the elements match the predicate (a special case
is when the array is empty); `false` if one or more elements don't
match; `NULL` if the predicate function returns `NULL` for one or more
elements and `true` for all other elements.

#### any\_match()

**`any_match(array(T), function(T,boolean))`** → boolean

Returns whether any elements of an array match the given predicate.
Returns `true` if one or more elements match the predicate; `false` if
none of the elements matches (a special case is when the array is
empty); `NULL` if the predicate function returns `NULL` for one or more
elements and `false` for all other elements.

#### array\_distinct()

**`array_distinct(x)`** → array

Remove duplicate values from the array `x`.

#### array\_except()

**`array_except(x, y)`** → array

Returns an array of elements in `x` but not in `y`, without duplicates.

#### array\_histogram()

**`array_histogram(x)`** → map\<K, bigint>

Returns a map where the keys are the unique elements in the input array `x` and the values are the number of times that each element appears in `x`. Null values are ignored.

```sql theme={null}
    SELECT array_histogram(ARRAY[42, 7, 42, NULL]);
    -- {42=2, 7=1}
```

Returns an empty map if the input array has no non-null elements.

```sql theme={null}
    SELECT array_histogram(ARRAY[NULL, NULL]);
    -- {}
```

#### array\_intersect()

**`array_intersect(x, y)`** → array

Returns an array of the elements in the intersection of `x` and `y`, without duplicates.

#### array\_join()

**`array_join(x, delimiter, null_replacement)`** → varchar

Concatenates the elements of the given array using the delimiter and an optional string to replace nulls.

#### array\_max()

**`array_max(x)`** → x

Returns the maximum value of input array.

#### array\_min()

**`array_min(x)`** → x

Returns the minimum value of input array.

#### array\_position()

**`array_position(x, element)`** → bigint

Returns the position of the f occurrence of the element in the array. Returns `NULL` if the element is not found. The position is counted from 1.

#### array\_remove()

**`array_remove(x, element)`** → array

Returns an array of elements in `x` without the element `element`.

#### array\_sort()

**`array_sort(x)`** → array

Sorts and returns the array `x`. The elements of `x` must be orderable. Null elements will be placed at the end of the returned array. The sort is stable, meaning that the relative order of elements that are equal is preserved.

**`array_sort(array(T), function(T,T,int))`** → array(T)

Sorts and returns the `array` based on the given comparator `function`. The comparator will take two nullable arguments representing two nullable elements of the `array`. It returns -1, 0, or 1 as the f nullable element is less than, equal to, or greater than the second nullable element. If the comparator function returns other values (including `NULL`), the query will fail and raise an error.

```sql theme={null}
    SELECT array_sort(ARRAY[3, 2, 5, 1, 2],
                  (x, y) -> IF(x < y, 1, IF(x = y, 0, -1)));
-- [5, 3, 2, 2, 1]

SELECT array_sort(ARRAY['bc', 'ab', 'dc'],
                  (x, y) -> IF(x < y, 1, IF(x = y, 0, -1)));
-- ['dc', 'bc', 'ab']


SELECT array_sort(ARRAY[3, 2, null, 5, null, 1, 2],
                  -- sort null first with descending order
                  (x, y) -> CASE WHEN x IS NULL THEN -1
                                 WHEN y IS NULL THEN 1
                                 WHEN x < y THEN 1
                                 WHEN x = y THEN 0
                                 ELSE -1 END);
-- [null, null, 5, 3, 2, 2, 1]

SELECT array_sort(ARRAY[3, 2, null, 5, null, 1, 2],
                  -- sort null last with descending order
                  (x, y) -> CASE WHEN x IS NULL THEN 1
                                 WHEN y IS NULL THEN -1
                                 WHEN x < y THEN 1
                                 WHEN x = y THEN 0
                                 ELSE -1 END);
-- [5, 3, 2, 2, 1, null, null]

SELECT array_sort(ARRAY['a', 'abcd', 'abc'],
                  -- sort by string length
                  (x, y) -> IF(length(x) < length(y), -1,
                               IF(length(x) = length(y), 0, 1)));
-- ['a', 'abc', 'abcd']

SELECT array_sort(ARRAY[ARRAY[2, 3, 1], ARRAY[4, 2, 1, 4], ARRAY[1, 2]],
                  -- sort by array length
                  (x, y) -> IF(cardinality(x) < cardinality(y), -1,
                               IF(cardinality(x) = cardinality(y), 0, 1)));
-- [[1, 2], [2, 3, 1], [4, 2, 1, 4]]
```

#### array\_union()

**`array_union(x, y)`** → array

Returns an array of the elements in the union of `x` and `y`, without duplicates.

#### array\_overlap()

**`array_overlap(x, y)`** → boolean

Tests if arrays x and y have any non-null elements in common. Returns null if there are no non-null elements in common but either array contains null.

#### cardinality()

**`cardinality(x)`** → bigint

Returns the cardinality (size) of the array x.

#### concat()

**`concat(array1, array2, ..., arrayN)`** → array

Concatenates the arrays array1, array2, ..., arrayN. This function provides the same functionality as the SQL-standard concatenation operator (||).

#### combinations()

**`combinations(array(T), n)`** -> array(array(T))

Returns n-element sub-groups of input array. If the input array has no duplicates, combinations returns n-element subsets.

```sql theme={null}
SELECT combinations(ARRAY['foo', 'bar', 'baz'], 2);
-- [['foo', 'bar'], ['foo', 'baz'], ['bar', 'baz']]

SELECT combinations(ARRAY[1, 2, 3], 2);
-- [[1, 2], [1, 3], [2, 3]]

SELECT combinations(ARRAY[1, 2, 2], 2);
-- [[1, 2], [1, 2], [2, 2]]
```

Order of sub-groups is deterministic but unspecified. Order of elements within a sub-group deterministic but unspecified. n must be not be greater than 5, and the total size of sub-groups generated must be smaller than 100,000.

#### contains()

**`contains(x, element)`** → boolean

Returns true if the array x contains the element.

#### contains\_sequence()

**`contains_sequence(x, seq)`** → boolean

Return true if array x contains all of array seq as a subsequence (all values in the same consecutive order).

#### element\_at()

**`element_at(array(E), index)`** → E

Returns element of array at given index. If index > 0, this function provides the same functionality as the SQL-standard subscript operator (\[]), except that the function returns NULL when accessing an index larger than array length, whereas the subscript operator would fail in such a case. If index \< 0, element\_at accesses elements from the last to the first.

#### filter()

**`filter(array(T), function(T, boolean))`** -> array(T)

Constructs an array from those elements of array for which function returns true:

```sql theme={null}
SELECT filter(ARRAY[], x -> true);
-- []

SELECT filter(ARRAY[5, -6, NULL, 7], x -> x > 0);
-- [5, 7]

SELECT filter(ARRAY[5, NULL, 7, NULL], x -> x IS NOT NULL);
-- [5, 7]
```

#### flatten()

**`flatten(x)`** → array

Flattens an array(array(T)) to an array(T) by concatenating the contained arrays.

#### ngrams()

**`ngrams(array(T), n)`** -> array(array(T))

Returns n-grams (sub-sequences of adjacent n elements) for the array. The order of the n-grams in the result is unspecified.

```sql theme={null}
SELECT ngrams(ARRAY['foo', 'bar', 'baz', 'foo'], 2);
-- [['foo', 'bar'], ['bar', 'baz'], ['baz', 'foo']]

SELECT ngrams(ARRAY['foo', 'bar', 'baz', 'foo'], 3);
-- [['foo', 'bar', 'baz'], ['bar', 'baz', 'foo']]

SELECT ngrams(ARRAY['foo', 'bar', 'baz', 'foo'], 4);
-- [['foo', 'bar', 'baz', 'foo']]

SELECT ngrams(ARRAY['foo', 'bar', 'baz', 'foo'], 5);
-- [['foo', 'bar', 'baz', 'foo']]

SELECT ngrams(ARRAY[1, 2, 3, 4], 2);
-- [[1, 2], [2, 3], [3, 4]]
```

#### none\_match()

**`none_match(array(T), function(T, boolean))`** → boolean

Returns whether no elements of an array match the given predicate. Returns true if none of the elements matches the predicate (a special case is when the array is empty); false if one or more elements match; NULL if the predicate function returns NULL for one or more elements and false for all other elements.

#### reduce()

**`reduce(array(T), initialState S, inputFunction(S, T, S), outputFunction(S, R))`** → R

Returns a single value reduced from array. inputFunction will be invoked for each element in array in order. In addition to taking the element, inputFunction takes the current state, initially initialState, and returns the new state. outputFunction will be invoked to turn the final state into the result value. It may be the identity function (i -> i).

```sql theme={null}
SELECT reduce(ARRAY[], 0,
              (s, x) -> s + x,
              s -> s);
-- 0

SELECT reduce(ARRAY[5, 20, 50], 0,
              (s, x) -> s + x,
              s -> s);
-- 75

SELECT reduce(ARRAY[5, 20, NULL, 50], 0,
              (s, x) -> s + x,
              s -> s);
-- NULL

SELECT reduce(ARRAY[5, 20, NULL, 50], 0,
              (s, x) -> s + coalesce(x, 0),
              s -> s);
-- 75

SELECT reduce(ARRAY[5, 20, NULL, 50], 0,
              (s, x) -> IF(x IS NULL, s, s + x),
              s -> s);
-- 75

SELECT reduce(ARRAY[2147483647, 1], BIGINT '0',
              (s, x) -> s + x,
              s -> s);
-- 2147483648

-- calculates arithmetic average
SELECT reduce(ARRAY[5, 6, 10, 20],
              CAST(ROW(0.0, 0) AS ROW(sum DOUBLE, count INTEGER)),
              (s, x) -> CAST(ROW(x + s.sum, s.count + 1) AS
                             ROW(sum DOUBLE, count INTEGER)),
              s -> IF(s.count = 0, NULL, s.sum / s.count));
-- 10.25
```

#### repeat()

**`repeat(element, count)`** → array

Repeat element for count times.

#### reverse()

**`reverse(x)`** → array

Returns an array which has the reversed order of array x.

#### sequence()

**`sequence(start, stop)`**

Generate a sequence of integers from start to stop, incrementing by 1 if start is less than or equal to stop, otherwise -1.

**`sequence(start, stop, step)`**

Generate a sequence of integers from start to stop, incrementing by step.

**`sequence(start, stop)`**

Generate a sequence of dates from start date to stop date, incrementing by 1 day if start date is less than or equal to stop date, otherwise -1 day.

**`sequence(start, stop, step)`**

Generate a sequence of dates from start to stop, incrementing by step. The type of step can be either INTERVAL DAY TO SECOND or INTERVAL YEAR TO MONTH.

**`sequence(start, stop, step)`**

Generate a sequence of timestamps from start to stop, incrementing by step. The type of step can be either INTERVAL DAY TO SECOND or INTERVAL YEAR TO MONTH.

#### shuffle()

**`shuffle(x)`** → array

Generate a random permutation of the given array x.

#### slice()

**`slice(x, start, length)`** → array

Subsets array x starting from index start (or starting from the end if start is negative) with a length of length.

#### trim\_array()

**`trim_array(x, n)`** → array

Remove n elements from the end of array:

```sql theme={null}
SELECT trim_array(ARRAY[1, 2, 3, 4], 1);
-- [1, 2, 3]

SELECT trim_array(ARRAY[1, 2, 3, 4], 2);
-- [1, 2]
```

#### transform()

**`transform(array(T), function(T, R))`** → array(R)

Returns an array of the results of applying the given function to each element of the given array. The function must be deterministic and must return the same type for each invocation with the same argument. If the function returns NULL, the result of the transform is NULL.

```sql theme={null}

SELECT transform(ARRAY[], x -> x + 1);
-- []

SELECT transform(ARRAY[5, 6], x -> x + 1);
-- [6, 7]

SELECT transform(ARRAY[5, NULL, 6], x -> coalesce(x, 0) + 1);
-- [6, 1, 7]

SELECT transform(ARRAY['x', 'abc', 'z'], x -> x || '0');
-- ['x0', 'abc0', 'z0']

SELECT transform(ARRAY[ARRAY[1, NULL, 2], ARRAY[3, NULL]],
                 a -> filter(a, x -> x IS NOT NULL));
-- [[1, 2], [3]]
```

#### zip()

**`zip(array1, array2[, ...])`** → array(row)

Merges the given arrays, element-wise, into a single array of rows. The M-th element of the N-th argument will be the N-th field of the M-th output element. If the arguments have an uneven length, missing values are filled with NULL.

```sql theme={null}
SELECT zip(ARRAY[1, 2], ARRAY['1b', null, '3b']);
-- [ROW(1, '1b'), ROW(2, null), ROW(null, '3b')]
```

#### zip\_with()

**`zip_with(array1, array2, function)`** → array(R)

Merges the given arrays, element-wise, into a single array using function. The M-th element of the N-th argument will be the N-th argument of the M-th invocation of function. If the arguments have an uneven length, missing values are filled with NULL.

```sql theme={null}
SELECT zip_with(ARRAY[1, 3, 5], ARRAY['a', 'b', 'c'],
                (x, y) -> (y, x));
-- [ROW('a', 1), ROW('b', 3), ROW('c', 5)]

SELECT zip_with(ARRAY[1, 2], ARRAY[3, 4],
                (x, y) -> x + y);
-- [4, 6]

SELECT zip_with(ARRAY['a', 'b', 'c'], ARRAY['d', 'e', 'f'],
                (x, y) -> concat(x, y));
-- ['ad', 'be', 'cf']

SELECT zip_with(ARRAY['a'], ARRAY['d', null, 'f'],
                (x, y) -> coalesce(x, y));
-- ['a', null, 'f']
```


# ASOF Join
Source: https://docs.dune.com/query-engine/Functions-and-operators/asof-join

ASOF JOIN in DuneSQL performs nearest-neighbor matching using inequality predicates, making it ideal for temporal lookups like "latest price at trade time" or forward-fill balance snapshots.

## Overview

ASOF JOIN in **DuneSQL** lets you join two relations based on the *closest matching row* according to an inequality in the `ON` clause - typically on a timestamp or sequence field.

This is most useful when you need to:

* Get the **latest price as of trade time**
* Forward-fill sparse **balance** or **config/state** tables
* Enrich dense time grids (e.g. hourly/daily) from sparse event data
* Tracking actions of an ENS across addresses over time.
* Tracking actions of EIP-7702 enabled wallets by the contract they authorized to.

Unlike standard joins, **ASOF JOIN does not require exact equality** — it picks the *nearest valid match* according to your inequality condition.

<Info>
  ASOF JOIN executes entirely at query time — it does not pre-materialize or store any helper tables. It is a runtime join optimized in the DuneSQL engine.
</Info>

## Syntax

```sql theme={null}
SELECT ...
FROM left_relation
ASOF [ LEFT ] JOIN right_relation
  ON <equality_conjuncts> AND <inequality_conjunct>
```

## Rules

* **Exactly one inequality is required**, comparing a **right-side expression to a left-side expression** using `<`, `<=`, `>`, or `>=`.
* **Any number of equality predicates** (left.sym = right.sym) are allowed and encouraged.
* **ASOF JOIN** returns only matched left rows (like INNER JOIN).
* **ASOF LEFT JOIN** returns all left rows and fills NULL when no neighbor exists.

<Info>
  Typically, expressions compare timestamps: e.g. `prices.ts <= trades.ts` will pick the latest price at or before the trade.
</Info>

## Example

#### Dune's ETH balances over time

[See query on dune.com](https://dune.com/queries/6015716).

```sql theme={null}
select 
    d.timestamp,
    b.balance
from utils.days d
asof join tokens_ethereum.balances b
on b.address = 0x7058decc644317062f90525f4C1489AaF456e6B3 --dune.eth
    and b.token_standard = 'native' -- native ETH
    and b.block_time <= d.timestamp -- ASOF JOIN condition
```

```
-- output
| timestamp                | balance               |
| ------------------------ | --------------------- |
| 2020-02-27 00:00         | 0.006315391776612467  |
| 2020-02-28 00:00         | 0.006315391776612467  |

```

#### Latest price at trade time

[See query on dune.com](https://dune.com/queries/6015749).

```sql theme={null}
WITH
  trades(ts, sym) AS (VALUES 
    (TIMESTAMP '2024-01-01 09:30:05', 'ABC'),
    (TIMESTAMP '2024-01-01 09:30:07', 'ABC')
  ),
  quotes(ts, sym, price) AS (VALUES 
    (TIMESTAMP '2024-01-01 09:30:00', 'ABC', 100.0),
    (TIMESTAMP '2024-01-01 09:30:06', 'ABC', 101.5)
  )
SELECT trades.ts, quotes.price
FROM trades 
ASOF JOIN quotes ON trades.sym = quotes.sym AND quotes.ts <= trades.ts
ORDER BY 1
```

```
-- output
| ts                       | price                 |
| ------------------------ | --------------------- |
| 2024-01-01 09:30:05      | 100.0                 |
| 2024-01-01 09:30:07      | 101.5                 |
```

#### Forward-fill with ASOF LEFT JOIN

[See query on dune.com](https://dune.com/queries/6015744).

```sql theme={null}
WITH
  readings(read_time) AS (
    VALUES (TIMESTAMP '2024-01-01 10:00:00'),
           (TIMESTAMP '2024-01-01 10:05:00')
  ),
  calibrations(effective_time, factor) AS (
    VALUES (TIMESTAMP '2024-01-01 10:01:00', 1.02)
  )
SELECT readings.read_time, calibrations.factor
FROM readings ASOF LEFT JOIN calibrations
  ON calibrations.effective_time >= readings.read_time
ORDER BY 1
```

```
-- output
| read_time                | factor                |
| ------------------------ | --------------------- |
| 2024-01-01 10:00:00      | 1.02                  |
| 2024-01-01 10:05:00      | NULL                  |
```

## Performance

ASOF JOIN consistently outperforms LEAD() + range joins for large temporal enrichments.
Below is a rounded summary from production-scale testing (millions of rows):

<Tip>
  ASOF JOIN combines **cleaner SQL** and **runtime performance gains** when data is sparse or when “nearest match” logic is required.
</Tip>

## When to use ASOF JOIN

**✅ Recommended when:**

* You need a point-in-time snapshot (latest state, price, config)
* You are forward-filling sparse events into a regular time spine
* Data is sparse or high-cardinality (wallet balances, token prices)

**⚠️ Consider alternatives when:**

* You just need window aggregates (e.g. moving averages) → use window functions
* You already materialize reusable helper tables with valid ranges → consider pre-filled models

## Limitations

* **Exactly one inequality** is required in the ON clause.
* Joins based on multiple inequalities are not supported — add extra conditions via equality or `WHERE`.

## Best Practices

* **Always constrain with equality first** (token, address, etc.) to avoid scanning irrelevant rows.
* Use `ASOF LEFT` when you need to preserve all left rows, even if no match exists.
* Prefer `<=` or `>=` for clear open/closed interval intent.
* Document the direction, as inequality can compare from right to left or from left to right (e.g., `right.ts <= left.ts` or `left.ts >= right.ts`):
  * `<=` → “most recent up to this timestamp” (historical lookup)
  * `>=` → “next upcoming record” (future-effective lookup)

<Tip>
  Think in terms of **“as of X, what was true?”** — that’s the strongest signal that ASOF JOIN is appropriate.
</Tip>


# Base58 functions
Source: https://docs.dune.com/query-engine/Functions-and-operators/base58



Base58 is a binary-to-text encoding scheme that is commonly used in Bitcoin and Solana. It uses an alphabet of 58 characters, which is the same as the Base64 encoding scheme, but omits the characters `0`, `O`, `I`, and `l` to avoid confusion between similar-looking letters and numbers.

You can use the `from_base58` function to convert a Base58-encoded string to a `VARBINARY` value. For example, the following query converts the Base58-encoded string `3DZBMRwnSU8f` to a `VARBINARY` value:

```sql theme={null}
SELECT 
    from_base58('3DZBMRwnSU8f')
-- results in VARBINARY 0x030094357700000000
```

Now that we are able to convert Base58-encoded strings to `VARBINARY` values, we can use the `bytearray_to_bigint` function to convert the `VARBINARY` value to a `BIGINT` value. However, we need to consider more things:

1. The decoded `VARBINARY` value does not only contain the data we want to convert to a `BIGINT` value. It also contains a discriminator that indicates which function of a solana program was called. We need to remove this discriminator before we can convert the `VARBINARY` value to a `BIGINT` value. We do this by using the `bytearray_substring` function.

2. Solana uses little-endian byte order, so we need to reverse the byte order before we can convert the `VARBINARY` value to a `BIGINT` value. We do this by using the `bytearray_reverse` function.

```sql theme={null}
SELECT 
    bytearray_to_bigint(bytearray_reverse(bytearray_substring(from_base58('3DZBMRwnSU8f'), 2, 8))) as token_sold_amount
-- results in BIGINT 2000000000
```

In a real-world scenario, here is how you would use these functions to decode a Base58-encoded string that represents a token amount in a Solana swap transaction:

```sql theme={null}
SELECT
sp.call_inner_instructions[1].data
,from_base58(sp.call_inner_instructions[1].data) as first_step
,bytearray_substring(from_base58(sp.call_inner_instructions[1].data), 2, 8) as second_step
,bytearray_reverse(bytearray_substring(from_base58(sp.call_inner_instructions[1].data), 2, 8)) as third_step
,bytearray_to_bigint(bytearray_reverse(bytearray_substring(from_base58(sp.call_inner_instructions[1].data), 2, 8))) as decoded_amount
FROM whirlpool_solana.whirlpool_call_swap sp
WHERE sp.account_whirlpool = '7qbRF6YsyGuLUVs6Y1q64bdVrfe4ZcUUz1JRdoVNUJnm'
AND call_tx_id = '44kmeC1edSfp21K5kKNVViJvLHG8XQqqu3KbHsrYcYZGmopWwBgP48c9u1DRBMGtQcbvyxd2TT8syY7ZvwpHqkhF'
and call_block_slot = 187701147
```

[→ Query in Dune](https://dune.com/queries/2846422)

<tip> This specific query decodes the token amount that was sold in a Solana swap transaction. While probably applicable for lots of other solana programs, it is not guaranteed to work for all solana programs. You might need to adjust the query to your specific use case, depending on the solana program you are querying. </tip>

## Functions

#### from\_base58()

**`from_base58(varchar)`** → `varbinary`

Converts a Base58-encoded string to a `VARBINARY` value.

```sql theme={null}
SELECT 
    from_base58('3DZBMRwnSU8f')
-- results in VARBINARY 0x030094357700000000
```

#### to\_base58()

**`to_base58(varbinary)`** → `varchar`

Converts a `VARBINARY` value to a Base58-encoded string.

```sql theme={null}
SELECT 
    to_base58(0x030094357700000000)
-- results in base58 encoded varchar 3DZBMRwnSU8f
```


# Binary
Source: https://docs.dune.com/query-engine/Functions-and-operators/binary

Overview of binary operators and functions in DuneSQL.

### Binary operators

The `||` operator performs concatenation.

### Binary functions

#### concat()

**`concat(binary1, ..., binaryN)`** → varbinary

Returns the concatenation of binary1, binary2, ..., binaryN. This function provides the same functionality as the SQL-standard concatenation operator (||).

#### length()

**`length(binary)`** → bigint

Returns the length of binary in bytes.

#### lpad()

**`lpad(binary, size, padbinary)`** → varbinary

Left pads binary to size bytes with padbinary. If size is less than the length of binary, the result is truncated to size characters. size must not be negative and padbinary must be non-empty.

#### rpad()

**`rpad(binary, size, padbinary)`** → varbinary

Right pads binary to size bytes with padbinary. If size is less than the length of binary, the result is truncated to size characters. size must not be negative and padbinary must be non-empty.

#### substr()

**`substr(binary, start)`** → varbinary

Returns the rest of binary from the starting position start, measured in bytes. Positions start with 1. A negative starting position is interpreted as being relative to the end of the string.

**`substr(binary, start, length)`** → varbinary

Returns a substring from binary of length length from the starting position start, measured in bytes. Positions start with 1. A negative starting position is interpreted as being relative to the end of the string.

#### reverse()

**`reverse(binary)`** → varbinary

Returns binary with the bytes in reverse order.

### Base64 encoding functions

#### from\_base64()

**`from_base64(string)`** → varbinary

Decodes binary data from the base64 encoded string.

#### to\_base64()

**`to_base64(binary)`** → varchar

Encodes binary into a base64 string representation.

#### from\_base64url()

**`from_base64url(string)`** → varbinary

Decodes binary data from the base64 encoded string using the URL safe alphabet.

#### to\_base64url()

**`to_base64url(binary)`** → varchar

Encodes binary into a base64 string representation using the URL safe alphabet.

#### from\_base32()

**`from_base32(string)`** → varbinary

Decodes binary data from the base32 encoded string.

#### to\_base32()

**`to_base32(binary)`** → varchar

Encodes binary into a base32 string representation.

### Hex encoding functions

#### from\_hex()

**`from_hex(string)`** → varbinary

Decodes binary data from the hex encoded string.

#### to\_hex()

**`to_hex(binary)`** → varchar

Encodes binary into a hex string representation.

### Integer encoding functions

#### from\_big\_endian\_32()

**`from_big_endian_32(binary)`** → integer

Decodes the 32-bit two’s complement big-endian binary. The input must be exactly 4 bytes.

#### to\_big\_endian\_32()

**`to_big_endian_32(integer)`** → varbinary

Encodes integer into a 32-bit two’s complement big-endian format.

#### from\_big\_endian\_64()

**`from_big_endian_64(binary)`** → bigint

Decodes the 64-bit two’s complement big-endian binary. The input must be exactly 8 bytes.

#### to\_big\_endian\_64()

**`to_big_endian_64(bigint)`** → varbinary

Encodes bigint into a 64-bit two’s complement big-endian format.

### Floating-point encoding functions

#### from\_ieee754\_32()

**`from_ieee754_32(binary)`** → real

Decodes the 32-bit big-endian binary in IEEE 754 single-precision floating-point format. The input must be exactly 4 bytes.

#### to\_ieee754\_32()

**`to_ieee754_32(real)`** → varbinary

Encodes real into a 32-bit big-endian binary according to IEEE 754 single-precision floating-point format.

#### from\_ieee754\_64()

**`from_ieee754_64(binary)`** → double

Decodes the 64-bit big-endian binary in IEEE 754 double-precision floating-point format. The input must be exactly 8 bytes.

#### to\_ieee754\_64()

**`to_ieee754_64(double)`** → varbinary

Encodes double into a 64-bit big-endian binary according to IEEE 754 double-precision floating-point format.

### Hashing functions

#### crc32()

**`crc32(binary)`** → bigint

Computes the CRC-32 of binary. For general purpose hashing, use xxhash64(), as it is much faster and produces a better quality hash.

#### md5()

**`md5(binary)`** → varbinary

Computes the MD5 hash of binary.

#### sha1()

**`sha1(binary)`** → varbinary

Computes the SHA1 hash of binary.

#### sha256()

**`sha256(binary)`** → varbinary

Computes the SHA256 hash of binary.

#### sha512()

**`sha512(binary)`** → varbinary

Computes the SHA512 hash of binary.

#### spooky\_hash\_v2\_32()

**`spooky_hash_v2_32(binary)`** → varbinary

Computes the 32-bit SpookyHashV2 hash of binary.

#### spooky\_hash\_v2\_64()

**`spooky_hash_v2_64(binary)`** → varbinary

Computes the 64-bit SpookyHashV2 hash of binary.

#### xxhash64()

**`xxhash64(binary)`** → varbinary

Computes the 64-bit xxHash hash of binary.

### HMAC functions

#### hmac\_md5()

**`hmac_md5(binary, key)`** → varbinary

Computes HMAC with MD5 of binary with the given key.

#### hmac\_sha1()

**`hmac_sha1(binary, key)`** → varbinary

Computes HMAC with SHA1 of binary with the given key.

#### hmac\_sha256()

**`hmac_sha256(binary, key)`** → varbinary

Computes HMAC with SHA256 of binary with the given key.

#### hmac\_sha512()

**`hmac_sha512(binary, key)`** → varbinary

Computes HMAC with SHA512 of binary with the given key.


# Bitwise
Source: https://docs.dune.com/query-engine/Functions-and-operators/bitwise



#### bit\_count()

**`bit_count(x, bits)`** → bigint
Count the number of bits set in x (treated as bits-bit signed integer) in 2’s complement representation:

```sql theme={null}
SELECT bit_count(9, 64); -- 2
SELECT bit_count(9, 8); -- 2
SELECT bit_count(-7, 64); -- 62
SELECT bit_count(-7, 8); -- 6
```

#### bitwise\_and()

**`bitwise_and(x, y)`** → bigint
Returns the bitwise AND of x and y in 2’s complement representation.

Bitwise AND of 19 (binary: 10011) and 25 (binary: 11001) results in 17 (binary: 10001):

```sql theme={null}
SELECT bitwise_and(19,25); -- 17
```

**`bitwise_not(x)`** → bigint

Returns the bitwise NOT of x in 2’s complement representation (NOT x = -x - 1):

```sql theme={null}
SELECT bitwise_not(-12); --  11
SELECT bitwise_not(19);  -- -20
SELECT bitwise_not(25);  -- -26
```

#### bitwise\_or()

**`bitwise_or(x, y)`** → bigint

Returns the bitwise OR of x and y in 2’s complement representation.

Bitwise OR of 19 (binary: 10011) and 25 (binary: 11001) results in 27 (binary: 11011):

```sql theme={null}
SELECT bitwise_or(19,25); -- 27
```

#### bitwise\_xor()

**`bitwise_xor(x, y)`** → bigint

Returns the bitwise XOR of x and y in 2’s complement representation.

Bitwise XOR of 19 (binary: 10011) and 25 (binary: 11001) results in 10 (binary: 01010):

```sql theme={null}
SELECT bitwise_xor(19,25); -- 10
```

#### bitwise\_left\_shift()

**`bitwise_left_shift(value, shift)`** → \[same as value]
Returns the left shifted value of value.

Shifting 1 (binary: 001) by two bits results in 4 (binary: 00100):

```sql theme={null}
SELECT bitwise_left_shift(1, 2); -- 4
```

Shifting 5 (binary: 0101) by two bits results in 20 (binary: 010100):

```sql theme={null}
SELECT bitwise_left_shift(5, 2); -- 20
```

Shifting a value by 0 always results in the original value:

```sql theme={null}
SELECT bitwise_left_shift(20, 0); -- 20
SELECT bitwise_left_shift(42, 0); -- 42
```

Shifting 0 by a shift always results in 0:

```sql theme={null}
SELECT bitwise_left_shift(0, 1); -- 0
SELECT bitwise_left_shift(0, 2); -- 0
```

#### bitwise\_right\_shift()

**`bitwise_right_shift(value, shift)`** → \[same as value]

Returns the logical right shifted value of value.

Shifting 8 (binary: 1000) by three bits results in 1 (binary: 001):

```sql theme={null}
SELECT bitwise_right_shift(8, 3); -- 1
```

Shifting 9 (binary: 1001) by one bit results in 4 (binary: 100):

```sql theme={null}
SELECT bitwise_right_shift(9, 1); -- 4
```

Shifting a value by 0 always results in the original value:

```sql theme={null}
SELECT bitwise_right_shift(20, 0); -- 20
SELECT bitwise_right_shift(42, 0); -- 42
```

Shifting a value by 64 or more bits results in 0:

```sql theme={null}
SELECT bitwise_right_shift( 12, 64); -- 0
SELECT bitwise_right_shift(-45, 64); -- 0
```

Shifting 0 by a shift always results in 0:

```sql theme={null}
SELECT bitwise_right_shift(0, 1); -- 0
SELECT bitwise_right_shift(0, 2); -- 0
```

#### bitwise\_right\_shift\_arithmetic()

**`bitwise_right_shift_arithmetic(value, shift)`** → \[same as value]

Returns the arithmetic right shifted value of value.

Returns the same values as bitwise\_right\_shift() when shifting by less than 64 bits. Shifting by 64 or more bits results in 0 for a positive and -1 for a negative value:

```sql theme={null}
SELECT bitwise_right_shift_arithmetic( 12, 64); -- 0
SELECT bitwise_right_shift_arithmetic(-45, 64); -- -1
```


# Chain Utility Functions
Source: https://docs.dune.com/query-engine/Functions-and-operators/chain-utility-functions

Helper functions for linking to chain explorers and transactions.

# Chain Utility Functions

Dune SQL offers a series of functions designed to ease some common tasks when working with blockchain data.

These functions are helpful to generate links to the explorer of a chain, to specific addresses, or to specific transactions.
Most of the time you'll want to use `get_href()` in combination with one of the other functions to generate a clickable link to a specific address or transaction.

```sql theme={null}
Select
    get_href(get_chain_explorer_address('ethereum', to), cast(to as varchar))
FROM ethereum.transactions
limit 100
```

This sql code will generate a clickable link pointing to the explorer of the Ethereum chain for each address in the `to` column. The displayed link will be the address itself.

You can find all the functions in action on this dashboard: [Chain Utility Functions](https://dune.com/dune/chain-utility-functions)

#### get\_href()

**`get_href(varchar, varchar)`** → varchar

This function converts a link and associated text into a clickable hyperlink. The first argument is the link, and the second argument is the text to be displayed.

```sql theme={null}
SELECT 
    get_href('https://dune.com', 'Dune')
```

#### get\_chain\_explorer\_address()

**`get_chain_explorer_address(varchar, varchar)`** → varchar

This function generates a URL for the explorer of a specified chain (provided as a varchar) for a given address (also provided as a varchar).

```sql theme={null}
SELECT 
    get_chain_explorer_address('ethereum', cast(to as varchar)) 
FROM ethereum.transactions 
limit 100
```

#### get\_chain\_explorer\_address()

**`get_chain_explorer_address(varchar, varbinary)`** → varchar

This function generates a URL for the explorer of a specified chain (provided as a varchar) for a given address (provided as a varbinary).

```sql theme={null}
SELECT 
    get_chain_explorer_address('ethereum', to) 
FROM ethereum.transactions 
limit 100
```

#### get\_chain\_explorer\_tx\_hash()

**`get_chain_explorer_tx_hash(varchar, varchar)`** → varchar

This function generates a URL for the explorer of a specified chain (provided as a varchar) for a given transaction hash (also provided as a varchar).

```sql theme={null}
SELECT 
    get_chain_explorer_tx_hash('ethereum', cast(hash as varchar)) 
FROM ethereum.transactions 
limit 100
```

#### get\_chain\_explorer\_tx\_hash()

**`get_chain_explorer_tx_hash(varchar, varbinary)`** → varchar

This function generates a URL for the explorer of a specified chain (provided as a varchar) for a given transaction hash (provided as a varbinary).

```sql theme={null}
SELECT 
    get_chain_explorer_tx_hash('ethereum', hash) 
FROM ethereum.transactions 
limit 100
```

#### get\_chain\_explorer()

**`get_chain_explorer(varchar)`** → varchar

This function returns the URL of the explorer for a specified chain (provided as a varchar).

```sql theme={null}
SELECT 
    get_chain_explorer('ethereum')
```

#### get\_balancer\_link()

**`get_balancer_link(varchar, varchar)`** → varchar

This function returns a link to access a specific pool on the Balancer app. The first argument is the chain, and the second argument is the pool Id (provided as varchar).

```sql theme={null}
SELECT 
    get_balancer_link(blockchain, cast(pool_id as varchar))
FROM balancer.trades
limit 100
```

#### get\_balancer\_link()

**`get_balancer_link(varchar, varbinary)`** → varchar

This function returns a link to access a specific pool on the Balancer app. The first argument is the chain, and the second argument is the pool Id (provided as varbinary).

```sql theme={null}
SELECT 
    get_balancer_link(blockchain, pool_id)
FROM balancer.trades
limit 100
```

#### all\_evm\_chains()

**`all_evm_chains()`** → array(varchar)

```sql theme={null}
SELECT 
    all_evm_chains()
```

This function returns an array listing all the EVM chains available on Dune.

#### all\_op\_chains()

**`all_op_chains()`** → array(varchar)

```sql theme={null}
SELECT 
    all_op_chains()
```

This function returns an array listing all the Optimism chains available on Dune.


# Comparisons
Source: https://docs.dune.com/query-engine/Functions-and-operators/comparison



<h3>
  Comparison operators \\
</h3>

| Operator | Description                                 |
| -------- | ------------------------------------------- |
| `<`      | Less than                                   |
| `>`      | Greater than                                |
| `<=`     | Less than or equal to                       |
| `>=`     | Greater than or equal to                    |
| `=`      | Equal                                       |
| `<>`     | Not equal                                   |
| `!=`     | Not equal (non-standard but popular syntax) |

### Range operator: BETWEEN

The `BETWEEN` operator tests if a value is within a specified range. It
uses the syntax `value BETWEEN min AND max`:

```sql theme={null}
    SELECT 3 BETWEEN 2 AND 6;
```

The statement shown above is equivalent to the following statement:

```sql theme={null}
    SELECT 3 >= 2 AND 3 <= 6;
```

To test if a value does not fall within the specified range use
`NOT BETWEEN`:

```sql theme={null}
    SELECT 3 NOT BETWEEN 2 AND 6;
```

The statement shown above is equivalent to the following statement:

```sql theme={null}
    SELECT 3 < 2 OR 3 > 6;
```

A `NULL` in a `BETWEEN` or `NOT BETWEEN` statement is evaluated using
the standard `NULL` evaluation rules applied to the equivalent
expression above:

```sql theme={null}
    SELECT NULL BETWEEN 2 AND 4; -- null

    SELECT 2 BETWEEN NULL AND 6; -- null

    SELECT 2 BETWEEN 3 AND NULL; -- false

    SELECT 8 BETWEEN NULL AND 6; -- false
```

The `BETWEEN` and `NOT BETWEEN` operators can also be used to evaluate
any orderable type. For example, a `VARCHAR`:

```sql theme={null}
    SELECT 'Paul' BETWEEN 'John' AND 'Ringo'; -- true
```

Note that the value, min, and max parameters to `BETWEEN` and
`NOT BETWEEN` must be the same type. For example, Trino will produce an
error if you ask it if John is between 2.3 and 35.2.

### IS NULL and IS NOT NULL

The `IS NULL` and `IS NOT NULL` operators test whether a value is null
(undefined). Both operators work for all data types.

Using `NULL` with `IS NULL` evaluates to true:

```sql theme={null}
    select NULL IS NULL; -- true
```

But any other constant does not:

```sql theme={null}
    SELECT 3.0 IS NULL; -- false
```

<h3>
  IS DISTINCT FROM and IS NOT DISTINCT FROM \\
</h3>

In SQL a `NULL` value signifies an unknown value, so any comparison
involving a `NULL` will produce `NULL`. The `IS DISTINCT FROM` and
`IS NOT DISTINCT FROM` operators treat `NULL` as a known value and both
operators guarantee either a true or false outcome even in the presence
of `NULL` input:

```sql theme={null}
    SELECT NULL IS DISTINCT FROM NULL; -- false

    SELECT NULL IS NOT DISTINCT FROM NULL; -- true
```

In the example shown above, a `NULL` value is not considered distinct
from `NULL`. When you are comparing values which may include `NULL` use
these operators to guarantee either a `TRUE` or `FALSE` result.

The following truth table demonstrate the handling of `NULL` in
`IS DISTINCT FROM` and `IS NOT DISTINCT FROM`:

| a      | b      | a = b   | a \<> b | a DISTINCT b | a NOT DISTINCT b |
| ------ | ------ | ------- | ------- | ------------ | ---------------- |
| `1`    | `1`    | `TRUE`  | `FALSE` | `FALSE`      | > `TRUE`         |
| `1`    | `2`    | `FALSE` | `TRUE`  | `TRUE`       | > `FALSE`        |
| `1`    | `NULL` | `NULL`  | `NULL`  | `TRUE`       | > `FALSE`        |
| `NULL` | `NULL` | `NULL`  | `NULL`  | `FALSE`      | > `TRUE`         |

### GREATEST and LEAST

These functions are not in the SQL standard, but are a common extension.
Like most other functions in Trino, they return null if any argument is
null. Note that in some other databases, such as PostgreSQL, they only
return null if all arguments are null.

The following types are supported: `DOUBLE`, `BIGINT`, `VARCHAR`,
`TIMESTAMP`, `TIMESTAMP WITH TIME ZONE`, `DATE`

#### greatest ()

**`greatest(value1, value2, ..., valueN)`** →  \[same as input]

Returns the largest of the provided values.

#### least ()

**`least(value1, value2, ..., valueN)`** →  \[same as input]

Returns the smallest of the provided values.

<h3>
  Quantified comparison predicates: ALL, ANY and SOME \\
</h3>

The `ALL`, `ANY` and `SOME` quantifiers can be used together with
comparison operators in the following way:

```text theme={null}
expression operator quantifier ( subquery )
```

For example:

```sql theme={null}

    SELECT 'hello' = ANY (VALUES 'hello', 'world'); -- true

    SELECT 21 < ALL (VALUES 19, 20, 21); -- false

    SELECT 42 >= SOME (SELECT 41 UNION ALL SELECT 42 UNION ALL SELECT 43); -- true
```

Here are the meanings of some quantifier and comparison operator
combinations:

| Expression       | Meaning                                                                                              |
| ---------------- | ---------------------------------------------------------------------------------------------------- |
| `A = ALL (...)`  | Evaluates to `true` when `A` is equal to all values.                                                 |
| `A <> ALL (...)` | Evaluates to `true` when `A` doesn't match any value.                                                |
| `A < ALL (...)`  | Evaluates to `true` when `A` is smaller than the smallest value.                                     |
| `A = ANY (...)`  | Evaluates to `true` when `A` is equal to any of the values. This form is equivalent to `A IN (...)`. |
| `A <> ANY (...)` | Evaluates to `true` when `A` doesn't match one or more values.                                       |
| `A < ANY (...)`  | Evaluates to `true` when `A` is smaller than the biggest value.                                      |

`ANY` and `SOME` have the same meaning and can be used interchangeably.

### Pattern comparison: LIKE

The `LIKE` operator can be used to compare values with a pattern:

```text theme={null}
    ... column [NOT] LIKE 'pattern' ESCAPE 'character';
```

Matching characters is case sensitive, and the pattern supports two
symbols for matching:

* `_` matches any single character
* `%` matches zero or more characters

Typically it is often used as a condition in `WHERE` statements. An
example is a query to find all continents starting with `E`, which
returns `Europe`:

```sql theme={null}
    SELECT * FROM (VALUES 'America', 'Asia', 'Africa', 'Europe', 'Australia', 'Antarctica') AS t (continent)
    WHERE continent LIKE 'E%';
```

You can negate the result by adding `NOT`, and get all other continents,
all not starting with `E`:

```sql theme={null}
    SELECT * FROM (VALUES 'America', 'Asia', 'Africa', 'Europe', 'Australia', 'Antarctica') AS t (continent)
    WHERE continent NOT LIKE 'E%';
```

If you only have one specific character to match, you can use the `_`
symbol for each character. The following query uses two underscores and
produces only `Asia` as result:

```sql theme={null}
    SELECT * FROM (VALUES 'America', 'Asia', 'Africa', 'Europe', 'Australia', 'Antarctica') AS t (continent)
    WHERE continent LIKE 'A__A';
```

The wildcard characters `_` and `%` must be escaped to allow you to
match them as literals. This can be achieved by specifying the `ESCAPE`
character to use:

```sql theme={null}
    SELECT 'South_America' LIKE 'South\_America' ESCAPE '\';
```

The above query returns `true` since the escaped underscore symbol
matches. If you need to match the used escape character as well, you can
escape it.

If you want to match for the chosen escape character, you simply escape
itself. For example, you can use `\\` to match for `''''`.


# Conditional expressions
Source: https://docs.dune.com/query-engine/Functions-and-operators/conditional

Guide to CASE, IF, and other conditional logic in DuneSQL.

### CASE

The standard SQL `CASE` expression has two forms. The "simple" form
searches each `value` expression from left to right until it finds one
that equals `expression`:

```text theme={null}
CASE expression
    WHEN value THEN result
    [ WHEN ... ]
    [ ELSE result ]
END
```

The `result` for the matching `value` is returned. If no match is found,
the `result` from the `ELSE` clause is returned if it exists, otherwise
null is returned. Example:

```sql theme={null}
    SELECT a,
           CASE a
               WHEN 1 THEN 'one'
               WHEN 2 THEN 'two'
               ELSE 'many'
           END
```

The "searched" form evaluates each boolean `condition` from left to
right until one is true and returns the matching `result`:

```text theme={null}
CASE
    WHEN condition THEN result
    [ WHEN ... ]
    [ ELSE result ]
END
```

If no conditions are true, the `result` from the `ELSE` clause is
returned if it exists, otherwise null is returned. Example:

```sql theme={null}
    SELECT a, b,
           CASE
               WHEN a = 1 THEN 'aaa'
               WHEN b = 2 THEN 'bbb'
               ELSE 'ccc'
           END
```

### IF

The `IF` expression has two forms, one supplying only a `true_value` and
the other supplying both a `true_value` and a `false_value`:

**`if(condition, true_value)`**

Evaluates and returns `true_value` if `condition` is true, otherwise
null is returned and `true_value` is not evaluated.

**`if(condition, true_value, false_value)`**

Evaluates and returns `true_value` if `condition` is true, otherwise
evaluates and returns `false_value`.

The following `IF` and `CASE` expressions are equivalent:

```sql theme={null}
SELECT
  orderkey,
  totalprice,
  IF(totalprice >= 150000, 'High Value', 'Low Value')
FROM tpch.sf1.orders;
```

```sql theme={null}
SELECT
  orderkey,
  totalprice,
  CASE
    WHEN totalprice >= 150000 THEN 'High Value'
    ELSE 'Low Value'
  END
FROM tpch.sf1.orders;
```

<h3>
  COALESCE \\
</h3>

**`coalesce(value1, value2\[, \...\])`**

Returns the f non-null `value` in the argument list. Like a `CASE`
expression, arguments are only evaluated if necessary.

### NULLIF

**`nullif(value1, value2)`**

Returns null if `value1` equals `value2`, otherwise returns `value1`.

### TRY

**`try(expression)`**

Evaluate an expression and handle certain types of errors by returning
`NULL`.

In cases where it is preferable that queries produce `NULL` or default
values instead of failing when corrupt or invalid data is encountered,
the `TRY` function may be useful. To specify default values, the `TRY`
function can be used in conjunction with the `COALESCE` function.

The following errors are handled by `TRY`:

* Division by zero
* Invalid cast or function argument
* Numeric value out of range

**`Examples`**

Source table with some invalid data:

```sql theme={null}
SELECT * FROM shipping;
```

```text theme={null}
origin_state | origin_zip | packages | total_cost
--------------+------------+----------+------------
California   |      94131 |       25 |        100
California   |      P332a |        5 |         72
California   |      94025 |        0 |        155
New Jersey   |      08544 |      225 |        490
(4 rows)
```

Query failure without `TRY`:

```sql theme={null}
SELECT CAST(origin_zip AS BIGINT) FROM shipping;
```

```text theme={null}
Query failed: Cannot cast 'P332a' to BIGINT
```

`NULL` values with `TRY`:

```sql theme={null}
SELECT TRY(CAST(origin_zip AS BIGINT)) FROM shipping;
```

```text theme={null}
origin_zip
------------
     94131
     NULL
     94025
     08544
(4 rows)
```

Query failure without `TRY`:

```sql theme={null}
SELECT total_cost / packages AS per_package FROM shipping;
```

```text theme={null}
Query failed: Division by zero
```

Default values with `TRY` and `COALESCE`:

```sql theme={null}
SELECT COALESCE(TRY(total_cost / packages), 0) AS per_package FROM shipping;
```

```text theme={null}
per_package
-------------
         4
        14
         0
        19
(4 rows)
```


# Conversions
Source: https://docs.dune.com/query-engine/Functions-and-operators/conversion



## Implicit Conversions

DuneSQL will implicitly convert numeric and character values to the correct type if such a conversion is possible.\
DuneSQL will not convert implicitly between character and numeric types.\
For example, a query that expects a `VARCHAR` will not automatically convert a `BIGINT` value to an equivalent `VARCHAR`.

When necessary, values can be explicitly cast to a particular type using the [cast function](#cast).

### Implicit Casting with numeric types

DuneSQL has added support for implicit casts when performing operations with `INT256` and `UINT256` and other numeric types like `INTEGER`, `BIGINTEGER`, `DECIMAL`, or `DOUBLE`.
This allows you to use `INT256` and `UINT256` without adding casts explicitly.

Whenever DuneSQL needs to find a common type for `INT256` or `UINT256` and another numeric type, it will generally go towards the bigger type.\
We consider `INT256` to be bigger than `UINT256`. In some cases, this might lead to an overflow error when trying to include `UINT256` and `INT256` values into the same expression.

`TINYINT`, `SMALLINT`, `INTEGER`, `BIGINT`, and `DECIMAL` type with zero scale, like `DECIMAL(2,0)` will be converted to `INT256` or `UINT256`.
Please note that some conversions to `UINT256` will fail, since this type cannot hold negative values.

For operations involving `INT256` or `UINT256` and `DECIMAL` type with non-zero scale, like `DECIMAL(2,1)`,
the result type is `DOUBLE`. Also, for operations involving `INT256` or `UINT256` and `REAL` or `DOUBLE` types, the result type is `DOUBLE`.
Please note that `DOUBLE` is an approximate numeric type and hence the conversion might lose some precision.
You can use explicit cast to override DuneSQL conversion rules.

With implicit conversion, this arithmetic expression:

```sql theme={null}
SELECT 2 * UINT256 '1';
```

will be equivalent to:

```sql theme={null}
SELECT CAST(2 AS UINT256) * UINT256 '1';
```

Similarly, this comparison:

```sql theme={null}
SELECT INT256 '1' > 0;
```

will be equivalent to:

```sql theme={null}
SELECT INT256 '1' > CAST(0 AS INT256);
```

DuneSQL uses implicit conversions in many other contexts. Here are some examples:

```sql theme={null}
SELECT COALESCE(1, INT256 '2');
-- will resolve to INT256
```

```sql theme={null}
SELECT CASE 
    WHEN false THEN BIGINT '0' 
    WHEN false THEN INT256 '1' 
    WHEN true THEN UINT256 '2' 
END;
-- will resolve to INT256
```

```sql theme={null}
SELECT * FROM (
    (VALUES TINYINT '0') 
    UNION 
    (VALUES INT256 '1') 
    UNION 
    (VALUES DOUBLE '2'));
-- will resolve to DOUBLE
```

### Conversion functions

#### cast()

**`cast(value AS type)`** → type

Explicitly cast a value as a type. This can be used to cast a varchar to
a numeric value type and vice versa.

#### try\_cast()

**`try_cast(value AS type)`** → type

Like `cast`, but returns `null` if the cast
fails.

### Formatting

#### format()

**`format(format, args\...)`** → varchar

Returns a formatted string using the specified [format
string](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Formatter.html#syntax)
and arguments:

```sql theme={null}
    SELECT format('%s%%', 123);
    -- '123%'

    SELECT format('%.5f', pi());
    -- '3.14159'

    SELECT format('%03d', 8);
    -- '008'

    SELECT format('%,.2f', 1234567.89);
    -- '1,234,567.89'

    SELECT format('%-7s,%7s', 'hello', 'world');
    -- 'hello  ,  world'

    SELECT format('%2$s %3$s %1$s', 'a', 'b', 'c');
    -- 'b c a'

    SELECT format('%1$tA, %1$tB %1$te, %1$tY', date '2006-07-04');
    -- 'Tuesday, July 4, 2006'
```

#### format\_number()

**`format_number(number)`** → varchar
Returns a formatted string using a unit symbol:

SELECT format\_number(123456); -- '123K'
SELECT format\_number(1000000); -- '1M'

### Miscellaneous

#### typeof()

**`typeof(expr)`** → varchar

Returns the name of the type of the provided expression:

```sql theme={null}
    SELECT typeof(123); -- integer
    SELECT typeof('cat'); -- varchar(3)
    SELECT typeof(cos(2) + 1.5); -- double
```


# Date and time functions and operators
Source: https://docs.dune.com/query-engine/Functions-and-operators/datetime



These functions and operators operate on
[`date and time data types`](/query-engine/datatypes).

### Date and time operators

| Operator | Example                                             | Result                    |
| -------- | --------------------------------------------------- | ------------------------- |
| `+`      | `date '2012-08-08' + interval '2' day`              | `2012-08-10`              |
| `+`      | `time '01:00' + interval '3' hour`                  | `04:00:00.000`            |
| `+`      | `timestamp '2012-08-08 01:00' + interval '29' hour` | `2012-08-09 06:00:00.000` |
| `+`      | `timestamp '2012-10-31 01:00' + interval '1' month` | `2012-11-30 01:00:00.000` |
| `+`      | `interval '2' day + interval '3' hour`              | `2 03:00:00.000`          |
| `+`      | `interval '3' year + interval '5' month`            | `3-5`                     |
| `-`      | `date '2012-08-08' - interval '2' day`              | `2012-08-06`              |
| `-`      | `time '01:00' - interval '3' hour`                  | `22:00:00.000`            |
| `-`      | `timestamp '2012-08-08 01:00' - interval '29' hour` | `2012-08-06 20:00:00.000` |
| `-`      | `timestamp '2012-10-31 01:00' - interval '1' month` | `2012-09-30 01:00:00.000` |
| `-`      | `interval '2' day - interval '3' hour`              | `1 21:00:00.000`          |
| `-`      | `interval '3' year - interval '5' month`            | `2-7`                     |

### Time zone conversion

The `AT TIME ZONE` operator sets the time zone of a timestamp:

```sql theme={null}
    SELECT timestamp '2012-10-31 01:00 UTC';
    -- 2012-10-31 01:00:00.000 UTC

    SELECT timestamp '2012-10-31 01:00 UTC' AT TIME ZONE 'America/Los_Angeles';
    -- 2012-10-30 18:00:00.000 America/Los_Angeles
```

### Date and time functions

#### current\_date

**`current_date`**

Returns the current date as of the start of the query.

#### current\_time

**`current_time`**

Returns the current time with time zone as of the start of the query.

#### current\_timestamp

**`current_timestamp`**

Returns the current timestamp with time zone as of the start of the
query, with `3` digits of subsecond precision,

#### current\_timestamp()

**`current_timestamp(p)`**

Returns the current `timestamp with time zone
as `timestamp-with-time-zone-data-type`of the start of the query, with`p\` digits of subsecond precision:

```sql theme={null}
    SELECT current_timestamp(6);
    -- 2020-06-24 08:25:31.759993 America/Los_Angeles
```

#### current\_timezone()

**`current_timezone()`** → varchar

Returns the current time zone in the format defined by IANA (e.g.,
`America/Los_Angeles`) or as fixed offset from UTC (e.g., `+08:35`)

#### date()

**`date(x)`** → date

This is an alias for `CAST(x AS date)`.

#### last\_day\_of\_month()

**`last_day_of_month(x)`** → date

Returns the last day of the month.

#### from\_iso8601\_timestamp()

**`from_iso8601_timestamp(string)`** → timestamp(3) with time zone

Parses the ISO 8601 formatted date `string`, optionally with time and
time zone, into a `timestamp(3) with time zone`. The time defaults to
`00:00:00.000`, and the time zone defaults to the session time zone:

```sql theme={null}
    SELECT from_iso8601_timestamp('2020-05-11');
    -- 2020-05-11 00:00:00.000 America/Vancouver

    SELECT from_iso8601_timestamp('2020-05-11T11:15:05');
    -- 2020-05-11 11:15:05.000 America/Vancouver

    SELECT from_iso8601_timestamp('2020-05-11T11:15:05.055+01:00');
    -- 2020-05-11 11:15:05.055 +01:00
```

#### from\_iso8601\_timestamp\_nanos()

**`from_iso8601_timestamp_nanos(string)`** → timestamp(9) with time zone

Parses the ISO 8601 formatted date and time `string`. The time zone
defaults to the session time zone:

```sql theme={null}
    SELECT from_iso8601_timestamp_nanos('2020-05-11T11:15:05');
    -- 2020-05-11 11:15:05.000000000 America/Vancouver

    SELECT from_iso8601_timestamp_nanos('2020-05-11T11:15:05.123456789+01:00');
    -- 2020-05-11 11:15:05.123456789 +01:00
```

#### from\_iso8601\_date()

**`from_iso8601_date(string)`** → date

Parses the ISO 8601 formatted date `string` into a `date`. The date can
be a calendar date, a week date using ISO week numbering, or year and
day of year combined:

```sql theme={null}
    SELECT from_iso8601_date('2020-05-11');
    -- 2020-05-11

    SELECT from_iso8601_date('2020-W10');
    -- 2020-03-02

    SELECT from_iso8601_date('2020-123');
    -- 2020-05-02
```

#### at\_timezone()

**`at_timezone(timestamp, zone)`** → timestamp(p) with time zone

Returns the timestamp specified in timestamp with the time zone converted from the session time zone to the time zone specified in zone with precision p. In the following example, the session time zone is set to America/New\_York, which is three hours ahead of America/Los\_Angeles:

```sql theme={null}
SELECT current_timezone()
-- America/New_York
```

```sql theme={null}
SELECT at_timezone(TIMESTAMP '2022-11-01 09:08:07.321', 'America/Los_Angeles')
-- 2022-11-01 06:08:07.321 America/Los_Angeles
```

#### with\_timezone()

**`with_timezone(timestamp, zone)`** → timestamp(p) with time zone

Returns the timestamp specified in `timestamp` with the time zone specified in `zone` with precision `p`.

```sql theme={null}
SELECT current_timezone()
-- America/New_York

SELECT with_timezone(TIMESTAMP '2022-11-01 09:08:07.321', 'America/Los_Angeles')
-- 2022-11-01 09:08:07.321 America/Los_Angeles
```

#### from\_unixtime()

**`from_unixtime(unixtime)`** → timestamp(3) with time zone

Returns the UNIX timestamp `unixtime` as a timestamp with time zone.
`unixtime` is the number of seconds since `1970-01-01 00:00:00 UTC`.

#### from\_unixtime()

**`from_unixtime(unixtime, zone)`** → timestamp(3) with time zone

Returns the UNIX timestamp `unixtime` as a timestamp with time zone
using `zone` for the time zone. `unixtime` is the number of seconds
since `1970-01-01 00:00:00 UTC`.

#### from\_unixtime()

**`from_unixtime(unixtime, hours, minutes)`** → timestamp(3) with time zone

Returns the UNIX timestamp `unixtime` as a timestamp with time zone
using `hours` and `minutes` for the time zone offset. `unixtime` is the
number of seconds since `1970-01-01 00:00:00` in `double` data type.

#### from\_unixtime\_nanos()

**`from_unixtime_nanos(unixtime)`** → timestamp(9) with time zone

Returns the UNIX timestamp `unixtime` as a timestamp with time zone.
`unixtime` is the number of nanoseconds since
`1970-01-01 00:00:00.000000000 UTC`:

```sql theme={null}
    SELECT from_unixtime_nanos(100);
    -- 1970-01-01 00:00:00.000000100 UTC

    SELECT from_unixtime_nanos(DECIMAL '1234');
    -- 1970-01-01 00:00:00.000001234 UTC

    SELECT from_unixtime_nanos(DECIMAL '1234.499');
    -- 1970-01-01 00:00:00.000001234 UTC

    SELECT from_unixtime_nanos(DECIMAL '-1234');
    -- 1969-12-31 23:59:59.999998766 UTC
```

#### now()

**`now()`** → timestamp(3) with time zone

This is an alias for `current_timestamp`.

#### to\_iso8601()

**`to_iso8601(x)`** → varchar

Formats `x` as an ISO 8601 string. `x` can be date, timestamp, or
timestamp with time zone.

#### to\_milliseconds()

**`to_milliseconds(interval)`** → bigint

Returns the day-to-second `interval` as milliseconds.

#### to\_unixtime()

**`to_unixtime(timestamp)`** → double

Returns `timestamp` as a UNIX timestamp.

### Truncation function

The `date_trunc` function supports the following units:

| Unit      | Example                   | Truncated Value           |
| --------- | ------------------------- | ------------------------- |
| `second`  | `2001-08-22 03:04:05.000` | `2001-08-22 03:04:05.000` |
| `minute`  | `2001-08-22 03:04:00.000` | `2001-08-22 03:04:00.000` |
| `hour`    | `2001-08-22 03:00:00.000` | `2001-08-22 03:00:00.000` |
| `day`     | `2001-08-22 00:00:00.000` | `2001-08-22 00:00:00.000` |
| `week`    | `2001-08-20 00:00:00.000` | `2001-08-20 00:00:00.000` |
| `month`   | `2001-08-01 00:00:00.000` | `2001-08-01 00:00:00.000` |
| `quarter` | `2001-07-01 00:00:00.000` | `2001-07-01 00:00:00.000` |
| `year`    | `2001-01-01 00:00:00.000` | `2001-01-01 00:00:00.000` |

The above examples use the timestamp `2001-08-22 03:04:05.321` as the
input.

#### date\_trunc()

**`date_trunc(unit, x)`** → \[same as input]

Returns `x` truncated to `unit`:

```sql theme={null}
    SELECT date_trunc('day' , TIMESTAMP '2022-10-20 05:10:00');
    -- 2022-10-20 00:00:00.000

    SELECT date_trunc('month' , TIMESTAMP '2022-10-20 05:10:00');
    -- 2022-10-01 00:00:00.000

    SELECT date_trunc('year', TIMESTAMP '2022-10-20 05:10:00');
    -- 2022-01-01 00:00:00.000
```

### Interval functions

The functions in this section support the following interval units:

| Unit          | Description        |
| ------------- | ------------------ |
| `millisecond` | Milliseconds       |
| `second`      | Seconds            |
| `minute`      | Minutes            |
| `hour`        | Hours              |
| `day`         | Days               |
| `week`        | Weeks              |
| `month`       | Months             |
| `quarter`     | Quarters of a year |
| `year`        | Years              |

#### date\_add()

**`date_add(unit, value, timestamp)`** → same as input

Adds an interval `value` of type `unit` to `timestamp`. Subtraction can
be performed by using a negative value:

```sql theme={null}
    SELECT date_add('second', 86, TIMESTAMP '2020-03-01 00:00:00');
    -- 2020-03-01 00:01:26.000

    SELECT date_add('hour', 9, TIMESTAMP '2020-03-01 00:00:00');
    -- 2020-03-01 09:00:00.000

    SELECT date_add('day', -1, TIMESTAMP '2020-03-01 00:00:00 UTC');
    -- 2020-02-29 00:00:00.000 UTC
```

#### date\_diff()

**`date_diff(unit, timestamp1, timestamp2)`** → bigint

Returns `timestamp2 - timestamp1` expressed in terms of `unit`:

```sql theme={null}
    SELECT date_diff('second', TIMESTAMP '2020-03-01 00:00:00', TIMESTAMP '2020-03-02 00:00:00');
    -- 86400

    SELECT date_diff('hour', TIMESTAMP '2020-03-01 00:00:00 UTC', TIMESTAMP '2020-03-02 00:00:00 UTC');
    -- 24

    SELECT date_diff('day', DATE '2020-03-01', DATE '2020-03-02');
    -- 1

    SELECT date_diff('second', TIMESTAMP '2020-06-01 12:30:45.000000000', TIMESTAMP '2020-06-02 12:30:45.123456789');
    -- 86400

    SELECT date_diff('millisecond', TIMESTAMP '2020-06-01 12:30:45.000000000', TIMESTAMP '2020-06-02 12:30:45.123456789');
    -- 86400123
```

### Duration function

The `parse_duration` function supports the following units:

| Unit | Description  |
| ---- | ------------ |
| `ns` | Nanoseconds  |
| `us` | Microseconds |
| `ms` | Milliseconds |
| `s`  | Seconds      |
| `m`  | Minutes      |
| `h`  | Hours        |
| `d`  | Days         |

#### parse\_duration()

**`parse_duration(string)`** → interval

Parses `string` of format `value unit` into an interval, where `value`
is fractional number of `unit` values:

```sql theme={null}
    SELECT parse_duration('42.8ms');
    -- 0 00:00:00.043

    SELECT parse_duration('3.81 d');
    -- 3 19:26:24.000

    SELECT parse_duration('5m');
    -- 0 00:05:00.000
```

#### human\_readable\_seconds()

**`human_readable_seconds(double)`** → varchar

Formats the double value of `seconds` into a human readable string
containing `weeks`, `days`, `hours`, `minutes`, and `seconds`:

```sql theme={null}
    SELECT human_readable_seconds(96);
    -- 1 minute, 36 seconds

    SELECT human_readable_seconds(3762);
    -- 1 hour, 2 minutes, 42 seconds

    SELECT human_readable_seconds(56363463);
    -- 93 weeks, 1 day, 8 hours, 31 minutes, 3 seconds
```

### MySQL date functions

The functions in this section use a format string that is compatible
with the MySQL `date_parse` and `str_to_date` functions. The following
table, based on the MySQL manual, describes the format specifiers:

| Specifier | Description                                                                                                        |
| --------- | ------------------------------------------------------------------------------------------------------------------ |
| `%a`      | Abbreviated weekday name (`Sun` .. `Sat`)                                                                          |
| `%b`      | Abbreviated month name (`Jan` .. `Dec`)                                                                            |
| `%c`      | Month, numeric (`1` .. `12`)[^1]                                                                                   |
| `%D`      | Day of the month with English suffix (`0th`, `1st`, `2nd`, `3rd`, ...)                                             |
| `%d`      | Day of the month, numeric (`01` .. `31`)[^2]                                                                       |
| `%e`      | Day of the month, numeric (`1` .. `31`)[^3]                                                                        |
| `%f`      | Fraction of second (6 digits for printing: `000000` .. `999000`; 1 - 9 digits for parsing: `0` .. `999999999`)[^4] |
| `%H`      | Hour (`00` .. `23`)                                                                                                |
| `%h`      | Hour (`01` .. `12`)                                                                                                |
| `%I`      | Hour (`01` .. `12`)                                                                                                |
| `%i`      | Minutes, numeric (`00` .. `59`)                                                                                    |
| `%j`      | Day of year (`001` .. `366`)                                                                                       |
| `%k`      | Hour (`0` .. `23`)                                                                                                 |
| `%l`      | Hour (`1` .. `12`)                                                                                                 |
| `%M`      | Month name (`January` .. `December`)                                                                               |
| `%m`      | Month, numeric (`01` .. `12`)[^5]                                                                                  |
| `%p`      | `AM` or `PM`                                                                                                       |
| `%r`      | Time of day, 12-hour (equivalent to `%h:%i:%s %p`)                                                                 |
| `%S`      | Seconds (`00` .. `59`)                                                                                             |
| `%s`      | Seconds (`00` .. `59`)                                                                                             |
| `%T`      | Time of day, 24-hour (equivalent to `%H:%i:%s`)                                                                    |
| `%U`      | Week (`00` .. `53`), where Sunday is the first day of the week                                                     |
| `%u`      | Week (`00` .. `53`), where Monday is the first day of the week                                                     |
| `%V`      | Week (`01` .. `53`), where Sunday is the first day of the week; used with `%X`                                     |
| `%v`      | Week (`01` .. `53`), where Monday is the first day of the week; used with `%x`                                     |
| `%W`      | Weekday name (`Sunday` .. `Saturday`)                                                                              |
| `%w`      | Day of the week (`0` .. `6`), where Sunday is the first day of the week[^6]                                        |
| `%X`      | Year for the week where Sunday is the first day of the week, numeric, four digits; used with `%V`                  |
| `%x`      | Year for the week, where Monday is the first day of the week, numeric, four digits; used with `%v`                 |
| `%Y`      | Year, numeric, four digits                                                                                         |
| `%y`      | Year, numeric (two digits)[^7]                                                                                     |
| `%%`      | A literal `%` character                                                                                            |
| `%x`      | `x`, for any `x` not                                                                                               |

The following specifiers are not currently supported:
`%D %U %u %V %w %X`

**`date_format(timestamp, format)`** → varchar

Formats `timestamp` as a string using `format`:

```sql theme={null}
    SELECT date_format(TIMESTAMP '2022-10-20 05:10:00', '%m-%d-%Y %H');
    -- 10-20-2022 05
```

**`date_parse(string, format)`** → timestamp

Parses `string` into a timestamp using `format`:

```sql theme={null}
    SELECT date_parse('2022/10/20/05', '%Y/%m/%d/%H');
    -- 2022-10-20 05:00:00.000
```

### Java date functions

The functions in this section use a format string that is compatible
with JodaTime's
[DateTimeFormat](http://joda-time.sourceforge.net/apidocs/org/joda/time/format/DateTimeFormat.html)
pattern format.

#### format\_datetime()

**`format_datetime(timestamp, format)`** → varchar

Formats `timestamp` as a string using `format`.

#### parse\_datetime()

**`parse_datetime(string, format)`** → timestamp

Parses `string` into a timestamp with time zone using `format`.

### Extraction function

The `extract` function supports the following fields:

| Field             | Description       |
| ----------------- | ----------------- |
| `YEAR`            | `year`            |
| `QUARTER`         | `quarter`         |
| `MONTH`           | `month`           |
| `WEEK`            | `week`            |
| `DAY`             | `day`             |
| `DAY_OF_MONTH`    | `day`             |
| `DAY_OF_WEEK`     | `day_of_week`     |
| `DOW`             | `day_of_week`     |
| `DAY_OF_YEAR`     | `day_of_year`     |
| `DOY`             | `day_of_year`     |
| `YEAR_OF_WEEK`    | `year_of_week`    |
| `YOW`             | `year_of_week`    |
| `HOUR`            | `hour`            |
| `MINUTE`          | `minute`          |
| `SECOND`          | `second`          |
| `TIMEZONE_HOUR`   | `timezone_hour`   |
| `TIMEZONE_MINUTE` | `timezone_minute` |

The types supported by the `extract` function vary depending on the
field to be extracted. Most fields support all date and time types.

**`extract(field FROM x)`** → bigint

Returns `field` from `x`:

```sql theme={null}
    SELECT extract(YEAR FROM TIMESTAMP '2022-10-20 05:10:00');
    -- 2022
```

<tip> This SQL-standard function uses special syntax for specifying the arguments.  </tip>

### Convenience extraction functions

#### day()

**`day(x)`** → bigint

Returns the day of the month from `x`.

#### day\_of\_month()

**`day_of_month(x)`** → bigint

This is an alias for `day`.

#### day\_of\_week()

**`day_of_week(x)`** → bigint

Returns the ISO day of the week from `x`. The value ranges from `1` (Monday) to `7` (Sunday).

#### day\_of\_year()

**`day_of_year(x)`** → bigint

Returns the day of the year from `x`. The value ranges from `1` to `366`.

#### dow()

**`dow(x)`** → bigint

This is an alias for `day_of_week`.

#### doy()

**`doy(x)`** → bigint

This is an alias for `day_of_year`.

#### hour()

**`hour(x)`** → bigint

Returns the hour of the day from `x`. The value ranges from `0` to `23`.

#### millisecond()

**`millisecond(x)`** → bigint

Returns the millisecond of the second from `x`.

#### minute()

**`minute(x)`** → bigint

Returns the minute of the hour from `x`.

#### month()

**`month(x)`** → bigint

Returns the month of the year from `x`.

#### quarter()

**`quarter(x)`** → bigint

Returns the quarter of the year from `x`. The value ranges from `1` to `4`.

#### second()

**`second(x)`** → bigint

Returns the second of the minute from `x`.

#### timezone\_hour()

**`timezone_hour(timestamp)`** → bigint

Returns the hour of the time zone offset from `timestamp`.

#### timezone\_minute()

**`timezone_minute(timestamp)`** → bigint

Returns the minute of the time zone offset from `timestamp`.

#### week()

**`week(x)`** → bigint

Returns the [ISO week]() of the year from `x`. The value ranges from `1` to `53`.

#### week\_of\_year()

**`week_of_year(x)`** → bigint

This is an alias for `week`.

#### year()

**`year(x)`** → bigint

Returns the year from `x`.

#### year\_of\_week()

**`year_of_week(x)`** → bigint

Returns the year of the [ISO week]() from `x`.

#### yow()

**`yow(x)`** → bigint

This is an alias for `year_of_week`.

[^1]: This specifier does not support `0` as a month or day.

[^2]: This specifier does not support `0` as a month or day.

[^3]: This specifier does not support `0` as a month or day.

[^4]: Timestamp is truncated to milliseconds.

[^5]: This specifier does not support `0` as a month or day.

[^6]: This specifier is not supported yet. Consider using `day_of_week` (it uses `1-7` instead of `0-6`).

[^7]: When parsing, two-digit year format assumes range `1970` .. `2069`, so "70" will result in year `1970` but "69" will produce `2069`.


# Decimal functions and operators
Source: https://docs.dune.com/query-engine/Functions-and-operators/decimal



<h3>
  Decimal literals \\
</h3>

Use the `DECIMAL 'xxxxxxx.yyyyyyy'` syntax to define a decimal literal.

The precision of a decimal type for a literal will be equal to the
number of digits in the literal (including trailing and leading zeros).
The scale will be equal to the number of digits in the fractional part
(including trailing zeros).

| Example literal                   | Data type         |
| --------------------------------- | ----------------- |
| `DECIMAL '0'`                     | `DECIMAL(1)`      |
| `DECIMAL '12345'`                 | `DECIMAL(5)`      |
| `DECIMAL '0000012345.1234500000'` | `DECIMAL(20, 10)` |

### Binary arithmetic decimal operators

Standard mathematical operators are supported. The table below explains
precision and scale calculation rules for result. Assuming `x` is of
type `DECIMAL(xp, xs)` and `y` is of type `DECIMAL(yp, ys)`.

| Operation          | Result type precision                            | Result type scale |
| ------------------ | ------------------------------------------------ | ----------------- |
| `x + y` and `x -y` | `min(38,1 +max(xs, ys) + max(xp - xs, yp - ys))` | `max(xs, ys)`     |
| `x * y`            | `min(38, xp + yp)`                               | `xs + ys`         |
| `x / y`            | `min(38, xp + ys + max(0, ys-xs))`               | `max(xs, ys)`     |
| `x % y`            | `min(xp - xs, yp - ys) + max(xs, bs)`            | `max(xs, ys)`     |

If the mathematical result of the operation is not exactly representable
with the precision and scale of the result data type, then an exception
condition is raised: `Value is out of range`.

When operating on decimal types with different scale and precision, the
values are first coerced to a common super type. For types near the
largest representable precision (38), this can result in "Value is out of
range" errors when one of the operands doesn't fit in the common super
type. For example, the common super type of decimal(38, 0) and
decimal(38, 1) is decimal(38, 1), but certain values that fit in
decimal(38, 0) cannot be represented as a decimal(38, 1).

### Comparison operators

All standard `comparison` work for the
decimal type.

### Unary decimal operators

The `-` operator performs negation. The type of result is same as type
of argument.


# EIP-8021 calldata table function
Source: https://docs.dune.com/query-engine/Functions-and-operators/eip-8021

Parse EIP-8021 builder codes from calldata with the `functions.base_l2.call_data_8021` table function.

# EIP-8021 calldata table function

[EIP-8021](https://eips.ethereum.org/EIPS/eip-8021) defines a standard for embedding builder identification codes at the end of transaction calldata.

Dune exposes this as the table function `functions.base_l2.call_data_8021`. It reads calldata from an input table, keeps the input columns, and adds parsed EIP-8021 fields for rows that contain a valid EIP-8021 suffix.

Rows without the EIP-8021 suffix are omitted from the result.

## Syntax

```sql theme={null}
SELECT *
FROM TABLE(functions.base_l2.call_data_8021(
  input => TABLE(<query>),
  calldata => DESCRIPTOR(<calldata_column>)
))
```

## Arguments

* `input`: The input table or subquery that contains a calldata column.
* `calldata`: Optional descriptor pointing to the calldata column in `input`.
  If omitted, the function looks for a column named `calldata`.

The referenced calldata column must be `varchar`.

## Output columns

The table function passes through the original input columns and adds:

| Column                    | Type             | Description                                                                                                             |
| ------------------------- | ---------------- | ----------------------------------------------------------------------------------------------------------------------- |
| `original_tx_data`        | `varchar`        | Original calldata without the EIP-8021 suffix                                                                           |
| `schema_type`             | `varchar`        | Parsed schema label: `Schema 0: Canonical Registry`, `Schema 1: Custom Registry`, `Schema 2: CBOR`, or `Unknown Schema` |
| `codes_hex`               | `varchar`        | Builder codes as hex                                                                                                    |
| `custom_registry_address` | `varchar`        | Custom registry address for schema 1, otherwise `NULL`                                                                  |
| `codes_readable`          | `varchar`        | UTF-8 decoded builder codes                                                                                             |
| `codes_array`             | `array(varchar)` | Builder codes split into an array                                                                                       |
| `cbor_data`               | `varchar`        | JSON representation of schema 2 CBOR payloads                                                                           |
| `erc_8021_suffix`         | `varchar`        | The EIP-8021 magic bytes suffix                                                                                         |

## Examples

### Parse transaction calldata from `base.transactions`

```sql theme={null}
SELECT
  tx_hash,
  block_time,
  schema_type,
  codes_readable,
  codes_array
FROM TABLE(functions.base_l2.call_data_8021(
  input => TABLE(
    SELECT
      hash AS tx_hash,
      block_time,
      cast(data as varchar) AS calldata
    FROM base.transactions
    WHERE block_time >= now() - interval '7' day
  )
))
LIMIT 100
```

### Use the default `calldata` column name

```sql theme={null}
SELECT
  tx_hash,
  schema_type,
  codes_readable
FROM TABLE(functions.base_l2.call_data_8021(
  input => TABLE(
    VALUES
      (
        '0xdeadbeef',
        '0x722c6182000000000000000000000000000000000000000000000000000000000000000163625f77616c6c6574090080218021802180218021802180218021'
      )
  ) AS t(tx_hash, calldata)
))
```

### Override the calldata column name

```sql theme={null}
SELECT
  tx_hash,
  schema_type,
  codes_readable
FROM TABLE(functions.base_l2.call_data_8021(
  input => TABLE(
    VALUES
      (
        '0xdeadbeef',
        '0x722c6182000000000000000000000000000000000000000000000000000000000000000163625f77616c6c6574090080218021802180218021802180218021'
      )
  ) AS t(tx_hash, call_data),
  calldata => DESCRIPTOR(call_data)
))
```

### Parse schema 2 CBOR calldata

```sql theme={null}
SELECT
  schema_type,
  codes_readable,
  codes_array,
  cbor_data
FROM TABLE(functions.base_l2.call_data_8021(
  input => TABLE(
    VALUES
      (
        '0xabcda26161656d796170706177686d7977616c6c657400140280218021802180218021802180218021'
      )
  ) AS t(calldata)
))
```

### Filter for a specific builder code

```sql theme={null}
SELECT
  tx_hash,
  block_time,
  codes_readable
FROM TABLE(functions.base_l2.call_data_8021(
  input => TABLE(
    SELECT
      hash AS tx_hash,
      block_time,
      cast(data as varchar) AS calldata
    FROM base.transactions
    WHERE block_time >= now() - interval '7' day
  )
))
WHERE contains(codes_array, 'cb_wallet')
LIMIT 100
```

## Supported schema types

* **Schema 0: Canonical Registry**: Builder codes plus the EIP-8021 suffix
* **Schema 1: Custom Registry**: Builder codes plus a custom registry address
* **Schema 2: CBOR**: CBOR-encoded builder metadata exposed through both `codes_*` fields and `cbor_data`

## EIP-8021 suffix structure

Schema 0 and schema 1 are parsed from the end of calldata in this order:

| Component        | Size     | Description                                |
| ---------------- | -------- | ------------------------------------------ |
| Builder codes    | Variable | UTF-8 encoded builder identification codes |
| Registry address | 20 bytes | Only present for schema 1                  |
| Codes length     | 1 byte   | Length of the builder code payload         |
| Schema ID        | 1 byte   | `0x00` or `0x01`                           |
| Magic bytes      | 16 bytes | `0x80218021802180218021802180218021`       |

Schema 2 uses:

| Component    | Size     | Description                          |
| ------------ | -------- | ------------------------------------ |
| CBOR payload | Variable | CBOR map containing builder metadata |
| CBOR length  | 2 bytes  | Length of the CBOR payload           |
| Schema ID    | 1 byte   | `0x02`                               |
| Magic bytes  | 16 bytes | `0x80218021802180218021802180218021` |

## Use Cases

* **Builder attribution**: Track which wallet or tool produced a transaction
* **Wallet analytics**: Measure adoption of builder codes across applications
* **ERC-4337 analysis**: Parse builder metadata from UserOperation calldata
* **Schema research**: Compare canonical registry, custom registry, and CBOR-based usage

## Notes

* The function currently expects calldata as `varchar`, not `varbinary`
* If your source column is `varbinary` (for example `base.transactions.data`), cast it to `varchar` before passing it into the table function
* Input rows without the EIP-8021 magic bytes are filtered out of the result
* Builder codes are typically comma-separated identifiers such as `cb_wallet`


# EVM Decoding Functions
Source: https://docs.dune.com/query-engine/Functions-and-operators/evm-decoding-functions

Functions to decode raw EVM events and function calls in DuneSQL.

EVM decoding functions let you decode raw event logs and function call traces inline in DuneSQL using a contract's ABI. This is useful when you need to decode contracts that have not been submitted through Dune's [contract decoding pipeline](/web-app/decoding/decoding-contracts), or when you want to decode data ad hoc without waiting for a submission to be processed.

<CardGroup>
  <Card title="Example Dashboard" icon="chart-simple" href="https://dune.com/dune/evm-decoding-functions">
    Live examples of both functions applied to real contract data.
  </Card>
</CardGroup>

## Before You Start

### Finding a Contract's ABI

These functions require the ABI for a **single event or function**, not the entire contract ABI.

To find the ABI for a specific event or function:

1. Go to the contract's page on [Etherscan](https://etherscan.io) (or the relevant chain's block explorer).
2. Navigate to **Contract > Code > Contract ABI**.
3. Locate the JSON object for the specific event or function you want to decode.
4. Copy that single JSON object, not the full array.

<Warning>
  Pass only the ABI for the specific event or function, not the entire contract ABI. Each `decode_evm_event()` or `decode_evm_function_call()` invocation expects a single ABI entry.
</Warning>

For more details on what an ABI is, see [this guide](https://www.quicknode.com/guides/ethereum-development/smart-contracts/what-is-an-abi).

### Finding the topic0 for an Event

`topic0` is the keccak256 hash of the event signature (name and parameter types). Use it to filter `logs` tables for specific events.

To find a `topic0`:

1. Open an [example transaction](https://basescan.org/tx/0x446c2c7c605cde83d6aba87921fceec40b111b97166ddbee513424eefae31ba5#eventlog) on a block explorer.
2. Go to the **Logs** tab.
3. Identify the event and copy the value in the **topic0** field.

<Frame>
  <img />
</Frame>

### Finding the MethodId for a Function Call

The MethodId is the first 4 bytes of the keccak256 hash of the function signature. Use it with `starts_with(input, <MethodId>)` to filter `traces` tables for specific function calls.

To find a MethodId:

1. Open an [example transaction](https://basescan.org/tx/0x446c2c7c605cde83d6aba87921fceec40b111b97166ddbee513424eefae31ba5) on a block explorer.
2. In the **Overview** tab, click **Click to show more**.
3. Copy the **MethodId** from the Input Data field.

<Frame>
  <img />
</Frame>

## Function Reference

### decode\_evm\_event()

**`decode_evm_event(abi, input [, topics [, data [, null_on_error]]])`**

Decodes EVM events according to the provided ABI. Returns each decoded parameter as a separate column.

#### Arguments

| Argument        | Required | Type       | Default                                      | Description                                                                                                              |
| --------------- | -------- | ---------- | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| `abi`           | Yes      | varchar    |                                              | Event specification in JSON format. Must be constant at analysis time. Each input in the ABI produces one output column. |
| `input`         | Yes      | table      |                                              | Table or subquery providing `topics` and `data` columns. Must be preceded with the `TABLE` keyword.                      |
| `topics`        | No       | descriptor | `DESCRIPTOR(topic0, topic1, topic2, topic3)` | Specifies which columns contain the event topics. Null topics are ignored.                                               |
| `data`          | No       | descriptor | `DESCRIPTOR(data)`                           | Specifies which column contains the event data.                                                                          |
| `null_on_error` | No       | boolean    | `true`                                       | When `true`, decoding errors produce null values. When `false`, errors are raised.                                       |

#### Output

One column per parameter defined in the ABI inputs. Column names match the ABI parameter names, or default to `_arg0`, `_arg1`, etc. Columns are ordered with `indexed` inputs first.

<Note>
  All columns from the input table are passed through. The returned table contains one column for each ABI argument, followed by all columns from the input table.
</Note>

#### Examples

* [Basic Usage](https://dune.com/queries/3851471)

```sql theme={null}
SELECT * 
FROM TABLE (
    decode_evm_event (
      abi => '{"anonymous":false,"inputs":[{"indexed":true,"internalType":"address","name":"buyer","type":"address"},{"indexed":true,"internalType":"address","name":"recipient","type":"address"},{"indexed":false,"internalType":"uint256[]","name":"tokensSoldIds","type":"uint256[]"},{"indexed":false,"internalType":"uint256[]","name":"tokensSoldAmounts","type":"uint256[]"},{"indexed":false,"internalType":"uint256[]","name":"currencyBoughtAmounts","type":"uint256[]"},{"indexed":false,"internalType":"address[]","name":"extraFeeRecipients","type":"address[]"},{"indexed":false,"internalType":"uint256[]","name":"extraFeeAmounts","type":"uint256[]"}],"name":"CurrencyPurchase","type":"event"}',
      input => TABLE (
        SELECT * 
        FROM polygon.logs
        WHERE topic0 = 0xb57378559821141c0e7ae964206b7523234d19e5783ade99b3d665eee495c997
        LIMIT 20
      )
    )
  )
```

* [Using Custom Topics and Data Columns](https://dune.com/queries/3861622)

```sql theme={null}
SELECT * 
FROM TABLE (
    decode_evm_event (
      abi => '{"anonymous":false,"inputs":[{"indexed":true,"internalType":"address","name":"buyer","type":"address"},{"indexed":true,"internalType":"address","name":"recipient","type":"address"},{"indexed":false,"internalType":"uint256[]","name":"tokensSoldIds","type":"uint256[]"},{"indexed":false,"internalType":"uint256[]","name":"tokensSoldAmounts","type":"uint256[]"},{"indexed":false,"internalType":"uint256[]","name":"currencyBoughtAmounts","type":"uint256[]"},{"indexed":false,"internalType":"address[]","name":"extraFeeRecipients","type":"address[]"},{"indexed":false,"internalType":"uint256[]","name":"extraFeeAmounts","type":"uint256[]"}],"name":"CurrencyPurchase","type":"event"}',
      input => TABLE (
        SELECT topic0 as my_topic_0, topic1 as my_topic_1, topic2 as my_last_topic, data as my_data_column, * 
        FROM polygon.logs
        WHERE topic0 = 0xb57378559821141c0e7ae964206b7523234d19e5783ade99b3d665eee495c997
        LIMIT 20
      ),
      topics => DESCRIPTOR(my_topic_0, my_topic_1, my_last_topic),
      data => DESCRIPTOR(my_data_column),
      null_on_error => false
    )
  )
```

### decode\_evm\_function\_call()

**`decode_evm_function_call(abi, data [, input [, output [, null_on_error]]])`**

Decodes EVM function calls according to the provided ABI. Returns each decoded input and output parameter as separate columns.

#### Arguments

| Argument        | Required | Type       | Default              | Description                                                                                                                                 |
| --------------- | -------- | ---------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| `abi`           | Yes      | varchar    |                      | Function call specification in JSON format. Must be constant at analysis time. Each input and output in the ABI produces one output column. |
| `data`          | Yes      | table      |                      | Table or subquery providing `input` and `output` columns. Must be preceded with the `TABLE` keyword.                                        |
| `input`         | No       | descriptor | `DESCRIPTOR(input)`  | Specifies which column contains the function call input bytes.                                                                              |
| `output`        | No       | descriptor | `DESCRIPTOR(output)` | Specifies which column contains the function call output bytes.                                                                             |
| `null_on_error` | No       | boolean    | `true`               | When `true`, decoding errors produce null values. When `false`, errors are raised.                                                          |

#### Output

One column per input and output defined in the ABI. Column names match the ABI parameter names, or default to `_input0`, `_input1`, `_output0`, `_output1`, etc. If two arguments share the same name, the last declared argument takes precedence.

<Note>
  All columns from the data table are passed through. The returned table contains one column for each ABI argument, followed by all columns from the data table.
</Note>

#### Examples

* [Basic Usage](https://dune.com/queries/4001654)

```sql theme={null}
SELECT * 
FROM TABLE (
    decode_evm_function_call (
      abi => '{"name":"getPlanet","type":"function","inputs":[{"name":"planetId","type":"uint256"}],"outputs":[{"name":"planetName","type":"string"},{"name":"planetType","type":"string"}]}',
      data => TABLE (
        SELECT * 
        FROM polygon.traces
        WHERE starts_with(input, 0x34efcb8e)
        LIMIT 20
      )
    )
  )
```


# HyperLogLog functions
Source: https://docs.dune.com/query-engine/Functions-and-operators/hyperloglog



Trino implements the [`approx_distinct`](/query-engine/Functions-and-operators/aggregate#approximate-aggregate-functions) function using the [HyperLogLog](https://en.wikipedia.org/wiki/HyperLogLog) data structure.

### Data structures

Trino implements HyperLogLog data sketches as a set of 32-bit buckets
which store a *maximum hash*. They can be stored sparsely (as a map from
bucket ID to bucket), or densely (as a contiguous memory block). The
HyperLogLog data structure starts as the sparse representation,
switching to dense when it is more efficient. The P4HyperLogLog
structure is initialized densely and remains dense for its lifetime.

`hyperloglog_type` implicitly casts to
`p4hyperloglog_type`, while one can
explicitly cast `HyperLogLog` to `P4HyperLogLog`:

```text theme={null}
    cast(hll AS P4HyperLogLog)
```

### Serialization

Data sketches can be serialized to and deserialized from `varbinary`.
This allows them to be stored for later use. Combined with the ability
to merge multiple sketches, this allows one to calculate
`approx_distinct` of the elements of a partition of a query, then for the entirety of a query with very little
cost.

For example, calculating the `HyperLogLog` for daily unique users will
allow weekly or monthly unique users to be calculated incrementally by
combining the dailies. This is similar to computing weekly revenue by
summing daily revenue. Uses of `approx_distinct` with `GROUPING SETS` can be converted to use `HyperLogLog`.\
Examples:

```sql theme={null}
  CREATE TABLE visit_summaries (  
    visit_date date,
    hll varbinary
  )
  INSERT INTO visit_summaries
  SELECT visit_date, cast(approx_set(user_id) AS varbinary)
  FROM user_visits
  GROUP BY visit_date;

  SELECT cardinality(merge(cast(hll AS HyperLogLog))) AS weekly_unique_users
  FROM visit_summaries
  WHERE visit_date >= current_date - interval '7' day;
```

### Functions

#### approx\_set()

**`approx_set(x)`** → HyperLogLog

Returns the `HyperLogLog` sketch of the input data set of `x`. This data
sketch underlies `approx_distinct` and can be stored and used later by calling `cardinality()`.

#### cardinality()

**`cardinality(hll)`** → bigint

This will perform `approx_distinct` on
the data summarized by the `hll` HyperLogLog data sketch.

#### empty\_hll()

**`empty_hll()`** → HyperLogLog

Returns an empty `HyperLogLog`.

#### merge()

**`merge(hyperloglog)`** → HyperLogLog
Returns the `HyperLogLog` of the aggregate union of the individual `hll`
HyperLogLog structures.


# Overview
Source: https://docs.dune.com/query-engine/Functions-and-operators/index

DuneSQL supports a wide range of built-in functions and operators.

This chapter describes the built-in SQL functions and operators supported by Trino. They allow you to implement complex functionality and behavior of the SQL executed by Trino operating on the underlying data sources.

Table procedures such as Datashare syncs are documented under [Supported SQL Operations](/api-reference/connectors/sql-operations), not in this functions reference.

Using `SHOW FUNCTIONS` in the query editor returns a list of all available functions, including custom functions, with all supported arguments and a short description.

### DuneSQL Added Functions and Operators:

* [Varbinary datatypes for EVM data](/query-engine/Functions-and-operators/varbinary)
* [EIP-8021 calldata table function](/query-engine/Functions-and-operators/eip-8021)
* [Base58 for Bitcoin\&Solana data](/query-engine/Functions-and-operators/base58)
* [ss58 for Substrate data](/query-engine/Functions-and-operators/ss58)
* [Tron Address Functions](/query-engine/Functions-and-operators/tronaddress)
* [Chain Utility Functions](/query-engine/Functions-and-operators/chain-utility-functions)
* [Varchar Utility Functions](/query-engine/Functions-and-operators/varchar-utility-functions)
* [LiveFetch Functions](/query-engine/Functions-and-operators/live-fetch)
* [ASOF Join](/query-engine/Functions-and-operators/asof-join)

### Trino Base Functions:

* [Aggregate](/query-engine/Functions-and-operators/aggregate)
* [Array](/query-engine/Functions-and-operators/array)
* [Binary](/query-engine/Functions-and-operators/binary)
* [Bitwise](/query-engine/Functions-and-operators/bitwise)
* [Comparison](/query-engine/Functions-and-operators/comparison)
* [Conditional](/query-engine/Functions-and-operators/conditional)
* [Conversion](/query-engine/Functions-and-operators/conversion)
* [Date and time](/query-engine/Functions-and-operators/datetime)
* [Decimal](/query-engine/Functions-and-operators/decimal)
* [HyperLogLog](/query-engine/Functions-and-operators/hyperloglog)
* [JSON](/query-engine/Functions-and-operators/json)
* [Lambda](/query-engine/Functions-and-operators/lambda)
* [Logical](/query-engine/Functions-and-operators/logical)
* [Map](/query-engine/Functions-and-operators/map)
* [Math](/query-engine/Functions-and-operators/math)
* [Quantile digest](/query-engine/Functions-and-operators/qdigest)
* [Regular expression](/query-engine/Functions-and-operators/regexp)
* [Set Digest](/query-engine/Functions-and-operators/setdigest)
* [String](/query-engine/Functions-and-operators/string)
* [System](/query-engine/Functions-and-operators/system)
* [Teradata](/query-engine/Functions-and-operators/teradata)
* [T-Digest](/query-engine/Functions-and-operators/tdigest)
* [URL](/query-engine/Functions-and-operators/url)
* [UUID](/query-engine/Functions-and-operators/uuid)
* [Window](/query-engine/Functions-and-operators/window)


# JSON functions
Source: https://docs.dune.com/query-engine/Functions-and-operators/json



# JSON functions and operators

The SQL standard describes functions and operators to process JSON data. They
allow you to access JSON data according to its structure, generate JSON data,
and store it persistently in SQL tables.

Importantly, the SQL standard imposes that there is no dedicated data type to
represent JSON data in SQL. Instead, JSON data is represented as character or
binary strings. Although Trino supports `JSON` type, it is not used or
produced by the following functions.

Trino supports three functions for querying JSON data:
`json_exists<json-exists>`,
`json_query<json-query>`, and `json_value<json-value>`. Each of them
is based on the same mechanism of exploring and processing JSON input using
JSON path.

Trino also supports two functions for generating JSON data --
`json_array<json-array>`, and `json_object<json-object>`.

## JSON path language

The JSON path language is a special language, used exclusively by certain SQL
operators to specify the query to perform on the JSON input. Although JSON path
expressions are embedded in SQL queries, their syntax significantly differs
from SQL. The semantics of predicates, operators, etc. in JSON path expressions
generally follow the semantics of SQL. The JSON path language is case-sensitive
for keywords and identifiers.

### JSON path syntax and semantics

JSON path expressions are recursive structures. Although the name "path"
suggests a linear sequence of operations going step by step deeper into the JSON
structure, a JSON path expression is a tree. It can access the input
JSON item multiple times, in multiple ways, and combine the results. Moreover,
the result of a JSON path expression is not a single item, but an ordered
sequence of items. Each of the sub-expressions takes one or more input
sequences and returns a sequence as the result.

<Note>
  In the lax mode, most path operations first unnest all JSON arrays in the
  input sequence. Any divergence from this rule is mentioned in the following
  listing. Path modes are explained in `json-path-modes`.
</Note>

The JSON path language features are divided into: literals, variables,
arithmetic binary expressions, arithmetic unary expressions, and a group of
operators collectively known as accessors.

### literals

#### numeric literals

They include exact and approximate numbers, and are interpreted as if they
were SQL values.

```text theme={null}
-1, 1.2e3, NaN
```

#### string literals

They are enclosed in double quotes.

```text theme={null}
"Some text"
```

#### boolean literals

```text theme={null}
true, false
```

#### null literal

It has the semantics of the JSON null, not of SQL null. See link`json-comparison-rules`.

```text theme={null}
null
```

### variables

#### context variable

It refers to the currently processed input of the JSON
function.

```text theme={null}
$
```

#### named variable

It refers to a named parameter by its name.

```text theme={null}
$param
```

#### current item variable

It is used inside the filter expression to refer to the currently processed
item from the input sequence.

```text theme={null}
@
```

#### last subscript variable

It refers to the last index of the innermost enclosing array. Array indexes
in JSON path expressions are zero-based.

```text theme={null}
last
```

### arithmetic binary expressions

The JSON path language supports five arithmetic binary operators:

```text theme={null}
<path1> + <path2>
<path1> - <path2>
<path1> * <path2>
<path1> / <path2>
<path1> % <path2>
```

Both operands, `<path1>` and `<path2>`, are evaluated to sequences of
items. For arithmetic binary operators, each input sequence must contain a
single numeric item. The arithmetic operation is performed according to SQL
semantics, and it returns a sequence containing a single element with the
result.

The operators follow the same precedence rules as in SQL arithmetic operations,
and parentheses can be used for grouping.

### arithmetic unary expressions

```text theme={null}
+ <path>
- <path>
```

The operand `<path>` is evaluated to a sequence of items. Every item must be
a numeric value. The unary plus or minus is applied to every item in the
sequence, following SQL semantics, and the results form the returned sequence.

### member accessor

The member accessor returns the value of the member with the specified key for
each JSON object in the input sequence.

```text theme={null}
<path>.key
<path>."key"
```

The condition when a JSON object does not have such a member is called a
structural error. In the lax mode, it is suppressed, and the faulty object is
excluded from the result.

Let `<path>` return a sequence of three JSON objects:

```text theme={null}
{"customer" : 100, "region" : "AFRICA"},
{"region" : "ASIA"},
{"customer" : 300, "region" : "AFRICA", "comment" : null}
```

the expression `<path>.customer` succeeds in the first and the third object,
but the second object lacks the required member. In strict mode, path
evaluation fails. In lax mode, the second object is silently skipped, and the
resulting sequence is `100, 300`.

All items in the input sequence must be JSON objects.

<Note>Trino does not support JSON objects with duplicate keys.</Note>

### wildcard member accessor

Returns values from all key-value pairs for each JSON object in the input
sequence. All the partial results are concatenated into the returned sequence.

```text theme={null}
<path>.*
```

Let `<path>` return a sequence of three JSON objects:

```text theme={null}
{"customer" : 100, "region" : "AFRICA"},
{"region" : "ASIA"},
{"customer" : 300, "region" : "AFRICA", "comment" : null}
```

The results is:

```text theme={null}
100, "AFRICA", "ASIA", 300, "AFRICA", null
```

All items in the input sequence must be JSON objects.

The order of values returned from a single JSON object is arbitrary. The
sub-sequences from all JSON objects are concatenated in the same order in which
the JSON objects appear in the input sequence.

### descendant member accessor

Returns the values associated with the specified key in all JSON objects on all
levels of nesting in the input sequence.

```text theme={null}
<path>..key
<path>.."key"
```

The order of returned values is that of preorder depth first search. First, the
enclosing object is visited, and then all child nodes are visited.

This method does not perform array unwrapping in the lax mode. The results
are the same in the lax and strict modes. The method traverses into JSON
arrays and JSON objects. Non-structural JSON items are skipped.

Let `<path>` be a sequence containing a JSON object:

```text theme={null}
{
    "id" : 1,
    "notes" : [{"type" : 1, "comment" : "foo"}, {"type" : 2, "comment" : null}],
    "comment" : ["bar", "baz"]
}
```

```text theme={null}
<path>..comment --> ["bar", "baz"], "foo", null
```

### array accessor

Returns the elements at the specified indexes for each JSON array in the input
sequence. Indexes are zero-based.

```text theme={null}
<path>[ <subscripts> ]
```

The `<subscripts>` list contains one or more subscripts. Each subscript
specifies a single index or a range (ends inclusive):

```text theme={null}
<path>[<path1>, <path2> to <path3>, <path4>,...]
```

In lax mode, any non-array items resulting from the evaluation of the input
sequence are wrapped into single-element arrays. Note that this is an exception
to the rule of automatic array wrapping.

Each array in the input sequence is processed in the following way:

* The variable `last` is set to the last index of the array.
* All subscript indexes are computed in order of declaration. For a singleton subscript `<path1>`, the result must be a singleton numeric item. For a range subscript `<path2> to <path3>`, two numeric items are expected.
* The specified array elements are added in order to the output sequence.

Let `<path>` return a sequence of three JSON arrays:

```text theme={null}
[0, 1, 2], ["a", "b", "c", "d"], [null, null]
```

The following expression returns a sequence containing the last element from
every array:

```text theme={null}
<path>[last] --> 2, "d", null
```

The following expression returns the third and fourth element from every array:

```text theme={null}
<path>[2 to 3] --> 2, "c", "d"
```

Note that the first array does not have the fourth element, and the last array
does not have the third or fourth element. Accessing non-existent elements is a
structural error. In strict mode, it causes the path expression to fail. In lax
mode, such errors are suppressed, and only the existing elements are returned.

Another example of a structural error is an improper range specification such
as `5 to 3`.

Note that the subscripts may overlap, and they do not need to follow the
element order. The order in the returned sequence follows the subscripts:

```text theme={null}
<path>[1, 0, 0] --> 1, 0, 0, "b", "a", "a", null, null, null
```

### wildcard array accessor

Returns all elements of each JSON array in the input sequence.

```text theme={null}
<path>[*]
```

In lax mode, any non-array items resulting from the evaluation of the input
sequence are wrapped into single-element arrays. Note that this is an exception
to the rule of automatic array wrapping.

The output order follows the order of the original JSON arrays. Also, the order
of elements within the arrays is preserved.

Let `<path>` return a sequence of three JSON arrays:

```text theme={null}
[0, 1, 2], ["a", "b", "c", "d"], [null, null]
<path>[*] --> 0, 1, 2, "a", "b", "c", "d", null, null
```

### filter

Retrieves the items from the input sequence which satisfy the predicate.

```text theme={null}
<path>?( <predicate> )
```

JSON path predicates are syntactically similar to boolean expressions in SQL.
However, the semantics are different in many aspects:

* They operate on sequences of items.
* They have their own error handling (they never fail).
* They behave differently depending on the lax or strict mode.

The predicate evaluates to `true`, `false`, or `unknown`. Note that some
predicate expressions involve nested JSON path expressions. When evaluating the
nested path, the variable `@` refers to the currently examined item from the
input sequence.

The following predicate expressions are supported:

##### Conjunction

```text theme={null}
<predicate1> && <predicate2>
```

##### Disjunction

```text theme={null}
<predicate1> || <predicate2>
```

##### Negation

```text theme={null}
! <predicate>
```

##### `exists` predicate

```text theme={null}
exists( <path> )
```

Returns `true` if the nested path evaluates to a non-empty sequence, and
`false` when the nested path evaluates to an empty sequence. If the path
evaluation throws an error, returns `unknown`.

##### `starts with` predicate

```text theme={null}
<path> starts with "Some text"
<path> starts with $variable
```

The nested `<path>` must evaluate to a sequence of textual items, and the
other operand must evaluate to a single textual item. If evaluating of either
operand throws an error, the result is `unknown`. All items from the sequence
are checked for starting with the right operand. The result is `true` if a
match is found, otherwise `false`. However, if any of the comparisons throws
an error, the result in the strict mode is `unknown`. The result in the lax
mode depends on whether the match or the error was found first.

##### `is unknown` predicate

```text theme={null}
( <predicate> ) is unknown
```

Returns `true` if the nested predicate evaluates to `unknown`, and
`false` otherwise.

#### Comparisons

```text theme={null}
<path1> == <path2>
<path1> <> <path2>
<path1> != <path2>
<path1> < <path2>
<path1> > <path2>
<path1> <= <path2>
<path1> >= <path2>
```

Both operands of a comparison evaluate to sequences of items. If either
evaluation throws an error, the result is `unknown`. Items from the left and
right sequence are then compared pairwise. Similarly to the `starts with`
predicate, the result is `true` if any of the comparisons returns `true`,
otherwise `false`. However, if any of the comparisons throws an error, for
example because the compared types are not compatible, the result in the strict
mode is `unknown`. The result in the lax mode depends on whether the `true`
comparison or the error was found first.

#### Comparison rules

Null values in the context of comparison behave differently than SQL null:

* null == null --> `true`
* null != null, null \< null, ... --> `false`
* null compared to a scalar value --> `false`
* null compared to a JSON array or a JSON object --> `false`

When comparing two scalar values, `true` or `false` is returned if the
comparison is successfully performed. The semantics of the comparison is the
same as in SQL. In case of an error, e.g. comparing text and number,
`unknown` is returned.

Comparing a scalar value with a JSON array or a JSON object, and comparing JSON
arrays/objects is an error, so `unknown` is returned.

##### Examples of filter

Let `<path>` return a sequence of three JSON objects:

```text theme={null}
{"customer" : 100, "region" : "AFRICA"},
{"region" : "ASIA"},
{"customer" : 300, "region" : "AFRICA", "comment" : null}
```

```text theme={null}
<path>?(@.region != "ASIA") --> {"customer" : 100, "region" : "AFRICA"},
                                {"customer" : 300, "region" : "AFRICA", "comment" : null}
<path>?(!exists(@.customer)) --> {"region" : "ASIA"}
```

The following accessors are collectively referred to as **item methods**.

#### double()

Converts numeric or text values into double values.

```text theme={null}
<path>.double()
```

Let `<path>` return a sequence `-1, 23e4, "5.6"`:

```text theme={null}
<path>.double() --> -1e0, 23e4, 5.6e0
```

#### ceiling(), floor(), and abs()

Gets the ceiling, the floor or the absolute value for every numeric item in the
sequence. The semantics of the operations is the same as in SQL.

Let `<path>` return a sequence `-1.5, -1, 1.3`:

```text theme={null}
<path>.ceiling() --> -1.0, -1, 2.0
<path>.floor() --> -2.0, -1, 1.0
<path>.abs() --> 1.5, 1, 1.3
```

#### keyvalue()

Returns a collection of JSON objects including one object per every member of
the original object for every JSON object in the sequence.

```text theme={null}
<path>.keyvalue()
```

The returned objects have three members:

* "name", which is the original key,
* "value", which is the original bound value,
* "id", which is the unique number, specific to an input object.

Let `<path>` be a sequence of three JSON objects:

```text theme={null}
{"customer" : 100, "region" : "AFRICA"},
{"region" : "ASIA"},
{"customer" : 300, "region" : "AFRICA", "comment" : null}
```

```text theme={null}
<path>.keyvalue() --> {"name" : "customer", "value" : 100, "id" : 0},
                      {"name" : "region", "value" : "AFRICA", "id" : 0},
                      {"name" : "region", "value" : "ASIA", "id" : 1},
                      {"name" : "customer", "value" : 300, "id" : 2},
                      {"name" : "region", "value" : "AFRICA", "id" : 2},
                      {"name" : "comment", "value" : null, "id" : 2}
```

It is required that all items in the input sequence are JSON objects.

The order of the returned values follows the order of the original JSON
objects. However, within objects, the order of returned entries is arbitrary.

#### type()

Returns a textual value containing the type name for every item in the
sequence.

```text theme={null}
<path>.type()
```

This method does not perform array unwrapping in the lax mode.

The returned values are:

* `"null"` for JSON null,
* `"number"` for a numeric item,
* `"string"` for a textual item,
* `"boolean"` for a boolean item,
* `"date"` for an item of type date,
* `"time without time zone"` for an item of type time,
* `"time with time zone"` for an item of type time with time zone,
* `"timestamp without time zone"` for an item of type timestamp,
* `"timestamp with time zone"` for an item of type timestamp with time zone,
* `"array"` for JSON array,
* `"object"` for JSON object,

#### size()

Returns a numeric value containing the size for every JSON array in the
sequence.

```text theme={null}
<path>.size()
```

This method does not perform array unwrapping in the lax mode. Instead, all
non-array items are wrapped in singleton JSON arrays, so their size is `1`.

It is required that all items in the input sequence are JSON arrays.

Let `<path>` return a sequence of three JSON arrays:

```text theme={null}
[0, 1, 2], ["a", "b", "c", "d"], [null, null]
<path>.size() --> 3, 4, 2
```

### Limitations

The SQL standard describes the `datetime()` JSON path item method and the
`like_regex()` JSON path predicate. Trino does not support them.

### JSON path modes

The JSON path expression can be evaluated in two modes: strict and lax. In the
strict mode, it is required that the input JSON data strictly fits the schema
required by the path expression. In the lax mode, the input JSON data can
diverge from the expected schema.

The following table shows the differences between the two modes.

| Condition                                                                                                                                                                                                                | Strict Mode | Lax Mode                                                                                                       |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------- | -------------------------------------------------------------------------------------------------------------- |
| Performing an operation which requires a non-array on an array, e.g.: `$.key` requires a JSON object; `$.floor()` requires a numeric value                                                                               | ERROR       | The array is automatically unnested, and the operation is performed on each array element.                     |
| Performing an operation which requires an array on a non-array, e.g.: `$[0]`, `$[*]`, `$.size()`                                                                                                                         | ERROR       | The non-array item is automatically wrapped in a singleton array, and the operation is performed on the array. |
| A structural error: accessing a non-existent element of an array or a non-existent member of a JSON object, e.g.: `$[-1]` (array index out of bounds); `$.key`, where the input JSON object does not have a member `key` | ERROR       | The error is suppressed, and the operation results in an empty sequence.                                       |

#### Examples of the lax mode behavior

Let `<path>` return a sequence of three items, a JSON array, a JSON object,
and a scalar numeric value:

```text theme={null}
[1, "a", null], {"key1" : 1.0, "key2" : true}, -2e3
```

The following example shows the wildcard array accessor in the lax mode. The
JSON array returns all its elements, while the JSON object and the number are
wrapped in singleton arrays and then unnested, so effectively they appear
unchanged in the output sequence:

```text theme={null}
<path>[*] --> 1, "a", null, {"key1" : 1.0, "key2" : true}, -2e3
```

When calling the `size()` method, the JSON object and the number are also
wrapped in singleton arrays:

```text theme={null}
<path>.size() --> 3, 1, 1
```

In some cases, the lax mode cannot prevent failure. In the following example,
even though the JSON array is unwrapped prior to calling the `floor()`
method, the item `"a"` causes type mismatch.

```text theme={null}
<path>.floor() --> ERROR
```

(json-exists)=

### json\_exists

The `json_exists` function determines whether a JSON value satisfies a JSON
path specification.

```text theme={null}
JSON_EXISTS(
    json_input [ FORMAT JSON [ ENCODING { UTF8 | UTF16 | UTF32 } ] ],
    json_path
    [ PASSING json_argument [, ...] ]
    [ { TRUE | FALSE | UNKNOWN | ERROR } ON ERROR ]
    )
```

The `json_path` is evaluated using the `json_input` as the context variable
(`$`), and the passed arguments as the named variables (`$variable_name`).
The returned value is `true` if the path returns a non-empty sequence, and
`false` if the path returns an empty sequence. If an error occurs, the
returned value depends on the `ON ERROR` clause. The default value returned
`ON ERROR` is `FALSE`. The `ON ERROR` clause is applied for the following
kinds of errors:

* Input conversion errors, such as malformed JSON
* JSON path evaluation errors, e.g. division by zero

`json_input` is a character string or a binary string. It should contain
a single JSON item. For a binary string, you can specify encoding.

`json_path` is a string literal, containing the path mode specification, and
the path expression, following the syntax rules described in
link`json-path-syntax-and-semantics`.

```text theme={null}
strict ($.price + $.tax)?(@ > 99.9)
lax $[0 to 1].floor()?(@ > 10)
```

In the `PASSING` clause you can pass arbitrary expressions to be used by the
path expression.

```text theme={null}
PASSING orders.totalprice AS O_PRICE,
        orders.tax % 10 AS O_TAX
```

The passed parameters can be referenced in the path expression by named
variables, prefixed with `$`.

```text theme={null}
lax $?(@.price > $O_PRICE || @.tax > $O_TAX)
```

Additionally to SQL values, you can pass JSON values, specifying the format and
optional encoding:

```text theme={null}
PASSING orders.json_desc FORMAT JSON AS o_desc,
        orders.binary_record FORMAT JSON ENCODING UTF16 AS o_rec
```

Note that the JSON path language is case-sensitive, while the unquoted SQL
identifiers are upper-cased. Therefore, it is recommended to use quoted
identifiers in the `PASSING` clause:

```text theme={null}
lax $.$KeyName PASSING nation.name AS KeyName --> ERROR; no passed value found
lax $.$KeyName PASSING nation.name AS "KeyName" --> correct
```

### Examples

Let `customers` be a table containing two columns: `id:bigint`,
`description:varchar`.

| id  | description                                       |
| --- | ------------------------------------------------- |
| 101 | `{"comment": "nice", "children": [10, 13, 16]}`   |
| 102 | `{"comment": "problematic", "children" :[8, 11]}` |
| 103 | `{"comment": "knows best", "children": [2]}`      |

The following query checks which customers have children above the age of 10:

```sql theme={null}
SELECT
      id,
      json_exists(
                  description,
                  lax $.children[*]?(@ > 10)
                 ) AS children_above_ten
FROM customers
```

| id  | children\_above\_ten |
| --- | -------------------- |
| 101 | true                 |
| 102 | true                 |
| 103 | false                |

In the following query, the path mode is strict. We check the third child for
each customer. This should cause a structural error for the customers who do
not have three or more children. This error is handled according to the `ON
ERROR` clause.

```sql theme={null}
SELECT
      id,
      json_exists(
                  description,
                  strict $.children[2]?(@ > 10)
                  UNKNOWN ON ERROR
                 ) AS child_3_above_ten
FROM customers
```

| id  | child\_3\_above\_ten |
| --- | -------------------- |
| 101 | true                 |
| 102 | NULL                 |
| 103 | NULL                 |

### json\_query

The `json_query` function extracts a JSON value from a JSON value.

```text theme={null}
JSON_QUERY(
    json_input [ FORMAT JSON [ ENCODING { UTF8 | UTF16 | UTF32 } ] ],
    json_path
    [ PASSING json_argument [, ...] ]
    [ RETURNING type [ FORMAT JSON [ ENCODING { UTF8 | UTF16 | UTF32 } ] ] ]
    [ WITHOUT [ ARRAY ] WRAPPER |
      WITH [ { CONDITIONAL | UNCONDITIONAL } ] [ ARRAY ] WRAPPER ]
    [ { KEEP | OMIT } QUOTES [ ON SCALAR STRING ] ]
    [ { ERROR | NULL | EMPTY ARRAY | EMPTY OBJECT } ON EMPTY ]
    [ { ERROR | NULL | EMPTY ARRAY | EMPTY OBJECT } ON ERROR ]
    )
```

The constant string `json_path` is evaluated using the `json_input` as the
context variable (`$`), and the passed arguments as the named variables
(`$variable_name`).

The returned value is a JSON item returned by the path. By default, it is
represented as a character string (`varchar`). In the `RETURNING` clause,
you can specify other character string type or `varbinary`. With
`varbinary`, you can also specify the desired encoding.

`json_input` is a character string or a binary string. It should contain
a single JSON item. For a binary string, you can specify encoding.

`json_path` is a string literal, containing the path mode specification, and
the path expression, following the syntax rules described in
link`json-path-syntax-and-semantics`.

```text theme={null}
strict $.keyvalue()?(@.name == $cust_id)
lax $[5 to last]
```

In the `PASSING` clause you can pass arbitrary expressions to be used by the
path expression.

```text theme={null}
PASSING orders.custkey AS CUST_ID
```

The passed parameters can be referenced in the path expression by named
variables, prefixed with `$`.

```text theme={null}
strict $.keyvalue()?(@.value == $CUST_ID)
```

Additionally to SQL values, you can pass JSON values, specifying the format and
optional encoding:

```text theme={null}
PASSING orders.json_desc FORMAT JSON AS o_desc,
        orders.binary_record FORMAT JSON ENCODING UTF16 AS o_rec
```

Note that the JSON path language is case-sensitive, while the unquoted SQL
identifiers are upper-cased. Therefore, it is recommended to use quoted
identifiers in the `PASSING` clause:

```text theme={null}
lax $.$KeyName PASSING nation.name AS KeyName --> ERROR; no passed value found
lax $.$KeyName PASSING nation.name AS "KeyName" --> correct
```

The `ARRAY WRAPPER` clause lets you modify the output by wrapping the results
in a JSON array. `WITHOUT ARRAY WRAPPER` is the default option. `WITH
CONDITIONAL ARRAY WRAPPER` wraps every result which is not a singleton JSON
array or JSON object. `WITH UNCONDITIONAL ARRAY WRAPPER` wraps every result.

The `QUOTES` clause lets you modify the result for a scalar string by
removing the double quotes being part of the JSON string representation.

### Examples

Let `customers` be a table containing two columns: `id:bigint`,
`description:varchar`.

| id  | description                                       |
| --- | ------------------------------------------------- |
| 101 | `{"comment": "nice", "children": [10, 13, 16]}`   |
| 102 | `{"comment": "problematic", "children": [8, 11]}` |
| 103 | `{"comment": "knows best", "children": [2]}`      |

The following query gets the `children` array for each customer:

```sql theme={null}
SELECT
      id,
      json_query(
                 description,
                 lax $.children
                ) AS children
FROM customers
```

| id  | children    |
| --- | ----------- |
| 101 | \[10,13,16] |
| 102 | \[8,11]     |
| 103 | \[2]        |

The following query gets the collection of children for each customer.
Note that the `json_query` function can only output a single JSON item. If
you dont use array wrapper, you get an error for every customer with multiple
children. The error is handled according to the `ON ERROR` clause.

```sql theme={null}
SELECT
      id,
      json_query(
                 description,
                 lax $.children[*]
                 WITHOUT ARRAY WRAPPER
                 NULL ON ERROR
                ) AS children
FROM customers
```

| id  | children |
| --- | -------- |
| 101 | NULL     |
| 102 | NULL     |
| 103 | 2        |

The following query gets the last child for each customer, wrapped in a JSON
array:

```sql theme={null}
SELECT
      id,
      json_query(
                 description,
                 lax $.children[last]
                 WITH ARRAY WRAPPER
                ) AS last_child
FROM customers
```

| id  | last\_child |
| --- | ----------- |
| 101 | \[16]       |
| 102 | \[11]       |
| 103 | \[2]        |

The following query gets all children above the age of 12 for each customer,
wrapped in a JSON array. The second and the third customer dont have children
of this age. Such case is handled according to the `ON EMPTY` clause. The
default value returned `ON EMPTY` is `NULL`. In the following example,
`EMPTY ARRAY ON EMPTY` is specified.

```sql theme={null}
SELECT
      id,
      json_query(
                 description,
                 strict $.children[*]?(@ > 12)
                 WITH ARRAY WRAPPER
                 EMPTY ARRAY ON EMPTY
                ) AS children
FROM customers
```

| id  | children |
| --- | -------- |
| 101 | \[13,16] |
| 102 | \[]      |
| 103 | \[]      |

The following query shows the result of the `QUOTES` clause. Note that `KEEP
QUOTES` is the default.

```sql theme={null}
SELECT
      id,
      json_query(description, strict $.comment KEEP QUOTES) AS quoted_comment,
      json_query(description, strict $.comment OMIT QUOTES) AS unquoted_comment
FROM customers
```

| id  | quoted\_comment | unquoted\_comment |
| --- | --------------- | ----------------- |
| 101 | "nice"          | nice              |
| 102 | "problematic"   | problematic       |
| 103 | "knows best"    | knows best        |

If an error occurs, the returned value depends on the `ON ERROR` clause. The
default value returned `ON ERROR` is `NULL`. One example of error is
multiple items returned by the path. Other errors caught and handled according
to the `ON ERROR` clause are:

* Input conversion errors, such as malformed JSON
* JSON path evaluation errors, e.g. division by zero
* Output conversion errors

### json\_value

The `json_value` function extracts a scalar SQL value from a JSON value.

```text theme={null}
JSON_VALUE(
    json_input [ FORMAT JSON [ ENCODING { UTF8 | UTF16 | UTF32 } ] ],
    json_path
    [ PASSING json_argument [, ...] ]
    [ RETURNING type ]
    [ { ERROR | NULL | DEFAULT expression } ON EMPTY ]
    [ { ERROR | NULL | DEFAULT expression } ON ERROR ]
    )
```

The `json_path` is evaluated using the `json_input` as the context variable
(`$`), and the passed arguments as the named variables (`$variable_name`).

The returned value is the SQL scalar returned by the path. By default, it is
converted to string (`varchar`). In the `RETURNING` clause, you can specify
other desired type: a character string type, numeric, boolean or datetime type.

`json_input` is a character string or a binary string. It should contain
a single JSON item. For a binary string, you can specify encoding.

`json_path` is a string literal, containing the path mode specification, and
the path expression, following the syntax rules described in
link`json-path-syntax-and-semantics`.

```text theme={null}
strict $.price + $tax
lax $[last].abs().floor()
```

In the `PASSING` clause you can pass arbitrary expressions to be used by the
path expression.

```text theme={null}
PASSING orders.tax AS O_TAX
```

The passed parameters can be referenced in the path expression by named
variables, prefixed with `$`.

```text theme={null}
strict $[last].price + $O_TAX
```

Additionally to SQL values, you can pass JSON values, specifying the format and
optional encoding:

```text theme={null}
PASSING orders.json_desc FORMAT JSON AS o_desc,
        orders.binary_record FORMAT JSON ENCODING UTF16 AS o_rec
```

Note that the JSON path language is case-sensitive, while the unquoted SQL
identifiers are upper-cased. Therefore, it is recommended to use quoted
identifiers in the `PASSING` clause:

```text theme={null}
lax $.$KeyName PASSING nation.name AS KeyName --> ERROR; no passed value found
lax $.$KeyName PASSING nation.name AS "KeyName" --> correct
```

If the path returns an empty sequence, the `ON EMPTY` clause is applied. The
default value returned `ON EMPTY` is `NULL`. You can also specify the
default value:

```text theme={null}
DEFAULT -1 ON EMPTY
```

If an error occurs, the returned value depends on the `ON ERROR` clause. The
default value returned `ON ERROR` is `NULL`. One example of error is
multiple items returned by the path. Other errors caught and handled according
to the `ON ERROR` clause are:

* Input conversion errors, such as malformed JSON
* JSON path evaluation errors, e.g. division by zero
* Returned scalar not convertible to the desired type

### Examples

Let `customers` be a table containing two columns: `id:bigint`,
`description:varchar`.

| id  | description                                         |
| --- | --------------------------------------------------- |
| 101 | `{"comment" : "nice", "children" : [10, 13, 16]}`   |
| 102 | `{"comment" : "problematic", "children" : [8, 11]}` |
| 103 | `{"comment" : "knows best", "children" : [2]}`      |

The following query gets the `comment` for each customer as `char(12)`:

```sql theme={null}
SELECT id, json_value(
                      description,
                      lax $.comment
                      RETURNING char(12)
                     ) AS comment
FROM customers
```

| id  | comment     |
| --- | ----------- |
| 101 | nice        |
| 102 | problematic |
| 103 | knows best  |

The following query gets the first childs age for each customer as
`tinyint`:

```sql theme={null}
SELECT id, json_value(
                      description,
                      lax $.children[0]
                      RETURNING tinyint
                     ) AS child
FROM customers
```

| id  | child |
| --- | ----- |
| 101 | 10    |
| 102 | 8     |
| 103 | 2     |

The following query gets the third childs age for each customer. In the strict
mode, this should cause a structural error for the customers who do not have
the third child. This error is handled according to the `ON ERROR` clause.

```sql theme={null}
SELECT id, json_value(
                      description,
                      strict $.children[2]
                      DEFAULT err ON ERROR
                     ) AS child
FROM customers
```

| id  | child |
| --- | ----- |
| 101 | 16    |
| 102 | err   |
| 103 | err   |

After changing the mode to lax, the structural error is suppressed, and the
customers without a third child produce empty sequence. This case is handled
according to the `ON EMPTY` clause.

```sql theme={null}
SELECT id, json_value(
                      description,
                      lax $.children[2]
                      DEFAULT missing ON EMPTY
                     ) AS child
FROM customers
```

| id  | child   |
| --- | ------- |
| 101 | 16      |
| 102 | missing |
| 103 | missing |

(json-array)=

## json\_array

The `json_array` function creates a JSON array containing given elements.

```text theme={null}
JSON_ARRAY(
    [ array_element [, ...]
      [ { NULL ON NULL | ABSENT ON NULL } ] ],
    [ RETURNING type [ FORMAT JSON [ ENCODING { UTF8 | UTF16 | UTF32 } ] ] ]
    )
```

### Argument types

The array elements can be arbitrary expressions. Each passed value is converted
into a JSON item according to its type, and optional `FORMAT` and
`ENCODING` specification.

You can pass SQL values of types boolean, numeric, and character string. They
are converted to corresponding JSON literals:

```sql theme={null}
SELECT json_array(true, 12e-1, text)
--> [true,1.2,"text"]
```

Additionally to SQL values, you can pass JSON values. They are character or
binary strings with a specified format and optional encoding:

```
SELECT json_array(
                  [  "text"  ]  FORMAT JSON,
                  X5B0035005D00 FORMAT JSON ENCODING UTF16
                 )
--> [["text"],[5]]
```

You can also nest other JSON-returning functions. In that case, the `FORMAT`
option is implicit:

```sql theme={null}
SELECT json_array(
                  json_query({"key" : [  "value"  ]}, lax $.key)
                 )
--> [["value"]]
```

Other passed values are cast to varchar, and they become JSON text literals:

```sql theme={null}
SELECT json_array(
                  DATE 2001-01-31,
                  UUID 12151fd2-7586-11e9-8f9e-2a86e4085a59
                 )
--> ["2001-01-31","12151fd2-7586-11e9-8f9e-2a86e4085a59"]
```

You can omit the arguments altogether to get an empty array:

```sql theme={null}
SELECT json_array() --> []
```

### Null handling

If a value passed for an array element is `null`, it is treated according to
the specified null treatment option. If `ABSENT ON NULL` is specified, the
null element is omitted in the result. If `NULL ON NULL` is specified, JSON
`null` is added to the result. `ABSENT ON NULL` is the default
configuration:

```sql theme={null}
SELECT json_array(true, null, 1)
--> [true,1]

SELECT json_array(true, null, 1 ABSENT ON NULL)
--> [true,1]

SELECT json_array(true, null, 1 NULL ON NULL)
--> [true,null,1]
```

### Returned type

The SQL standard imposes that there is no dedicated data type to represent JSON
data in SQL. Instead, JSON data is represented as character or binary strings.
By default, the `json_array` function returns varchar containing the textual
representation of the JSON array. With the `RETURNING` clause, you can
specify other character string type:

```sql theme={null}
SELECT json_array(true, 1 RETURNING VARCHAR(100))
--> [true,1]
```

You can also specify to use varbinary and the required encoding as return type.
The default encoding is UTF8:

```sql theme={null}
SELECT json_array(true, 1 RETURNING VARBINARY)
--> X5b 74 72 75 65 2c 31 5d

SELECT json_array(true, 1 RETURNING VARBINARY FORMAT JSON ENCODING UTF8)
--> X5b 74 72 75 65 2c 31 5d

SELECT json_array(true, 1 RETURNING VARBINARY FORMAT JSON ENCODING UTF16)
--> X5b 00 74 00 72 00 75 00 65 00 2c 00 31 00 5d 00

SELECT json_array(true, 1 RETURNING VARBINARY FORMAT JSON ENCODING UTF32)
--> X5b 00 00 00 74 00 00 00 72 00 00 00 75 00 00 00 65 00 00 00 2c 00 00 00 31 00 00 00 5d 00 00 00
```

(json-object)=

## json\_object

The `json_object` function creates a JSON object containing given key-value pairs.

```text theme={null}
JSON_OBJECT(
    [ key_value [, ...]
      [ { NULL ON NULL | ABSENT ON NULL } ] ],
      [ { WITH UNIQUE [ KEYS ] | WITHOUT UNIQUE [ KEYS ] } ]
    [ RETURNING type [ FORMAT JSON [ ENCODING { UTF8 | UTF16 | UTF32 } ] ] ]
    )
```

### Argument passing conventions

There are two conventions for passing keys and values:

```sql theme={null}
SELECT json_object('key1' : 1, 'key2' : true)
--> {"key1":1,"key2":true}

SELECT json_object(KEY 'key1' VALUE 1, KEY 'key2' VALUE true)
--> {"key1":1,"key2":true}
```

In the second convention, you can omit the `KEY` keyword:

```sql theme={null}
SELECT json_object('key1' VALUE 1, 'key2' VALUE true)
--> {"key1":1,"key2":true}
```

### Argument types

The keys can be arbitrary expressions. They must be of character string type.
Each key is converted into a JSON text item, and it becomes a key in the
created JSON object. Keys must not be null.

The values can be arbitrary expressions. Each passed value is converted
into a JSON item according to its type, and optional `FORMAT` and
`ENCODING` specification.

You can pass SQL values of types boolean, numeric, and character string. They
are converted to corresponding JSON literals:

```sql theme={null}
SELECT json_object('x' : true, 'y' : 12e-1, 'z' : 'text')
--> {"x":true,"y":1.2,"z":"text"}
```

Additionally to SQL values, you can pass JSON values. They are character or
binary strings with a specified format and optional encoding:

```sql theme={null}
SELECT json_object(
                   'x' : '[  "text"  ] ' FORMAT JSON,
                   'y' : X'5B0035005D00' FORMAT JSON ENCODING UTF16
                  )
--> {"x":["text"],"y":[5]}
```

You can also nest other JSON-returning functions. In that case, the `FORMAT`
option is implicit:

```sql theme={null}
SELECT json_object(
                   'x' : json_query('{"key" : [  "value"  ]}', 'lax $.key')
                  )
--> {"x":["value"]}
```

Other passed values are cast to varchar, and they become JSON text literals:

```sql theme={null}
SELECT json_object(
                   'x' : DATE '2001-01-31',
                   'y' : UUID '12151fd2-7586-11e9-8f9e-2a86e4085a59'
                  )
--> {"x":"2001-01-31","y":"12151fd2-7586-11e9-8f9e-2a86e4085a59"}
```

You can omit the arguments altogether to get an empty object:

```sql theme={null}
SELECT json_object() --> {}
```

### Null handling

The values passed for JSON object keys must not be null. It is allowed to pass
`null` for JSON object values. A null value is treated according to the
specified null treatment option. If `NULL ON NULL` is specified, a JSON
object entry with `null` value is added to the result. If `ABSENT ON NULL`
is specified, the entry is omitted in the result. `NULL ON NULL` is the
default configuration.:

```sql theme={null}
SELECT json_object('x' : null, 'y' : 1)
--> '{"x":null,"y":1}'

SELECT json_object('x' : null, 'y' : 1 NULL ON NULL)
--> '{"x":null,"y":1}'

SELECT json_object('x' : null, 'y' : 1 ABSENT ON NULL)
--> '{"y":1}'
```

### Key uniqueness

If a duplicate key is encountered, it is handled according to the specified key
uniqueness constraint.

If `WITH UNIQUE KEYS` is specified, a duplicate key results in a query
failure:

```sql theme={null}
SELECT json_object('x' : null, 'x' : 1 WITH UNIQUE KEYS)
--> failure: "duplicate key passed to JSON_OBJECT function"
```

Note that this option is not supported if any of the arguments has a
`FORMAT` specification.

If `WITHOUT UNIQUE KEYS` is specified, duplicate keys are not supported due
to implementation limitation. `WITHOUT UNIQUE KEYS` is the default
configuration.

### Returned type

The SQL standard imposes that there is no dedicated data type to represent JSON
data in SQL. Instead, JSON data is represented as character or binary strings.
By default, the `json_object` function returns varchar containing the textual
representation of the JSON object. With the `RETURNING` clause, you can
specify other character string type:

```sql theme={null}
SELECT json_object('x' : 1 RETURNING VARCHAR(100))
--> '{"x":1}'
```

You can also specify to use varbinary and the required encoding as return type.
The default encoding is UTF8:

```sql theme={null}
SELECT json_object('x' : 1 RETURNING VARBINARY)
--> X'7b 22 78 22 3a 31 7d'

SELECT json_object('x' : 1 RETURNING VARBINARY FORMAT JSON ENCODING UTF8)
--> X'7b 22 78 22 3a 31 7d'

SELECT json_object('x' : 1 RETURNING VARBINARY FORMAT JSON ENCODING UTF16)
--> X'7b 00 22 00 78 00 22 00 3a 00 31 00 7d 00'

SELECT json_object('x' : 1 RETURNING VARBINARY FORMAT JSON ENCODING UTF32)
--> X'7b 00 00 00 22 00 00 00 78 00 00 00 22 00 00 00 3a 00 00 00 31 00 00 00 7d 00 00 00'
```

## Cast to JSON

<Warning>
  The following functions and operators are not compliant with the SQL
  standard, and should be considered deprecated. According to the SQL
  standard, there shall be no `JSON` data type. Instead, JSON values
  should be represented as string values. The remaining functionality of the
  following functions is covered by the functions described previously.
</Warning>

The following types can be cast to JSON:

* `BOOLEAN`
* `TINYINT`
* `SMALLINT`
* `INTEGER`
* `BIGINT`
* `REAL`
* `DOUBLE`
* `VARCHAR`

Additionally, `ARRAY`, `MAP`, and `ROW` types can be cast to JSON when
the following requirements are met:

* `ARRAY` types can be cast when the element type of the array is one
  of the supported types.
* `MAP` types can be cast when the key type of the map is `VARCHAR` and
  the value type of the map is a supported type,
* `ROW` types can be cast when every field type of the row is a supported
  type.

<Note>
  Cast operations with supported link`character string types <string-data-types>` treat the input as a string, not validated as JSON.
  This means that a cast operation with a string-type input of invalid JSON
  results in a successful cast to invalid JSON.
  Instead, consider using the `json_parse` function to
  create validated JSON from a string.
</Note>

The following examples show the behavior of casting to JSON with these types:

```sql theme={null}
SELECT CAST(NULL AS JSON);
-- NULL

SELECT CAST(1 AS JSON);
-- JSON '1'

SELECT CAST(9223372036854775807 AS JSON);
-- JSON '9223372036854775807'

SELECT CAST('abc' AS JSON);
-- JSON '"abc"'

SELECT CAST(true AS JSON);
-- JSON 'true'

SELECT CAST(1.234 AS JSON);
-- JSON '1.234'

SELECT CAST(ARRAY[1, 23, 456] AS JSON);
-- JSON '[1,23,456]'

SELECT CAST(ARRAY[1, NULL, 456] AS JSON);
-- JSON '[1,null,456]'

SELECT CAST(ARRAY[ARRAY[1, 23], ARRAY[456]] AS JSON);
-- JSON '[[1,23],[456]]'

SELECT CAST(MAP(ARRAY['k1', 'k2', 'k3'], ARRAY[1, 23, 456]) AS JSON);
-- JSON '{"k1":1,"k2":23,"k3":456}'

SELECT CAST(CAST(ROW(123, 'abc', true) AS
            ROW(v1 BIGINT, v2 VARCHAR, v3 BOOLEAN)) AS JSON);
-- JSON '{"v1":123,"v2":"abc","v3":true}'
```

Casting from NULL to `JSON` is not straightforward. Casting
from a standalone `NULL` will produce SQL `NULL` instead of
`JSON null`. However, when casting from arrays or map containing
`NULL`s, the produced `JSON` will have `null`s in it.

## Cast from JSON

Casting to `BOOLEAN`, `TINYINT`, `SMALLINT`, `INTEGER`,
`BIGINT`, `REAL`, `DOUBLE` or `VARCHAR` is supported.
Casting to `ARRAY` and `MAP` is supported when the element type of
the array is one of the supported types, or when the key type of the map
is `VARCHAR` and value type of the map is one of the supported types.
Behaviors of the casts are shown with the examples below:

```sql theme={null}
SELECT CAST(JSON 'null' AS VARCHAR);
-- NULL

SELECT CAST(JSON '1' AS INTEGER);
-- 1

SELECT CAST(JSON '9223372036854775807' AS BIGINT);
-- 9223372036854775807

SELECT CAST(JSON '"abc"' AS VARCHAR);
-- abc

SELECT CAST(JSON 'true' AS BOOLEAN);
-- true

SELECT CAST(JSON '1.234' AS DOUBLE);
-- 1.234

SELECT CAST(JSON '[1,23,456]' AS ARRAY(INTEGER));
-- [1, 23, 456]

SELECT CAST(JSON '[1,null,456]' AS ARRAY(INTEGER));
-- [1, NULL, 456]

SELECT CAST(JSON '[[1,23],[456]]' AS ARRAY(ARRAY(INTEGER)));
-- [[1, 23], [456]]

SELECT CAST(JSON '{"k1":1,"k2":23,"k3":456}' AS MAP(VARCHAR, INTEGER));
-- {k1=1, k2=23, k3=456}

SELECT CAST(JSON '{"v1":123,"v2":"abc","v3":true}' AS
            ROW(v1 BIGINT, v2 VARCHAR, v3 BOOLEAN));
-- {v1=123, v2=abc, v3=true}

SELECT CAST(JSON '[123,"abc",true]' AS
            ROW(v1 BIGINT, v2 VARCHAR, v3 BOOLEAN));
-- {v1=123, v2=abc, v3=true}
```

JSON arrays can have mixed element types and JSON maps can have mixed
value types. This makes it impossible to cast them to SQL arrays and maps in
some cases. To address this, Trino supports partial casting of arrays and maps:

```sql theme={null}
SELECT CAST(JSON '[[1, 23], 456]' AS ARRAY(JSON));
-- [JSON '[1,23]', JSON '456']

SELECT CAST(JSON '{"k1": [1, 23], "k2": 456}' AS MAP(VARCHAR, JSON));
-- {k1 = JSON '[1,23]', k2 = JSON '456'}

SELECT CAST(JSON '[null]' AS ARRAY(JSON));
-- [JSON 'null']
```

When casting from `JSON` to `ROW`, both JSON array and JSON object are supported.

## Other JSON functions

In addition to the functions explained in more details in the preceding
sections, the following functions are available:

#### is\_json\_scalar()

**`is_json_scalar(json)`** → boolean

Determine if `json` is a scalar (i.e. a JSON number, a JSON string, `true`, `false` or `null`):

```sql theme={null}
SELECT is_json_scalar('1');         -- true
SELECT is_json_scalar('[1, 2, 3]'); -- false
```

#### json\_array\_contains()

**`json_array_contains(json, value)`** → boolean

Determine if `value` exists in `json` (a string containing a JSON array):

```sql theme={null}
SELECT json_array_contains('[1, 2, 3]', 2); -- true
```

#### json\_array\_get()

**`json_array_get(json_array, index)`** → json

<Warning>
  The semantics of this function are broken. If the extracted element
  is a string, it will be converted into an invalid `JSON` value that
  is not properly quoted (the value will not be surrounded by quotes
  and any interior quotes will not be escaped).

  We recommend against using this function. It cannot be fixed without
  impacting existing usages and may be removed in a future release.
</Warning>

Returns the element at the specified index into the `json_array`.
The index is zero-based:

```sql theme={null}
SELECT json_array_get('["a", [3, 9], "c"]', 0); -- JSON 'a' (invalid JSON)
SELECT json_array_get('["a", [3, 9], "c"]', 1); -- JSON '[3,9]'
```

This function also supports negative indexes for fetching element indexed
from the end of an array:

```sql theme={null}
SELECT json_array_get('["c", [3, 9], "a"]', -1); -- JSON 'a' (invalid JSON)
SELECT json_array_get('["c", [3, 9], "a"]', -2); -- JSON '[3,9]'
```

If the element at the specified index doesn't exist, the function returns null:

```sql theme={null}
SELECT json_array_get('[]', 0);                -- NULL
SELECT json_array_get('["a", "b", "c"]', 10);  -- NULL
SELECT json_array_get('["c", "b", "a"]', -10); -- NULL
```

#### json\_array\_length()

**`json_array_length(json)`** → bigint

Returns the array length of `json` (a string containing a JSON array):

```sql theme={null}
SELECT json_array_length('[1, 2, 3]'); -- 3
```

#### json\_extract()

**`json_extract(json, json_path)`** → json

Evaluates the \[JSONPath]-like expression `json_path` on `json`
(a string containing JSON) and returns the result as a JSON string:

```sql theme={null}
SELECT json_extract(json, '$.store.book');
SELECT json_extract(json, '$.store[book]');
SELECT json_extract(json, '$.store["book name"]');
```

The `json_query` function provides a more powerful and
feature-rich alternative to parse and extract JSON data.

#### json\_extract\_scalar()

**`json_extract_scalar(json, json_path)`** → varchar

Like json\_extract`, but returns the result value as a string (as opposed
to being encoded as JSON). The value referenced by `json\_path\` must be a
scalar (boolean, number or string).

```sql theme={null}
SELECT json_extract_scalar('[1, 2, 3]', '$[2]');
SELECT json_extract_scalar(json, '$.store.book[0].author');
```

#### json\_format()

**`json_format(json)`** → varchar

Returns the JSON text serialized from the input JSON value.
This is inverse function to `json_parse`:

```sql theme={null}
SELECT json_format(JSON '[1, 2, 3]'); -- '[1,2,3]'
SELECT json_format(JSON '"a"');       -- '"a"'
```

<Note>
  `json_format` and `CAST(json AS VARCHAR)` have completely different semantics.

  `json_format` serializes the input JSON value to JSON text conforming to
  rfc`7159`. The JSON value can be a JSON object, a JSON array, a JSON string,
  a JSON number, `true`, `false` or `null`.

  ```sql theme={null}
  SELECT json_format(JSON '{"a": 1, "b": 2}'); -- '{"a":1,"b":2}'
  SELECT json_format(JSON '[1, 2, 3]');        -- '[1,2,3]'
  SELECT json_format(JSON '"abc"');            -- '"abc"'
  SELECT json_format(JSON '42');               -- '42'
  SELECT json_format(JSON 'true');             -- 'true'
  SELECT json_format(JSON 'null');             -- 'null'
  ```

  `CAST(json AS VARCHAR)` casts the JSON value to the corresponding SQL VARCHAR value.
  For JSON string, JSON number, `true`, `false` or `null`, the cast
  behavior is same as the corresponding SQL type. JSON object and JSON array
  cannot be cast to VARCHAR.

  ```sql theme={null}
  SELECT CAST(JSON '{"a": 1, "b": 2}' AS VARCHAR); -- ERROR!
  SELECT CAST(JSON '[1, 2, 3]' AS VARCHAR);        -- ERROR!
  SELECT CAST(JSON '"abc"' AS VARCHAR);            -- 'abc' (the double quote is gone)
  SELECT CAST(JSON '42' AS VARCHAR);               -- '42'
  SELECT CAST(JSON 'true' AS VARCHAR);             -- 'true'
  SELECT CAST(JSON 'null' AS VARCHAR);             -- NULL
  ```
</Note>

#### json\_parse()

**`json_parse(string)`** → json

Returns the JSON value deserialized from the input JSON text.
This is inverse function to `json_format`:

```sql theme={null}
SELECT json_parse('[1, 2, 3]');   -- JSON '[1,2,3]'
SELECT json_parse('"abc"');       -- JSON '"abc"'
```

`json_parse` expects a JSON text conforming to rfc`7159`, and returns
the JSON value deserialized from the JSON text.
The JSON value can be a JSON object, a JSON array, a JSON string, a JSON number,
`true`, `false` or `null`.

```sql theme={null}
SELECT json_parse('not_json');         -- ERROR!
SELECT json_parse('["a": 1, "b": 2]'); -- JSON '["a": 1, "b": 2]'
SELECT json_parse('[1, 2, 3]');        -- JSON '[1,2,3]'
SELECT json_parse('"abc"');            -- JSON '"abc"'
SELECT json_parse('42');               -- JSON '42'
SELECT json_parse('true');             -- JSON 'true'
SELECT json_parse('null');             -- JSON 'null'
```

`CAST(string AS JSON)` takes any VARCHAR value as input, and returns
a JSON string with its value set to input string.

```
SELECT CAST('not_json' AS JSON);         -- JSON '"not_json"'
SELECT CAST('["a": 1, "b": 2]' AS JSON); -- JSON '"[\"a\": 1, \"b\": 2]"'
SELECT CAST('[1, 2, 3]' AS JSON);        -- JSON '"[1, 2, 3]"'
SELECT CAST('"abc"' AS JSON);            -- JSON '"\"abc\""'
SELECT CAST('42' AS JSON);               -- JSON '"42"'
SELECT CAST('true' AS JSON);             -- JSON '"true"'
SELECT CAST('null' AS JSON);             -- JSON '"null"'
```

#### json\_size()

**`json_size(json, json_path)`** → bigint

Like `json_extract`, but returns the size of the value.
For objects or arrays, the size is the number of members, and the size of a scalar value is zero.

```sql theme={null}
SELECT json_size('{"x": {"a": 1, "b": 2}}', '$.x');   -- 2
SELECT json_size('{"x": [1, 2, 3]}', '$.x');          -- 3
SELECT json_size('{"x": {"a": 1, "b": 2}}', '$.x.a'); -- 0
```


# Lambda expressions
Source: https://docs.dune.com/query-engine/Functions-and-operators/lambda

Lambda expressions are anonymous functions which are passed as arguments to higher-order SQL functions.

Lambda expressions are written with `->`:

```text theme={null}
    x -> x + 1
    (x, y) -> x + y
    x -> regexp_like(x, 'a+')
    x -> x[1] / x[2]
    x -> IF(x > 0, x, -x)
    x -> COALESCE(x, 0)
    x -> CAST(x AS JSON)
    x -> x + TRY(1 / 0)
```

## Limitations

Most SQL expressions can be used in a lambda body, with a few
exceptions:

* Subqueries are not supported: `x -> 2 + (SELECT 3)`
* Aggregations are not supported: `x -> max(y)`

## Examples

Obtain the squared elements of an array column with
`transform`:

```sql theme={null}
    SELECT numbers,
           transform(numbers, n -> n * n) as squared_numbers
    FROM (
        VALUES
            (ARRAY[1, 2]),
            (ARRAY[3, 4]),
            (ARRAY[5, 6, 7])
    ) AS t(numbers);
```

**Results**:

| numbers    | squared\_numbers |
| ---------- | ---------------- |
| \[1, 2]    | \[1, 4]          |
| \[3, 4]    | \[9, 16]         |
| \[5, 6, 7] | \[25, 36, 49]    |

The function `transform` can be also
employed to safely cast the elements of an array to strings:

```sql theme={null}
    SELECT transform(prices, n -> TRY_CAST(n AS VARCHAR) || '$') as price_tags
    FROM (
        VALUES
            (ARRAY[100, 200]),
            (ARRAY[30, 4])
    ) AS t(prices);
```

**Results**:

| price\_tags   |
| ------------- |
| \[100$, 200$] |
| \[30$, 4$]    |

Besides the array column being manipulated, other columns can be
captured as well within the lambda expression. The following statement
provides a showcase of this feature for calculating the value of the
linear function `f(x) = ax + b` with `transform`:

```sql theme={null}
    SELECT xvalues,
           a,
           b,
           transform(xvalues, x -> a * x + b) as linear_function_values
    FROM (
        VALUES
            (ARRAY[1, 2], 10, 5),
            (ARRAY[3, 4], 4, 2)
    ) AS t(xvalues, a, b);
```

**Results**:

| xvalues | a  | b | linear\_function\_values |
| ------- | -- | - | ------------------------ |
| \[1, 2] | 10 | 5 | \[15, 25]                |
| \[3, 4] | 4  | 2 | \[14, 18]                |

Find the array elements containing at least one value greater than `100`
with `any_match`:

```sql theme={null}
    SELECT numbers
    FROM (
        VALUES
            (ARRAY[1,NULL,3]),
            (ARRAY[10,20,30]),
            (ARRAY[100,200,300])
    ) AS t(numbers)
    WHERE any_match(numbers, n ->  COALESCE(n, 0) > 100);
    -- [100, 200, 300]
```

Capitalize the f word in a string via `regexp_replace`:

```sql theme={null}
    SELECT regexp_replace('once upon a time ...', '^(\w)(\w*)(\s+.*)$',x -> upper(x[1]) || x[2] || x[3]);
    -- Once upon a time ...
```

Lambda expressions can be also applied in aggregation functions.
Following statement is a sample the overly complex calculation of the
sum of all elements of a column by making use of `reduce_agg`:

```sql theme={null}
    SELECT reduce_agg(value, 0, (a, b) -> a + b, (a, b) -> a + b) sum_values
    FROM (
        VALUES (1), (2), (3), (4), (5)
    ) AS t(value);
    -- 15
```


# LiveFetch functions
Source: https://docs.dune.com/query-engine/Functions-and-operators/live-fetch

LiveFetch functions send HTTP requests to a specified URL.

The LiveFetch functions send HTTP requests to a specified URL.
Using the LiveFetch functions, you can interact with HTTP servers directly in SQL queries.
They allow to fetch data from external APIs, as well as invoke remote procedure calls.

With the LiveFetch functions we can e.g. pull in a list of coins from coingecko:

```sql theme={null}
SELECT * FROM UNNEST(
    CAST(json_parse(
        http_get('https://api.coingecko.com/api/v3/coins/list'))
    AS array(json))) t(coin_data)
```

<DuneEmbed />

<CardGroup>
  <Card title="Example Dashboard" icon="chart-simple" href="https://dune.com/dune/dunesql-live-fetch-functions">
    A dashboard with examples of LiveFetch functions.
  </Card>
</CardGroup>

## API support and credentials

There are no limits to the supported APIs. The URL can point to any public or private API.

If you need to pass credentials for the API, you can include them in the headers.
For example, you can use the `Authorization` header to pass a token.
If you choose to hardcode the credentials in the query, please make sure to keep the query private.
Optionally, you can use a query parameter as a placeholder:

```sql theme={null}
SELECT http_get(
    'https://api.blastscan.io/api?module=block&action=getblocknobytime&timestamp=1711712564&closest=before&apikey={{api_key}}'
);
```

## Functions

#### http\_get()

**`http_get(url: varchar)`** → varchar

**`http_get(url: varchar, headers: array(varchar))`** → varchar

The function sends an HTTP GET request to the given URL, optionally including the provided headers,
and returns the response body as `varchar`.

Often, the response is a JSON document. You can process it further with [JSON-processing SQL functions](/query-engine/Functions-and-operators/json).
Other response formats, like html, are also supported.

#### http\_post()

**`http_post(url: varchar, body: varchar)`** → varchar

**`http_post(url: varchar, body: varchar, headers: array(varchar))`** → varchar

The function sends an HTTP POST request to the given URL, including the provided data in the request body,
and optionally including the headers. It returns the response body as `varchar`.

The type of the body argument is `varchar`. It gives you flexibility to send JSON data as well as text.

## Limits

**Call timeout:** A call issued by an HTTP function times out after 5 seconds.

**Throttling:** Requests from each query execution are limited to 80 requests per second per proxy.
There are currently 3 proxies configured per clusterset. The rate limit is shared between all HTTP function calls
made within the query.

**Response size limit:** Maximum accepted response body size is 4\_194\_304 bytes (4 MiB).

**Request size limit:** Maximum accepted request body size for `http_post()` is 1\_000\_000 bytes.

## Examples

### Single HTTP GET request to list coins from CoinGecko

```sql theme={null}
SELECT http_get('https://api.coingecko.com/api/v3/coins/list');
```

### Multiple HTTP GET requests parametrized with Dune data

```sql theme={null}
SELECT
    http_get(concat('https://coins.llama.fi/prices/current/ethereum:', CAST(contract_address AS varchar)))
FROM tokens_ethereum.stablecoins;
```

### JSON processing with http\_get()

```sql theme={null}
SELECT
    contract_address,
    json_query(
        http_get(concat('https://coins.llama.fi/prices/current/ethereum:', CAST(contract_address AS varchar))),
        'lax $.coins.*?(@.decimals==18).keyvalue()?(@.name=="symbol" || @.name=="price" || @.name=="decimals").value'
        WITH ARRAY WRAPPER
        EMPTY ARRAY ON EMPTY
) as coin_data
FROM tokens_ethereum.stablecoins;
```

### Using http\_get() in a subquery as a static filter

By wrapping the `http_get()` function in a subquery, you can use it as a static filter in the main query.
It helps to avoid repeating the same HTTP request multiple times.

```sql theme={null}
SELECT *
FROM
    ethereum.transactions t1,
    (SELECT from_hex(json_extract_scalar(http_get('https://api.ensideas.com/ens/resolve/vitalik.eth'),'$.address'))) t2(x)
WHERE t1."from" = t2.x;
```

### RPC call with http\_post()

```sql theme={null}
SELECT http_post(
		'https://docs-demo.quiknode.pro',
		'{"method":"eth_chainId","params":[],"id":1,"jsonrpc":"2.0"}',
		ARRAY['Content-Type: application/json']);
```

If you want a more complex example, [see this post call to compound comet read functions here](https://dune.com/queries/3571891).

### Handling quotation marks

If your payload contains the `'` character, you need to quote it properly because it is the bounding character of `varchar`.
Each `'` character should be doubled, and the query engine will unwrap them.

```sql theme={null}
SELECT json_value(
	        http_post(
			    'https://httpbin.org/post',
				'foo',
				ARRAY['MyHeader : Use two '' quotes']),
			'lax $.headers.Myheader');
```


# Logical operators
Source: https://docs.dune.com/query-engine/Functions-and-operators/logical



## Logical operators

| Operator | Description                  | Example |
| -------- | ---------------------------- | ------- |
| `AND`    | True if both values are true | a AND b |
| `OR`     | True if either value is true | a OR b  |
| `NOT`    | True if the value is false   | NOT a   |

## Effect of NULL on logical operators

The result of an `AND` comparison may be `NULL` if one or both sides of
the expression are `NULL`. If at least one side of an `AND` operator is
`FALSE` the expression evaluates to `FALSE`:

```sql theme={null}
    SELECT CAST(null AS boolean) AND true; -- null

    SELECT CAST(null AS boolean) AND false; -- false

    SELECT CAST(null AS boolean) AND CAST(null AS boolean); -- null
```

The result of an `OR` comparison may be `NULL` if one or both sides of
the expression are `NULL`. If at least one side of an `OR` operator is
`TRUE` the expression evaluates to `TRUE`:

```sql theme={null}
    SELECT CAST(null AS boolean) OR CAST(null AS boolean); -- null

    SELECT CAST(null AS boolean) OR false; -- null

    SELECT CAST(null AS boolean) OR true; -- true
```

The following truth table demonstrates the handling of `NULL` in `AND`
and `OR`:

| a       | b       | a AND b | a OR b  |
| ------- | ------- | ------- | ------- |
| `TRUE`  | `TRUE`  | `TRUE`  | `TRUE`  |
| `TRUE`  | `FALSE` | `FALSE` | `TRUE`  |
| `TRUE`  | `NULL`  | `NULL`  | `TRUE`  |
| `FALSE` | `TRUE`  | `FALSE` | `TRUE`  |
| `FALSE` | `FALSE` | `FALSE` | `FALSE` |
| `FALSE` | `NULL`  | `FALSE` | `NULL`  |
| `NULL`  | `TRUE`  | `NULL`  | `TRUE`  |
| `NULL`  | `FALSE` | `FALSE` | `NULL`  |
| `NULL`  | `NULL`  | `NULL`  | `NULL`  |

The logical complement of `NULL` is `NULL` as shown in the following
example:

```sql theme={null}
    SELECT NOT CAST(null AS boolean); -- null
```

The following truth table demonstrates the handling of `NULL` in `NOT`:

| a       | NOT a   |
| ------- | ------- |
| `TRUE`  | `FALSE` |
| `FALSE` | `TRUE`  |
| `NULL`  | `NULL`  |


# Map functions and operators
Source: https://docs.dune.com/query-engine/Functions-and-operators/map



## Subscript operator: \[]

The `[]` operator is used to retrieve the value corresponding to a given
key from a map:

```sql theme={null}
    SELECT name_to_age_map['Bob'] AS bob_age;
```

## Map functions

#### cardinality()

**`cardinality(x)`** → bigint

Returns the cardinality (size) of the map `x`.

#### element\_at()

**`element_at(map(K,V), key)`** → V

Returns value for given `key`, or `NULL` if the key is not contained in
the map.

#### map()

**`map()`** → map(unknown, unknown)

Returns an empty map:

```sql theme={null}
    SELECT map();
    -- {}
```

**`map(array(K), array(V))`** → map(K,V)

Returns a map created using the given key/value arrays:

```sql theme={null}
    SELECT map(ARRAY[1,3], ARRAY[2,4]);
    -- {1 -> 2, 3 -> 4}
```

See also `map_agg` and `multimap_agg` for creating a map as an aggregation.

#### map\_from\_entries()

**`map_from_entries(array(row(K,V)))`** → map(K,V)

Returns a map created from the given array of entries:

```sql theme={null}
    SELECT map_from_entries(ARRAY[(1, 'x'), (2, 'y')]);
    -- {1 -> 'x', 2 -> 'y'}
```

#### multimap\_from\_entries()

**`multimap_from_entries(array(row(K,V)))`** → map(K,array(V))

Returns a multimap created from the given array of entries. Each key can
be associated with multiple values:

```sql theme={null}
    SELECT multimap_from_entries(ARRAY[(1, 'x'), (2, 'y'), (1, 'z')]);
    -- {1 -> ['x', 'z'], 2 -> ['y']}
```

#### map\_entries()

**`map_entries(map(K,V))`** → array(row(K,V))

Returns an array of all entries in the given map:

```sql theme={null}
    SELECT map_entries(MAP(ARRAY[1, 2], ARRAY['x', 'y']));
    -- [ROW(1, 'x'), ROW(2, 'y')]
```

#### map\_concat()

**`map_concat(map1(K,V), map2(K,V), ..., mapN(K,V))`** → map(K,V)

Returns the union of all the given maps. If a key is found in multiple
given maps, that key's value in the resulting map comes from the last
one of those maps.

#### map\_filter()

**`map_filter(map(K,V), function(K,V,boolean))`** → map(K,V)

Constructs a map from those entries of `map` for which `function`
returns true:

```sql theme={null}
    SELECT map_filter(MAP(ARRAY[], ARRAY[]), (k, v) -> true);
    -- {}

    SELECT map_filter(MAP(ARRAY[10, 20, 30], ARRAY['a', NULL, 'c']),
                      (k, v) -> v IS NOT NULL);
    -- {10 -> a, 30 -> c}

    SELECT map_filter(MAP(ARRAY['k1', 'k2', 'k3'], ARRAY[20, 3, 15]),
                      (k, v) -> v > 10);
    -- {k1 -> 20, k3 -> 15}
```

#### map\_keys()

**`map_keys(x(K,V))`** → array(K)

Returns all the keys in the map `x`.

#### map\_values()

**`map_values(x(K,V))`** → array(V)

Returns all the values in the map `x`.

#### map\_zip\_with()

**`map_zip_with(map(K,V1), map(K,V2), function(K,V1,V2,V3))`** → map(K,V3)

Merges the two given maps into a single map by applying `function` to
the pair of values with the same key. For keys only presented in one
map, NULL will be passed as the value for the missing key:

```sql theme={null}
    SELECT map_zip_with(MAP(ARRAY[1, 2, 3], ARRAY['a', 'b', 'c']),
                        MAP(ARRAY[1, 2, 3], ARRAY['d', 'e', 'f']),
                        (k, v1, v2) -> concat(v1, v2));
    -- {1 -> ad, 2 -> be, 3 -> cf}

    SELECT map_zip_with(MAP(ARRAY['k1', 'k2'], ARRAY[1, 2]),
                        MAP(ARRAY['k2', 'k3'], ARRAY[4, 9]),
                        (k, v1, v2) -> (v1, v2));
    -- {k1 -> ROW(1, null), k2 -> ROW(2, 4), k3 -> ROW(null, 9)}

    SELECT map_zip_with(MAP(ARRAY['a', 'b', 'c'], ARRAY[1, 8, 27]),
                        MAP(ARRAY['a', 'b', 'c'], ARRAY[1, 2, 3]),
                        (k, v1, v2) -> k || CAST(v1 / v2 AS VARCHAR));
    -- {a -> a1, b -> b4, c -> c9}
```

#### transform\_keys()

**`transform_keys(map(K1,V), function(K1,V,K2))`** → map(K2,V)

Returns a map that applies `function` to each entry of `map` and
transforms the keys:

```sql theme={null}
    SELECT transform_keys(MAP(ARRAY[], ARRAY[]), (k, v) -> k + 1);
    -- {}

    SELECT transform_keys(MAP(ARRAY [1, 2, 3], ARRAY ['a', 'b', 'c']),
                          (k, v) -> k + 1);
    -- {2 -> a, 3 -> b, 4 -> c}

    SELECT transform_keys(MAP(ARRAY ['a', 'b', 'c'], ARRAY [1, 2, 3]),
                          (k, v) -> v * v);
    -- {1 -> 1, 4 -> 2, 9 -> 3}

    SELECT transform_keys(MAP(ARRAY ['a', 'b'], ARRAY [1, 2]),
                          (k, v) -> k || CAST(v as VARCHAR));
    -- {a1 -> 1, b2 -> 2}

    SELECT transform_keys(MAP(ARRAY [1, 2], ARRAY [1.0, 1.4]),
                          (k, v) -> MAP(ARRAY[1, 2], ARRAY['one', 'two'])[k]);
    -- {one -> 1.0, two -> 1.4}
```

#### transform\_values()

**`transform_values(map(K,V1), function(K,V1,V2))`** → map(K,V2)

Returns a map that applies `function` to each entry of `map` and
transforms the values:

```sql theme={null}
    SELECT transform_values(MAP(ARRAY[], ARRAY[]), (k, v) -> v + 1);
    -- {}

    SELECT transform_values(MAP(ARRAY [1, 2, 3], ARRAY [10, 20, 30]),
                            (k, v) -> v + k);
    -- {1 -> 11, 2 -> 22, 3 -> 33}

    SELECT transform_values(MAP(ARRAY [1, 2, 3], ARRAY ['a', 'b', 'c']),
                            (k, v) -> k * k);
    -- {1 -> 1, 2 -> 4, 3 -> 9}

    SELECT transform_values(MAP(ARRAY ['a', 'b'], ARRAY [1, 2]),
                            (k, v) -> k || CAST(v as VARCHAR));
    -- {a -> a1, b -> b2}

    SELECT transform_values(MAP(ARRAY [1, 2], ARRAY [1.0, 1.4]),
                            (k, v) -> MAP(ARRAY[1, 2], ARRAY['one', 'two'])[k]
                              || '_' || CAST(v AS VARCHAR));
    -- {1 -> one_1.0, 2 -> two_1.4}
```


# Mathematical functions and operators
Source: https://docs.dune.com/query-engine/Functions-and-operators/math



# Mathematical operators

| Operator | Description                                     |
| -------- | ----------------------------------------------- |
| `+`      | Addition                                        |
| `-`      | Subtraction                                     |
| `*`      | Multiplication                                  |
| `/`      | Division (integer division performs truncation) |
| `%`      | Modulus (remainder)                             |

## Mathematical functions

#### abs()

**`abs(x)`** → same as input\
Returns the absolute value of `x`.

#### cbrt()

**`cbrt(x)`** → double\
Returns the cube root of `x`.

#### ceil()

**`ceil(x)`** → same as input\
This is an alias for `ceiling`.

#### ceiling()

**`ceiling(x)`** → same as input\
Returns `x` rounded up to the nearest integer.

#### degrees()

**`degrees(x)`** → double\
Converts angle `x` in radians to degrees.

#### e()

**`e()`** → double\
Returns the constant Euler's number.

#### exp()

**`exp(x)`** → double\
Returns Euler's number raised to the power of `x`.

#### floor()

**`floor(x)`** → same as input\
Returns `x` rounded down to the nearest integer.

#### ln()

**`ln(x)`** → double\
Returns the natural logarithm of `x`.

#### log()

**`log(b, x)`** → double\
Returns the base `b` logarithm of `x`.

#### log2()

**`log2(x)`** → double\
Returns the base 2 logarithm of `x`.

#### log10()

**`log10(x)`** → double\
Returns the base 10 logarithm of `x`.

#### mod()

**`mod(n, m)`** → same as input\
Returns the modulus (remainder) of `n` divided by `m`.

#### pi()

**`pi()`** → double\
Returns the constant Pi.

#### pow()

**`pow(x, p)`** → double\
This is an alias for `power`.

#### power()

**`power(x, p)`** → double\
Returns `x` raised to the power of `p`.

#### radians()

**`radians(x)`** → double\
Converts angle `x` in degrees to radians.

#### round()

**`round(x)`** → same as input\
Returns `x` rounded to the nearest integer.

#### round()

**`round(x, d)`** → same as input\
Returns `x` rounded to `d` decimal places.

#### sign()

**`sign(x)`** → same as input\
Returns the signum function of `x`, that is:

* 0 if the argument is 0,
* 1 if the argument is greater than 0,
* -1 if the argument is less than 0.
  For double arguments, the function additionally returns:
* NaN if the argument is NaN,
* 1 if the argument is +Infinity,
* -1 if the argument is -Infinity.

#### sqrt()

**`sqrt(x)`** → double\
Returns the square root of `x`.

#### truncate()

**`truncate(x)`** → double\
Returns `x` rounded to integer by dropping digits after decimal point.

#### width\_bucket()

**`width_bucket(x, bound1, bound2, n)`** → bigint\
Returns the bin number of `x` in an equi-width histogram with the specified `bound1` and `bound2` bounds and `n` number of buckets.

#### width\_bucket()

**`width_bucket(x, bins)`** → bigint\
Returns the bin number of `x` according to the bins specified by the array `bins`. The `bins` parameter must be an array of doubles and is assumed to be in sorted ascending order.

## Random functions

#### rand()

**`rand()`** → double\
This is an alias for `random()`.

#### random()

**`random()`** → double\
Returns a pseudo-random value in the range 0.0 \<= x \< 1.0.

#### random()

**`random(n)`** → same as input\
Returns a pseudo-random number between 0 and n (exclusive).

#### random()

**`random(m, n)`** → same as input\
Returns a pseudo-random number between m and n (exclusive).

## Trigonometric functions

All trigonometric function arguments are expressed in radians. See unit conversion functions `degrees` and `radians`.

#### acos()

**`acos(x)`** → double\
Returns the arc cosine of `x`.

#### asin()

**`asin(x)`** → double\
Returns the arc sine of `x`.

#### atan()

**`atan(x)`** → double\
Returns the arc tangent of `x`.

#### atan2()

**`atan2(y, x)`** → double\
Returns the arc tangent of `y / x`.

#### cos()

**`cos(x)`** → double\
Returns the cosine of `x`.

#### cosh()

**`cosh(x)`** → double\
Returns the hyperbolic cosine of `x`.

#### sin()

**`sin(x)`** → double\
Returns the sine of `x`.

#### tan()

**`tan(x)`** → double\
Returns the tangent of `x`.

#### sinh()

**`sinh(x)`** → double
Returns the hyperbolic sine of `x`.

#### tanh()

**`tanh(x)`** → double\
Returns the hyperbolic tangent of `x`.

## Floating point functions

#### infinity()

**`infinity()`** → double\
Returns the constant representing positive infinity.

#### is\_finite()

**`is_finite(x)`** → boolean\
Determine if `x` is finite.

#### is\_infinite()

**`is_infinite(x)`** → boolean\
Determine if `x` is infinite.

#### is\_nan()

**`is_nan(x)`** → boolean\
Determine if `x` is not-a-number.

#### nan()

**`nan()`** → double\
Returns the constant representing not-a-number.

## Base conversion functions

#### from\_base()

**`from_base(string, radix)`** → bigint\
Returns the value of `string` interpreted as a base-`radix` number.

#### to\_base()

**`to_base(x, radix)`** → varchar\
Returns the base-`radix` representation of `x`.

## Statistical functions

#### cosine\_similarity()

**`cosine_similarity(x, y)`** → double\
Returns the cosine similarity between the sparse vectors `x` and `y`:
SELECT cosine\_similarity(MAP(ARRAY\['a'], ARRAY\[1.0]), MAP(ARRAY\['a'], ARRAY\[2.0])); -- 1.0

#### wilson\_interval\_lower()

**`wilson_interval_lower(successes, trials, z)`** → double\
Returns the lower bound of the Wilson score interval of a Bernoulli
trial process at a confidence specified by the z-score `z`.

#### wilson\_interval\_upper()

**`wilson_interval_upper(successes, trials, z)`** → double\
Returns the upper bound of the Wilson score interval of a Bernoulli
trial process at a confidence specified by the z-score `z`.

## Cumulative distribution functions

#### beta\_cdf()

**`beta_cdf(a, b, v)`** → double\
Compute the Beta cdf with given a, b parameters: P(N \< v; a, b). The a,
b parameters must be positive real numbers and value v must be a real
value. The value v must lie on the interval \[0, 1].

#### inverse\_beta\_cdf()

**`inverse_beta_cdf(a, b, p)`** → double\
Compute the inverse of the Beta cdf with given a, b parameters for the
cumulative probability (p): P(N \< n). The a, b parameters must be
positive real values. The probability p must lie on the interval \[0,
1].

#### inverse\_normal\_cdf()

**`inverse_normal_cdf(mean, sd, p)`** → double\
Compute the inverse of the Normal cdf with given mean and standard

#### normal\_cdf()

**`normal_cdf(mean, sd, v)`** → double\
Compute the Normal cdf with given mean and standard deviation (sd): P(N
\< v; mean, sd). The mean and value v must be real values and the
standard deviation must be a real and positive value.


# Machine learning functions
Source: https://docs.dune.com/query-engine/Functions-and-operators/ml

Use SVM-based classifiers and regressors directly within DuneSQL.

The machine learning plugin provides machine learning functionality as
an aggregation function. It enables you to train Support Vector Machine
(SVM) based classifiers and regressors for the supervised learning
problems.

<Note>
  Note: The machine learning functions are not optimized for distributed
  processing. The capability to train large data sets is limited by this
  execution of the final training on a single instance.
</Note>

# Feature vector

To solve a problem with the machine learning technique, especially as a
supervised learning problem, it is necessary to represent the data set
with the sequence of pairs of labels and feature vector. A label is a
target value you want to predict from the unseen feature and a feature
is a A N-dimensional vector whose elements are numerical values. In
Trino, a feature vector is represented as a map-type value, whose key is
an index of each feature, so that it can express a sparse vector. Since
classifiers and regressors can recognize the map-type feature vector,
there is a function to construct the feature from the existing numerical
values, `features`:

```sql theme={null}
SELECT features(1.0, 2.0, 3.0) AS features;
```

Result:

| Features               |
| ---------------------- |
| \{0=1.0, 1=2.0, 2=3.0} |

The output from `features` can be directly passed to ML functions.

# Classification

Classification is a type of supervised learning problem to predict the
distinct label from the given feature vector. The interface looks
similar to the construction of the SVM model from the sequence of pairs
of labels and features implemented in Teradata Aster or [BigQuery
ML](https://cloud.google.com/bigquery/docs/bqml-introduction). The
function to train a classification model looks like as follows:

```sql theme={null}
    SELECT
      learn_classifier(
        species,
        features(sepal_length, sepal_width, petal_length, petal_width)
      ) AS model
    FROM
      iris
```

It returns the trained model in a serialized format.

```text theme={null}
model
-------------------------------------------------
3c 43 6c 61 73 73 69 66 69 65 72 28 76 61 72 63
68 61 72 29 3e
```

`classify` returns the predicted label by using the trained model. The trained model can not be saved natively,
and needs to be passed in the format of a nested query:

```sql theme={null}
    SELECT
      classify(features(5.9, 3, 5.1, 1.8), model) AS predicted_label
    FROM (
      SELECT
        learn_classifier(species, features(sepal_length, sepal_width, petal_length, petal_width)) AS model
      FROM
        iris
    ) t
```

```text theme={null}
predicted_label
-----------------
Iris-virginica
```

As a result you need to run the training process at the same time when
predicting values. Internally, the model is trained by
[libsvm](https://www.csie.ntu.edu.tw/~cjlin/libsvm/). You can use
`learn_libsvm_classifier` to control the
internal parameters of the model.

# Regression

Regression is another type of supervised learning problem, predicting
continuous value, unlike the classification problem. The target must be
numerical values that can be described as `double`.

The following code shows the creation of the model predicting
`sepal_length` from the other 3 features:

```sql theme={null}
    SELECT
      learn_regressor(sepal_length, features(sepal_width, petal_length, petal_width)) AS model
    FROM
      iris
```

The way to use the model is similar to the classification case:

```sql theme={null}
    SELECT
      regress(features(3, 5.1, 1.8), model) AS predicted_target
    FROM (
      SELECT
        learn_regressor(sepal_length, features(sepal_width, petal_length, petal_width)) AS model
      FROM iris
    ) t;
```

```text theme={null}
predicted_target
-------------------
6.407376822560477
```

Internally, the model is trained by
[libsvm](https://www.csie.ntu.edu.tw/~cjlin/libsvm/).
`learn_libsvm_regressor` provides you a
way to control the training process.

<h1>
  Machine learning functions \\
</h1>

#### features()

**`features(double, ...)`** → map(bigint, double)\
Returns the map representing the feature vector.

#### learn\_classifier()

**`learn_classifier(label, features)`** → Classifier

Returns an SVM-based classifier model, trained with the given label and
feature data sets.

#### learn\_libsvm\_classifier()

**`learn_libsvm_classifier(label, features, params)`** → Classifier

Returns an SVM-based classifier model, trained with the given label and
feature data sets. You can control the training process by libsvm
parameters.

#### classify()

**`classify(features, model)`** → label

Returns a label predicted by the given classifier SVM model.

#### learn\_regressor()

**`learn_regressor(target, features)`** → Regressor

Returns an SVM-based regressor model, trained with the given target and
feature data sets.

#### learn\_libsvm\_regressor()

**`learn_libsvm_regressor(target, features, params)`** → Regressor

Returns an SVM-based regressor model, trained with the given target and
feature data sets. You can control the training process by libsvm
parameters.

#### regress()

**`regress(features, model)`** → target

Returns a predicted target value by the given regressor SVM model.


# Quantile digest functions
Source: https://docs.dune.com/query-engine/Functions-and-operators/qdigest



# Data structures

A quantile digest is a data sketch which stores approximate percentile
information. The Trino type for this data structure is called `qdigest`,
and it takes a parameter which must be one of `bigint`, `double` or
`real` which represent the set of numbers that may be ingested by the
`qdigest`. They may be merged without losing precision, and for storage
and retrieval they may be cast to/from `VARBINARY`.

## Functions

#### merge()

**`merge(qdigest)`** → qdigest

Merges all input `qdigest`s into a single `qdigest`.

#### quantile\_at\_value()

**`quantile_at_value(qdigest(T), T)`** → quantile

Returns the approximate `quantile` number between 0 and 1 from the quantile digest given an input value. Null is returned if the quantile digest is empty or the input value is outside of the range of the quantile digest.

#### values\_at\_quantile()

**`value_at_quantile(qdigest(T), quantile)`** → T

Returns the approximate percentile value from the quantile digest given
the number `quantile` between 0 and 1.

#### values\_at\_quantiles()

**`values_at_quantiles(qdigest(T), quantiles)`** → array(T)

Returns the approximate percentile values as an array given the input
quantile digest and array of values between 0 and 1 which represent the
quantiles to return.

#### qdigest\_agg()

**`qdigest_agg(x)`** → qdigest(same as x)

Returns the `qdigest` which is composed of all input values of `x`.

#### qdigest\_agg()

**`qdigest_agg(x, w)`** → qdigest(same as x)

Returns the `qdigest` which is composed of all input values of `x` using
the per-item weight `w`.

#### qdigest\_agg()

**`qdigest_agg(x, w, accuracy)`** → qdigest(same as x)

Returns the `qdigest` which is composed of all input values of `x` using
the per-item weight `w` and maximum error of `accuracy`. `accuracy` must
be a value greater than zero and less than one, and it must be constant
for all input rows.


# Regular expression functions
Source: https://docs.dune.com/query-engine/Functions-and-operators/regexp



All of the regular expression functions use the [Java pattern]() syntax,
with a few notable exceptions:

* When using multi-line mode (enabled via the `(?m)` flag), only `\n`
  is recognized as a line terminator. Additionally, the `(?d)` flag is
  not supported and must not be used.
* Case-insensitive matching (enabled via the `(?i)` flag) is always
  performed in a Unicode-aware manner. However, context-sensitive and
  local-sensitive matching is not supported. Additionally, the `(?u)`
  flag is not supported and must not be used.
* Surrogate pairs are not supported. For example, `\uD800\uDC00` is
  not treated as `U+10000` and must be specified as `\x{10000}`.
* Boundaries (`\b`) are incorrectly handled for a non-spacing mark
  without a base character.
* `\Q` and `\E` are not supported in character classes (such as
  `[A-Z123]`) and are instead treated as literals.
* Unicode character classes (`\p{prop}`) are supported with the
  following differences:
  * All underscores in names must be removed. For example, use
    `OldItalic` instead of `Old_Italic`.
  * Scripts must be specified directly, without the `Is`, `script=`
    or `sc=` prefixes. Example: `\p{Hiragana}`
  * Blocks must be specified with the `In` prefix. The `block=` and
    `blk=` prefixes are not supported. Example: `\p{Mongolian}`
  * Categories must be specified directly, without the `Is`,
    `general_category=` or `gc=` prefixes. Example: `\p{L}`
  * Binary properties must be specified directly, without the `Is`.
    Example: `\p{NoncharacterCodePoint}`

#### regexp\_count()

**`regexp_count(string, pattern)`** → bigint

Returns the number of occurrence of `pattern` in `string`:

```sql theme={null}
    SELECT regexp_count('1a 2b 14m', '\s*[a-z]+\s*'); -- 3
```

#### regexp\_extract\_all()

**`regexp_extract_all(string, pattern)`** → array(varchar)

Returns the substring(s) matched by the regular expression `pattern` in
`string`:

```sql theme={null}
    SELECT regexp_extract_all('1a 2b 14m', '\d+'); -- [1, 2, 14]
```

**`regexp_extract_all(string, pattern, group)`** → array(varchar)

Finds all occurrences of the regular expression `pattern` in `string`
and returns the [capturing group number]() `group`:

```sql theme={null}
    SELECT regexp_extract_all('1a 2b 14m', '(\d+)([a-z]+)', 2); -- ['a', 'b', 'm']
```

#### regexp\_extract()

**`regexp_extract(string, pattern)`** → varchar

Returns the f substring matched by the regular expression `pattern`
in `string`:

```sql theme={null}
    SELECT regexp_extract('1a 2b 14m', '\d+'); -- 1
```

**`regexp_extract(string, pattern, group)`** → varchar

Finds the f occurrence of the regular expression `pattern` in
`string` and returns the [capturing group number]() `group`:

```sql theme={null}
    SELECT regexp_extract('1a 2b 14m', '(\d+)([a-z]+)', 2); -- 'a'
```

#### regexp\_like()

**`regexp_like(string, pattern)`** → boolean

Evaluates the regular expression `pattern` and determines if it is
contained within `string`.

The `pattern` only needs to be contained within `string`, rather than
needing to match all of `string`. In other words, this performs a
*contains* operation rather than a *match* operation. You can match the
entire string by anchoring the pattern using `^` and `$`:

```sql theme={null}
    SELECT regexp_like('1a 2b 14m', '\d+b'); -- true
```

#### regexp\_position()

**`regexp_position(string, pattern)`** → integer

Returns the index of the f occurrence (counting from 1) of `pattern`
in `string`. Returns -1 if not found:

```sql theme={null}
    SELECT regexp_position('I have 23 apples, 5 pears and 13 oranges', '\b\d+\b'); -- 8
```

**`regexp_position(string, pattern, start)`** → integer

Returns the index of the f occurrence of `pattern` in `string`,
starting from `start` (include `start`). Returns -1 if not found:

```sql theme={null}
    SELECT regexp_position('I have 23 apples, 5 pears and 13 oranges', '\b\d+\b', 5); -- 8
    SELECT regexp_position('I have 23 apples, 5 pears and 13 oranges', '\b\d+\b', 12); -- 19
```

**`regexp_position(string, pattern, start, occurrence)`** → integer

Returns the index of the nth `occurrence` of `pattern` in `string`,
starting from `start` (include `start`). Returns -1 if not found:

```sql theme={null}
    SELECT regexp_position('I have 23 apples, 5 pears and 13 oranges', '\b\d+\b', 12, 1); -- 19
    SELECT regexp_position('I have 23 apples, 5 pears and 13 oranges', '\b\d+\b', 12, 2); -- 31
    SELECT regexp_position('I have 23 apples, 5 pears and 13 oranges', '\b\d+\b', 12, 3);
```

#### regexp\_replace()

**`regexp_replace(string, pattern)`** → varchar

Removes every instance of the substring matched by the regular
expression `pattern` from `string`:

SELECT regexp\_replace('1a 2b 14m', '\d+\[ab] '); -- '14m'

**`regexp_replace(string, pattern, replacement)`** → varchar

Replaces every instance of the substring matched by the regular
expression `pattern` in `string` with `replacement`. [Capturing
groups]() can be referenced in `replacement` using `$g` for a numbered
group or `${name}` for a named group. A dollar sign (`$`) may be
included in the replacement by escaping it with a backslash (`\$`):

```sql theme={null}
    SELECT regexp_replace('1a 2b 14m', '(\d+)([ab]) ', '3c$2 '); -- '3ca 3cb 14m'
```

**`regexp_replace(string, pattern, function)`** → varchar

Replaces every instance of the substring matched by the regular
expression `pattern` in `string` using `function`. The
`lambda expression <lambda>` function is
invoked for each match with the [capturing groups]() passed as an array.
Capturing group numbers start at one; there is no group for the entire
match (if you need this, surround the entire expression with
parenthesis). :

SELECT regexp\_replace('new york', '(\w)(\w\*)', x -> upper(x\[1]) || lower(x\[2])); --'New York'

#### regexp\_split()

**`regexp_split(string, pattern)`** → array(varchar)

Splits `string` using the regular expression `pattern` and returns an
array. Trailing empty strings are preserved:

```sql theme={null}
    SELECT regexp_split('1a 2b 14m', '\s*[a-z]+\s*'); -- [1, 2, 14, ]
```


# Set Digest functions
Source: https://docs.dune.com/query-engine/Functions-and-operators/setdigest

Functions for computing set digests and HyperLogLog structures.

## Set Digest functions

Trino offers several functions that deal with the
[MinHash](https://en.wikipedia.org/wiki/MinHash) technique.

MinHash is used to quickly estimate the [Jaccard similarity
coefficient](https://en.wikipedia.org/wiki/Jaccard_index) between two
sets.

It is commonly used in data mining to detect near-duplicate web pages at
scale. By using this information, the search engines efficiently avoid
showing within the search results two pages that are nearly identical.

The following example showcases how the Set Digest functions can be used
to naively estimate the similarity between texts. The input texts are
split by using the function `ngrams` to
[4-shingles](https://en.wikipedia.org/wiki/W-shingling) which are used
as input for creating a set digest of each initial text. The set digests
are compared to each other to get an approximation of the similarity of
their corresponding initial texts:

```sql theme={null}
WITH text_input(id, text) AS (
         VALUES
             (1, 'The quick brown fox jumps over the lazy dog'),
             (2, 'The quick and the lazy'),
             (3, 'The quick brown fox jumps over the dog')
     ),
     text_ngrams(id, ngrams) AS (
         SELECT id,
                transform(
                  ngrams(
                    split(text, ' '),
                    4
                  ),
                  token -> array_join(token, ' ')
                )
         FROM text_input
     ),
     minhash_digest(id, digest) AS (
         SELECT id,
                (SELECT make_set_digest(v) FROM unnest(ngrams) u(v))
         FROM text_ngrams
     ),
     setdigest_side_by_side(id1, digest1, id2, digest2) AS (
         SELECT m1.id as id1,
                m1.digest as digest1,
                m2.id as id2,
                m2.digest as digest2
         FROM (SELECT id, digest FROM minhash_digest) m1
         JOIN (SELECT id, digest FROM minhash_digest) m2
           ON m1.id != m2.id AND m1.id < m2.id
     )
SELECT id1,
       id2,
       intersection_cardinality(digest1, digest2) AS intersection_cardinality,
       jaccard_index(digest1, digest2)            AS jaccard_index
FROM setdigest_side_by_side
ORDER BY id1, id2;
```

Results:

| id1 | id2 | intersection\_cardinality | jaccard\_index |
| --- | --- | ------------------------- | -------------- |
| 1   | 2   | 0                         | 0.0            |
| 1   | 3   | 4                         | 0.6            |
| 2   | 3   | 0                         | 0.0            |

The above result listing points out, as expected, that the texts with
the id 1 and 3 are quite similar.

One may argue that the text with the id 2 is somewhat similar to the
texts with the id 1 and 3. Due to the fact in the example above
4-shingles are taken into account for measuring the similarity of the
texts, there are no intersections found for the text pairs 1 and 2,
respectively 3 and 2 and therefore there the similarity index for
these text pairs is 0.

## Data structures

Trino implements Set Digest data sketches by encapsulating the following
components:

* [HyperLogLog](https://en.wikipedia.org/wiki/HyperLogLog)
* [MinHash with a single hash
  function](http://en.wikipedia.org/wiki/MinHash#Variant_with_a_single_hash_function)

The HyperLogLog structure is used for the approximation of the distinct
elements in the original set.

The MinHash structure is used to store a low memory footprint signature
of the original set. The similarity of any two sets is estimated by
comparing their signatures.

The Trino type for this data structure is called `setdigest`. Trino
offers the ability to merge multiple Set Digest data sketches.

## Serialization

Data sketches can be serialized to and deserialized from `varbinary`.
This allows them to be stored for later use.

## Functions

#### make\_set\_digest()

**`make_set_digest(x)`** → setdigest

Composes all input values of `x` into a `setdigest`.

Create a `setdigest` corresponding to a `bigint` array:

```sql theme={null}
    SELECT make_set_digest(value)
    FROM (VALUES 1, 2, 3) T(value);
```

Create a `setdigest` corresponding to a `varchar` array:

SELECT make\_set\_digest(value)
FROM (VALUES 'Trino', 'SQL', 'on', 'everything') T(value);

#### merge\_set\_digest()

**`merge_set_digest(setdigest, setdigest)`** → setdigest

Returns the `setdigest` of the aggregate union of the individual
`setdigest` Set Digest structures.

Returns the cardinality of the set digest from its internal
`HyperLogLog` component.

Examples:

```sql theme={null}
    SELECT cardinality(make_set_digest(value))
    FROM (VALUES 1, 2, 2, 3, 3, 3, 4, 4, 4, 4, 5) T(value);
    -- 5
```

#### intersection\_cardinality()

**`intersection_cardinality(x,y)`** → long

Returns the estimation for the cardinality of the intersection of the
two set digests.

`x` and `y` must be of type `setdigest`

Examples:

```sql theme={null}
    SELECT intersection_cardinality(make_set_digest(v1), make_set_digest(v2))
    FROM (VALUES (1, 1), (NULL, 2), (2, 3), (3, 4)) T(v1, v2);
    -- 3
```

#### jaccard\_index()

**`jaccard_index(x, y)`** → double

Returns the estimation of [Jaccard
index](https://en.wikipedia.org/wiki/Jaccard_index) for the two set
digests.

`x` and `y` must be of type `setdigest`.

Examples:

```sql theme={null}
    SELECT jaccard_index(make_set_digest(v1), make_set_digest(v2))
    FROM (VALUES (1, 1), (NULL,2), (2, 3), (NULL, 4)) T(v1, v2);
    -- 0.5
```

#### hash\_counts()

**`hash_counts(x)`** → map(bigint, bigint)

Returns a map containing the
[Murmur3Hash128](https://en.wikipedia.org/wiki/MurmurHash#MurmurHash3)
hashed values and the count of their occurrences within the internal
`MinHash` structure belonging to `x`.

`x` must be of type `setdigest`.

Examples:

```sql theme={null}
    SELECT hash_counts(make_set_digest(value))
    FROM (VALUES 1, 1, 1, 2, 2) T(value);
    -- {19144387141682250=3, -2447670524089286488=2}
```


# SS58 functions
Source: https://docs.dune.com/query-engine/Functions-and-operators/ss58

Explanation of the SS58 address encoding scheme used in Substrate chains.

ss58 or substrate58 is an address encoding scheme that is commonly used in substrate-based chains. It is similar to [Base58](/query-engine/Functions-and-operators/base58) encoding format, with some modifications.

Under basic ss58 encoding format an address can be encoded as:

```
base58encode ( concat ( <address-type>, <address>, <checksum> ) )
```

## Functions

#### from\_ss58()

**`from_ss58(varchar)`** → `varbinary`

Converts an ss58-encoded string to the corresponding `VARBINARY` address.

```sql theme={null}
SELECT 
    from_ss58('1qnJN7FViy3HZaxZK9tGAA71zxHSBeUweirKqCaox4t8GT7')
-- results in VARBINARY 0x2534454d30f8a028e42654d6b535e0651d1d026ddf115cef59ae1dd71bae074e
```

#### to\_ss58()

**`to_ss58(varbinary, int)`** → `varchar`

Encodes an address of a specific network type into its ss58 `VARCHAR` representation. For example:

* `Polkadot` has address type 0
* `Kusama` has address type 2
* `Generic Substrate` has address type 42

```sql theme={null}
SELECT 
    to_ss58('0x2534454d30f8a028e42654d6b535e0651d1d026ddf115cef59ae1dd71bae074e', 2)
-- results 'DR6pMC4GJiVbgPtNNuw1xgxJyEsYYuXKXq7ZCVBjfFrh3V5'
```


# String functions and operators
Source: https://docs.dune.com/query-engine/Functions-and-operators/string



## String operators

The `||` operator performs concatenation.

The `LIKE` statement can be used for pattern matching and is documented
in `like_operator`.

## String functions

<tip>
  Note
  These functions assume that the input strings contain valid UTF-8 encoded Unicode code points. There are no explicit checks for valid UTF-8, and the functions may return incorrect results on invalid UTF-8. Invalid UTF-8 data can be corrected with from\_utf8.

  Additionally, the functions operate on Unicode code points and not user-visible characters (or grapheme clusters). Some     languages combine multiple code points into a single user-perceived character, the basic unit of a writing system for a     language, but the functions will treat each code point as a separate unit.

  The lower and upper functions do not perform locale-sensitive, context-sensitive, or one-to-many mappings required for some     languages. Specifically, this will return incorrect results for Lithuanian, Turkish, and Azeri.
</tip>

#### chr()

**`chr(n)`** → varchar\
Returns the Unicode code point `n` as a single character string.

#### codepoint()

**`codepoint(string)`** → integer\
Returns the Unicode code point of the only character of `string`.

#### concat()

**`concat(string1, ..., stringN)`** → varchar\
Returns the concatenation of `string1`, `string2`, `...`, `stringN`. This function provides the same functionality as the SQL-standard concatenation operator (`||`).

#### concat\_ws()

**`concat_ws(string0, string1, ..., stringN)`** → varchar\
Returns the concatenation of `string1`, `string2`, `...`, `stringN` using `string0` as a separator. If `string0` is null, then the return value is null. Any null values provided in the arguments after the separator are skipped.

#### concat\_ws()

**`concat_ws(string0, array(varchar))`** → varchar\
Returns the concatenation of elements in the array using `string0` as a separator. If `string0` is null, then the return value is null. Any null values in the array are skipped.

#### format()

**`format(format, args...)`** → varchar\
See `format`.

#### hamming\_distance()

**`hamming_distance(string1, string2)`** → bigint\
Returns the Hamming distance of `string1` and `string2`, i.e. the number of positions at which the corresponding characters are different. Note that the two strings must have the same length.

#### length()

**`length(string)`** → bigint\
Returns the length of `string` in characters.

#### levenshtein\_distance()

**`levenshtein_distance(string1, string2)`** → bigint\
Returns the Levenshtein edit distance of `string1` and `string2`, i.e. the minimum number of single-character edits (insertions, deletions or substitutions) needed to change `string1` into `string2`.

#### lower()

**`lower(string)`** → varchar\
Converts `string` to lowercase.

#### lpad()

**`lpad(string, size, padstring)`** → varchar\
Left pads `string` to `size` characters with `padstring`. If `size` is less than the length of `string`, the result is truncated to `size` characters. `size` must not be negative and `padstring` must be non-empty.

#### ltrim()

**`ltrim(string)`** → varchar\
Removes leading whitespace from `string`.

#### luhn\_check()

**`luhn_check(string)`** → boolean\
Tests whether a `string` of digits is valid according to the [Luhn algorithm](https://en.wikipedia.org/wiki/Luhn_algorithm).
This checksum function, also known as `modulo 10` or `mod 10`, is widely applied on credit card numbers and government identification numbers to distinguish valid numbers from mistyped, incorrect numbers.

Valid identification number:

select luhn\_check('79927398713');
\-- true

Invalid identification number:

select luhn\_check('79927398714');
\-- false

#### position()

**`position(substring IN string)`** → bigint

Returns the starting position of the first instance of `substring` in `string`. Positions start with `1`. If not found, `0` is returned.

Note: This SQL-standard function has special syntax and uses the `IN` keyword for the arguments. See also `strpos`.

#### replace()

**`replace(string, search)`** → varchar

Removes all instances of `search` from `string`.

**`replace(string, search, replace)`** → varchar

Replaces all instances of `search` with `replace` in `string`.

#### reverse()

**`reverse(string)`** → varchar

Returns `string` with the characters

#### rpad()

**`rpad(string, size, padstring)`** → varchar

Right pads `string` to `size` characters with `padstring`. If `size` is less than the length of `string`, the result is truncated to `size` characters. `size` must not be negative and `padstring` must be non-empty.

#### rtrim()

**`rtrim(string)`** → varchar

Removes trailing whitespace from `string`.

#### soundex()

**`soundex(char)`** → string

`soundex` returns a character string containing the phonetic representation of `char`.

It is typically used to evaluate the similarity of two expressions phonetically, that is how the string sounds when spoken:

```sql theme={null}
    SELECT name
    FROM nation
    WHERE SOUNDEX(name)  = SOUNDEX('CHYNA');
```

```text theme={null}
     name  |
    -------+----
     CHINA |
    (1 row)
```

#### split()

**`split(string, delimiter)`** → array(varchar)

Splits `string` on `delimiter` and returns an array.

#### split()

**`split(string, delimiter, limit)`** → array(varchar)

Splits `string` on `delimiter` and returns an array of size at most `limit`. The last element in the array always contain everything left in the `string`. `limit` must be a positive number.

#### split\_part()

**`split_part(string, delimiter, index)`** → varchar

Splits `string` on `delimiter` and returns the field `index`. Field indexes start with `1`. If the index is larger than the number of fields, then null is returned.

#### split\_to\_map()

**`split_to_map(string, entryDelimiter, keyValueDelimiter)`** → map(varchar, varchar)

Splits `string` by `entryDelimiter` and `keyValueDelimiter` and returns a map. `entryDelimiter` splits `string` into key-value pairs. `keyValueDelimiter` splits each pair into key and value.

#### split\_to\_multimap()

**`split_to_multimap(string, entryDelimiter, keyValueDelimiter)`** → map(varchar, array(varchar))

Splits `string` by `entryDelimiter` and `keyValueDelimiter` and returns a map containing an array of values for each unique key. `entryDelimiter` splits `string` into key-value pairs. `keyValueDelimiter` splits each pair into key and value. The values for each key will be in the same order as they appeared in `string`.

#### strpos()

**`strpos(string, substring)`** → bigint

Returns the starting position of the first instance of `substring` in `string`. Positions start with `1`. If not found, `0` is returned.

**`strpos(string, substring, instance)`** → bigint

Returns the position of the N-th `instance` of `substring` in `string`. When `instance` is a negative number the search will start from the end of `string`. Positions start with `1`. If not found, `0` is returned.

#### starts\_with()

**`starts_with(string, substring)`** → boolean

Tests whether `substring` is a prefix of `string`.

#### substring()

**`substr(string, start)`** → varchar

This is an alias for `substring`.

**`substring(string, start)`** → varchar

Returns the rest of `string` from the starting position `start`. Positions start with `1`. A negative starting position is interpreted as being relative to the end of the string.

**`substr(string, start, length)`** → varchar

This is an alias for `substring`.

**`substring(string, start, length)`** → varchar

Returns a substring from `string` of length `length` from the starting position `start`. Positions start with `1`. A negative starting position is interpreted as being relative to the end of the string.

#### translate()

**`translate(source, from, to)`** → varchar

Returns the `source` string translated by replacing characters found in the

**`translate(source, from, to)`** → varchar

Returns the `source` string translated by replacing characters found in the `from` string with the corresponding characters in the `to` string. If the `from` string contains duplicates, only the first is used. If the `source` character does not exist in the `from` string, the `source` character will be copied without translation. If the index of the matching character in the `from` string is beyond the length of the `to` string, the `source` character will be omitted from the resulting string.

Here are some examples illustrating the translate function:

```sql theme={null}
    SELECT translate('abcd', '', ''); -- 'abcd'
    SELECT translate('abcd', 'a', 'z'); -- 'zbcd'
    SELECT translate('abcda', 'a', 'z'); -- 'zbcdz'
    SELECT translate('Palhoça', 'ç','c'); -- 'Palhoca'
    SELECT translate('abcd', 'b', U&'\+01F600'); -- a😀cd
    SELECT translate('abcd', 'a', ''); -- 'bcd'
    SELECT translate('abcd', 'a', 'zy'); -- 'zbcd'
    SELECT translate('abcd', 'ac', 'z'); -- 'zbd'
    SELECT translate('abcd', 'aac', 'zq'); -- 'zbd'
```

#### trim()

**`trim(string)`** → varchar

Removes leading and trailing whitespace from `string`.

**`trim( \[ \[ specification \] \[ string \] FROM \] source )`** → varchar

Removes any leading and/or trailing characters as specified up to and including `string` from `source`:

```sql theme={null}
    SELECT trim('!' FROM '!foo!'); -- 'foo'
    SELECT trim(LEADING FROM '  abcd');  -- 'abcd'
    SELECT trim(BOTH '$' FROM '$var$'); -- 'var'
    SELECT trim(TRAILING 'ER' FROM upper('worker')); -- 'WORK'
```

#### upper()

**`upper(string)`** → varchar

Converts `string` to uppercase.

#### word\_stem()

**`word_stem(word)`** → varchar

Returns the stem of `word` in the English language.

**`word_stem(word, lang)`** → varchar

Returns the stem of `word` in the `lang` language.

## Unicode functions

#### keccak()

**`keccak(varbinary)`** → varbinary

Returns the Keccak-256 hash of `varbinary`.

```sql theme={null}
    SELECT keccak(to_utf8('Transfer(address,address,uint256)')) --0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef
```

#### normalize()

**`normalize(string)`** → varchar

Transforms `string` with NFC normalization form.

**`normalize(string, form)`** → varchar

Transforms `string` with the specified normalization form. `form` must be one of the following keywords:

| Form   | Description                                                    |
| ------ | -------------------------------------------------------------- |
| `NFD`  | Canonical Decomposition                                        |
| `NFC`  | Canonical Decomposition, followed by Canonical Composition     |
| `NFKD` | Compatibility Decomposition                                    |
| `NFKC` | Compatibility Decomposition, followed by Canonical Composition |

<tip> This SQL-standard function has special syntax and requires specifying `form` as a keyword, not as a string. </tip>

#### to\_utf8()

**`to_utf8(string)`** → varbinary

Encodes `string` into a UTF-8 varbinary representation.

```sql theme={null}
    SELECT to_utf8('Hello, world!'); -- 0x48656C6C6F2C20776F726C6421
    Select keccak(to_utf8('Transfer(address,address,uint256)')) --0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef 
```

#### from\_utf8()

**`from_utf8(binary)`** → varchar

Decodes a UTF-8 encoded string from `binary`. Invalid UTF-8 sequences are replaced with the Unicode replacement character `U+FFFD`.

**`from_utf8(binary, replace)`** → varchar

Decodes a UTF-8 encoded string from `binary`. Invalid UTF-8 sequences are replaced with `replace`. The replacement string `replace` must either be a single character or empty (in which case invalid characters are removed).


# System information
Source: https://docs.dune.com/query-engine/Functions-and-operators/system



## System information

Functions providing information about the Trino cluster system environment. More information is available by querying the various schemas and tables exposed by the `/connector/system`.

## Function

**`version()`** -> varchar

Returns the Trino version used on the cluster. Equivalent to the value of the `node_version` column in the `system.runtime.nodes` table.


# T-Digest functions
Source: https://docs.dune.com/query-engine/Functions-and-operators/tdigest



## Data structures

A T-digest is a data sketch which stores approximate percentile
information. The Trino type for this data structure is called `tdigest`.
T-digests can be merged, and for storage and retrieval they can be cast
to and from `VARBINARY`.

## Functions

#### merge()

**`merge(tdigest)`** → tdigest

Aggregates all inputs into a single `tdigest`.

#### values\_at\_quantile()

**`value_at_quantile(tdigest, quantile)`** → double

Returns the approximate percentile value from the T-digest, given the number `quantile` between 0 and 1.

#### values\_at\_quantiles()

**`values_at_quantiles(tdigest, quantiles)`** → array(double)

Returns the approximate percentile values as an array, given the input T-digest and an array of values between 0 and 1, which represent the quantiles to return.

#### tdigest\_agg()

**`tdigest_agg(x)`** → tdigest

Composes all input values of `x` into a `tdigest`. `x` can be of any numeric type.

**`tdigest_agg(x, w)`** → tdigest

Composes all input values of `x` into a `tdigest` using the per-item weight `w`. `w` must be greater or equal than 1. `x` and `w` can be of any numeric type.


# Teradata functions
Source: https://docs.dune.com/query-engine/Functions-and-operators/teradata



These functions provide compatibility with Teradata SQL.

## String functions

#### char2()

**`char2hexint(string)`** → varchar

Returns the hexadecimal representation of the UTF-16BE encoding of the string.

#### index()

**`index(string, substring)`** → bigint

Alias for `strpos` function.

## Date functions

The functions in this section use a format string that is compatible
with the Teradata datetime functions. The following table, based on the
Teradata reference manual, describes the supported format specifiers:

| Specifier   | Description                        |
| ----------- | ---------------------------------- |
| - / , . ; : | Punctuation characters are ignored |
| dd          | Day of month (1-31)                |
| hh          | Hour of day (1-12)                 |
| hh24        | Hour of the day (0-23)             |
| mi          | Minute (0-59)                      |
| mm          | Month (01-12)                      |
| ss          | Second (0-59)                      |
| yyyy        | 4-digit year                       |
| yy          | 2-digit year                       |

<tip>  Case insensitivity is not currently supported. All specifiers must be lowercase. </tip>

#### to\_char()

**`to_char(timestamp, format)`** → varchar

Formats `timestamp` as a string using `format`.

#### to\_timestamp()

**`to_timestamp(string, format)`** → timestamp

Parses `string` into a `TIMESTAMP` using `format`.

#### to\_date()

**`to_date(string, format)`** → date

Parses `string` into a `DATE` using `format`.


# TON address functions
Source: https://docs.dune.com/query-engine/Functions-and-operators/tonaddress

Helpers for encoding and decoding TON blockchain addresses.

Smart contract addresses on the TON blockchain are composed of two key components:

1. Workchain Identifier. A signed 8-bit number that identifies the workchain. Currently, only the masterchain (workchain\_id = -1) and occasionally the basic workchain (workchain\_id = 0) are active on the TON blockchain.
2. Account Identifier. A 256-bit number unique to each account within a workchain.

There are two different representation of contract addresses on TON blockchain:

* Raw addresses: Original full representation of smart contract addresses. Raw smart contract addresses consist of a workchain ID and account ID and are displayed in the following format: `<decimal workchain_id>:<64 hexadecimal digits with account_id>`. Example: `-1:fcb91a3a3816d0f7b8c2c76108b8a9bc5a6b7a55bd79f8ab101c52db29232260`.
* User-friendly addresses: An enhanced version of raw address designed to improve security and usability. User-friendly addresses were developed to secure and simplify the experience for TON users who share addresses on the internet (for example, on public messaging platforms or via their email service providers), as well as in the real world. User-friendly addresses are made up of 36 bytes in total.

We provide functions to translate between the two formats.

## Functions

#### ton\_address\_raw\_to\_user\_friendly()

**`ton_address_raw_to_user_friendly(varchar, boolean)`** → `varchar`

Converts a raw address to its user-friendly equivalent. The second argument is a boolean flag that specifies whether the bounceable flag is enabled (true) or disabled (false). If omitted, the bounceable flag defaults to true.

```sql theme={null}
SELECT 
    ton_address_raw_to_user_friendly('0:ca6e321c7cce9ecedf0a8ca2492ec8592494aa5fb5ce0387dff96ef6af982a3e', true)
-- results 'EQDKbjIcfM6ezt8KjKJJLshZJJSqX7XOA4ff-W72r5gqPrHF'
```

#### ton\_address\_user\_friendly\_to\_raw()

**`ton_address_user_friendly_to_raw(varchar)`** → `varchar`

Converts a user-friendly address back to its raw representation.

```sql theme={null}
SELECT 
    ton_address_user_friendly_to_raw('UQDKbjIcfM6ezt8KjKJJLshZJJSqX7XOA4ff-W72r5gqPuwA')
-- results '0:ca6e321c7cce9ecedf0a8ca2492ec8592494aa5fb5ce0387dff96ef6af982a3e'
```


# Tron address functions
Source: https://docs.dune.com/query-engine/Functions-and-operators/tronaddress

Utilities for working with TRON's custom address format.

Tron blockchain adopted a custom type of addresses. It is similar to [Base58](/query-engine/Functions-and-operators/base58) encoding format, with some modifications.

Under basic tron address encoding format an address can be encoded as:

```
base58encode ( concat ( <constant-prefix>, <address>, <checksum> ) )
```

## Functions

#### from\_tron\_address()

**`from_tron_address(varchar)`** → `varbinary`

Converts a Tron address string to the corresponding `VARBINARY` hex address.

```sql theme={null}
SELECT 
    from_tron_address('THHRK1bA7YRPZBcLnTP1SZy9ipUpsRwpo6')
-- results in VARBINARY 0x503aa4ad108bd3a89ba0310e23b49fb654cd6986
```

#### to\_tron\_address()

**`to_tron_address(varbinary)`** → `varchar`

Encodes a `VARBINARY` hex address to the corresponding Tron address.

```sql theme={null}
SELECT 
    to_tron_address(0x503aa4ad108bd3a89ba0310e23b49fb654cd6986)
-- results 'THHRK1bA7YRPZBcLnTP1SZy9ipUpsRwpo6'
```


# URL functions
Source: https://docs.dune.com/query-engine/Functions-and-operators/url



## Extraction functions

The URL extraction functions extract components from HTTP URLs (or any
valid URIs conforming to `2396`). The following syntax is supported:

```text theme={null}
[protocol:][//host[:port]][path][?query][#fragment]
```

The extracted components do not contain URI syntax separators such as
`:` or `?`.

#### url\_extract\_fragment()

**`url_extract_fragment(url)`** → varchar

Returns the fragment identifier from `url`.

#### url\_extract\_host()

**`url_extract_host(url)`** → varchar

Returns the host from `url`.

#### url\_extract\_parameter()

**`url_extract_parameter(url, name)`** → varchar

Returns the value of the f query string parameter named `name` from `url`. Parameter extraction is handled in the typical manner as specified by RFC 1866#section-8.2.1.

#### url\_extract\_path()

**`url_extract_path(url)`** → varchar

Returns the path from `url`.

#### url\_extract\_port()

**`url_extract_port(url)`** → bigint

Returns the port number from `url`.

#### url\_extract\_protocol()

**`url_extract_protocol(url)`** → varchar

Returns the protocol from `url`.

#### url\_extract\_query()

**`url_extract_query(url)`** → varchar

Returns the query string from `url`.

## Encoding functions

#### url\_encode()

**`url_encode(value)`** → varchar

Escapes `value` by encoding it so that it can be safely included in URL query parameter names and values.

#### url\_decode()

**`url_decode(value)`** → varchar

Unescapes the URL encoded `value`. This function is the inverse of `url_encode`.


# UUID functions
Source: https://docs.dune.com/query-engine/Functions-and-operators/uuid



**`uuid()`** → uuid

Returns a pseudo randomly generated `uuid_type`(type 4).


# Varbinary functions (DuneSQL)
Source: https://docs.dune.com/query-engine/Functions-and-operators/varbinary



## Varbinary Functions

Dune SQL represents varbinarys using the varbinary type.

To make it simpler to work with varbinarys we have the following helper functions, which work with these two kinds of representation. They simplify interactions with varbinarys, as they automatically account for the `0x`-prefix and use byte index instead of character index. For instance, the varbinary\_substring methods take indexes by byte, not by character (twice the varbinary length).

You can use these function to extract data from undecoded events logs, or calldata. For instance, if you have a function that takes a `uint256` as an argument, you can use `varbinary_to_uint256` to extract the value from the calldata. You'll oftentimes need to use `varbinary_substring` to extract the correct part of the calldata or use other bytearray manipulation functions to get the correct value.

```sql theme={null}
select tx_hash,
       data,
       varbinary_substring(data,97,32) as fee,
       varbinary_to_uint256(varbinary_substring(data,97,32)) as fee_uint256
from optimism.logs
where contract_address = 0xa1ace9ce6862e865937939005b1a6c5ac938a11f
and topic0 = 0xc9d5ada2ea384fe04826ecd1b258955ac73c3e2e20d755108eafde90bc5588d4
-- sample transaction hash
and tx_hash IN (0x3e3c558e7f723e3bb7de1d8f5f920ca206e3e878984296a2b8e6af2969003a19,
                0xccfd2033adfb1fdd14fdfc047fe554ba7549e396abc6c559e9528a4259295b89)
```

<tip> Varbinary functions were previously called byte array functions. You might find e.g. `bytearray_to_uint256` in some of our older queries. These functions are identical to the varbinary functions and work as aliases. </tip>

## Varbinary to Numeric Functions

The varbinary conversion functions throw an overflow exception if the varbinary is larger than the number of bytes supported of the type, even if the most significant bytes are all zero. It is possible to use `varbinary_ltrim` in order to trim the zero bytes from the left.

[Here is a dashboard](https://dune.com/dune/dune-sql-byte-array-functions-uint256-int256-support) with examples covering all of the below functions. For a more comprehensive look at all special DuneSQL functions, use this [dashboard](https://dune.com/cryptuschrist/dunesql-functions) from [cryptuschrist](https://dune.com/cryptuschrist).

#### varbinary\_to\_integer()

**`varbinary_to_integer(varbinary)`** → integer

Returns the `INTEGER` value of a big-endian varbinary of length \<= 4 representing the integer in two's complement. If the varbinary has length \< 4 it is padded with zero bytes.

```sql theme={null}
-- convert bytearray to integer [result will be either 1 or 0]
-- if 1 = true, 0 = false
SELECT tx_hash,
       varbinary_to_integer(varbinary_ltrim(varbinary_substring(data,1,32))) as isQuote_number,
       CASE WHEN  varbinary_to_integer(varbinary_ltrim(varbinary_substring(data,1,32))) = 1 THEN TRUE ELSE FALSE END AS isQuote
FROM arbitrum.logs
WHERE contract_address = 0xdaf4ffb05bfcb2c328c19135e3e74e1182c88283
AND topic0 = 0xf1bc206c8d659bf05edd19865dbae82643062168ec3970d9d7c5468f900487d9
LIMIT 10
```

#### varbinary\_to\_bigint()

**`varbinary_to_bigint(varbinary)`** → bigint

Returns the `BIGINT` value of a big-endian varbinary of length \<= 8 representing the bigint in two's complement. If the varbinary has length \< 8 it is padded with zero bytes.

```sql theme={null}
-- convert bytearray to integer [result will be either 1 or 0]
-- if 1 = true, 0 = false
SELECT tx_hash,
       varbinary_to_bigint(varbinary_ltrim(varbinary_substring(data,1,32))) as isQuote_number,
       CASE WHEN  varbinary_to_bigint(varbinary_ltrim(varbinary_substring(data,1,32))) = 1 THEN TRUE ELSE FALSE END AS isQuote
FROM arbitrum.logs
WHERE contract_address = 0xdaf4ffb05bfcb2c328c19135e3e74e1182c88283
AND topic0 = 0xf1bc206c8d659bf05edd19865dbae82643062168ec3970d9d7c5468f900487d9
LIMIT 10
```

#### varbinary\_to\_decimal()

**`varbinary_to_decimal(varbinary)`** → decimal(38,0)

Returns the `DECIMAL(38,0)` value of a big-endian varbinary of length \<= 16 representing the decimal(38,0) in two's complement. If the varbinary has length \< 16 it is padded with zero bytes.

```sql theme={null}
-- using raw table to get usdc transfers amount
-- transfer topic0 = 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef
-- usdc contract_address = 0xaf88d065e77c8cc2239327c5edb3a432268e5831
SELECT tx_hash,
       data,
       varbinary_to_decimal(varbinary_ltrim(data)) as data_decimal
FROM arbitrum.logs
WHERE topic0 = 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef
AND contract_address = 0xaf88d065e77c8cc2239327c5edb3a432268e5831
AND block_time >= NOW() - interval '1' day
LIMIT 50
```

#### varbinary\_to\_uint256()

**`varbinary_to_uint256(varbinary)`** → uint256

Returns the `UINT256` of a big-endian varbinary of length \<= 32 representing the unsigned integer. If the varbinary has length \< 32 it is padded with zero bytes.

```sql theme={null}
select tx_hash,
       data,
       varbinary_substring(data,97,32) as fee,
       varbinary_to_uint256(varbinary_substring(data,97,32)) as fee_uint256
from optimism.logs
where contract_address = 0xa1ace9ce6862e865937939005b1a6c5ac938a11f
and topic0 = 0xc9d5ada2ea384fe04826ecd1b258955ac73c3e2e20d755108eafde90bc5588d4
-- sample transaction hash
and tx_hash IN (0x3e3c558e7f723e3bb7de1d8f5f920ca206e3e878984296a2b8e6af2969003a19,
                0xccfd2033adfb1fdd14fdfc047fe554ba7549e396abc6c559e9528a4259295b89)
```

#### varbinary\_to\_int256()

**`varbinary_to_int256(varbinary)`** → int256

Returns the `INT256` of a big-endian varbinary of length \<= 32 representing the signed integer. If the varbinary has length \< 32 it is padded with zero bytes.

```sql theme={null}
select tx_hash,
       data,
       varbinary_substring(data,65,32) as sizeDelta,
       varbinary_to_int256(varbinary_substring(data,65,32)) as sizeDelta_int256
from optimism.logs
where contract_address = 0xa1ace9ce6862e865937939005b1a6c5ac938a11f
and topic0 = 0xc9d5ada2ea384fe04826ecd1b258955ac73c3e2e20d755108eafde90bc5588d4
-- sample transaction hash
and tx_hash IN (0x3e3c558e7f723e3bb7de1d8f5f920ca206e3e878984296a2b8e6af2969003a19,
                0xccfd2033adfb1fdd14fdfc047fe554ba7549e396abc6c559e9528a4259295b89)
```

#### bytea2numeric()

**`bytea2numeric(varbinary)`** → bigint

This function has been deprecated. It is an alias for `varbinary_to_bigint`.

## Numeric to Varbinary

#### Converting uint256 to varbinary

**`varbinary_ltrim(cast(uint256 as varbinary))`** → varbinary

Converts a uint256 type number into varbinary.

```sql theme={null}
select varbinary_ltrim(
        cast(UINT256 '101691398105299641525402875323276528467270701520' as varbinary)
    ) as vb
```

## Varbinary to text

#### from\_utf8()

**`from_utf8(varbinary)`** → varchar

Converts a varbinary to a string using the UTF-8 encoding.

```sql theme={null}
Select from_utf8(0x48656c6c6f20576f726c64)
-- returns "Hello World"
```

most commonly will have to be used like this:

```sql theme={null}
Select from_utf8(varbinary_ltrim(0x0000000000000000006e66746e657264732e6169))
```

## Text to varbinary

#### from\_hex()

**`from_hex(varchar)`** → varbinary

Converts a varbinary expression in datatype `string` to `varbinary` datatype

```sql theme={null}
Select from_hex('0x6574686275696c646572')
-- returns VARBINARY 0x6574686275696c646572
```

<Warning> You **cannot** use `cast(x as varbinary)` in these cases as it will actually encode the string as varbinary which is different from converting the expression to `varbinary`.  </Warning>

## Varbinary Manipulation Functions

#### varbinary\_concat()

**`varbinary_concat(varbinary, varbinary)`** → varbinary

Concatenates two varbinarys or strings.

```sql theme={null}
SELECT varbinary_concat(0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2,
                        0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48)
```

**`varbinary_concat(varchar, varchar)`** → varchar

Concatenates two varbinarys or strings.

```sql theme={null}
-- concatenate varchar
-- using typeof to check the datatype
SELECT varbinary_concat('0xabcd', '0x00ab') as varbinary_varchar_concat,
       typeof(varbinary_concat('0xabcd', '0x00ab')) as varbinary_varchar_type

```

#### varbinary\_length()

**`varbinary_length(varbinary)`** → bigint

Returns the length of a varbinary.

```sql theme={null}
 -- this will return 20
SELECT varbinary_length(0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2)
```

**`varbinary_length(varchar)`** → bigint

Returns the length of a string.

```sql theme={null}
 -- this will return 20
SELECT typeof('0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2') as data_type,
       varbinary_length('0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2') varchar_length
```

#### varbinary\_ltrim()

**`varbinary_ltrim(varbinary)`** → varbinary

Removes zero bytes or spaces from the beginning of a varbinary

```sql theme={null}
 -- this will remove the zeros at the front,
 -- returning 0xa2b80f9c09558945800ddf4f8786dcc8b1c44974
SELECT varbinary_ltrim(0x000000000000000000000000a2b80f9c09558945800ddf4f8786dcc8b1c44974)
```

**`varbinary_ltrim(varchar)`** → varchar

Removes spaces from the beginning of a string.

```sql theme={null}
 -- this will remove the zeros at the front,
 -- returning 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2
SELECT typeof('0x0000000000000000000000000000000000000000c02aaa39b223fe8d0a0e5c4f27ead9083c756cc2') as data_type,
       varbinary_ltrim('0x0000000000000000000000000000000000000000c02aaa39b223fe8d0a0e5c4f27ead9083c756cc2') varchar_ltrim
```

#### varbinary\_rtrim()

**`varbinary_rtrim(varbinary) or varbinary_rtrim(varchar)`** → varbinary or varchar

Removes zero bytes or spaces from the end of a varbinary or string.

```sql theme={null}
 -- this will remove the zeros at the end,
 -- returning 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2
SELECT varbinary_ltrim(0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc20000000000000000000000000000000000000000)
```

#### varbinary\_position()

**`varbinary_position(varbinary, varbinary)`** → bigint

Returns the index of the first occurrence of a given bytearray or string (or 0 if not found) within a varbinary or string.

```sql theme={null}

-- get $ARKM claimers 
SELECT * FROM ethereum.transactions
WHERE block_time >= TIMESTAMP '2023-07-17' -- claim start date
AND varbinary_position(data,0x3d13f874) = 1 -- 0x3d13f874 is the methodID
AND success
LIMIT 100

```

**`varbinary_position(varchar, varchar)`** → bigint

Returns the index of the first occurrence of a given bytearray or string (or 0 if not found) within a varbinary or string.

```sql theme={null}
-- search for '0x6cc2' and return its position
SELECT varbinary_position('0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2','0x6cc2') 
```

#### varbinary\_replace()

**`varbinary_replace(varbinary, varbinary, varbinary)`** → varbinary

Greedily replaces occurrences of a pattern within a varbinary.

```sql theme={null}

-- replacing the blackhole address (ETH)
-- to WETH address
SELECT varbinary_replace(0x0000000000000000000000000000000000000000,
                         0x0000000000000000000000000000000000000000,
                         0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2)  
```

**`varbinary_replace(varchar, varchar, varchar)`** → varchar

Greedily replaces occurrences of a pattern within a string.

```sql theme={null}

SELECT varbinary_replace('0x0000000000000000000000000000000000000000a2b80f9c09558945800ddf4f8786dcc8b1c44974',
                         '0x0000000000000000000000000000000000000000',
                         '0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2')  
```

#### varbinary\_reverse()

**`varbinary_reverse(varbinary)`** → varbinary

Reverses a given varbinary.

```sql theme={null}

SELECT varbinary_reverse(0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2)
```

**`varbinary_reverse(varchar)`** → varchar

Reverses a given string.

```sql theme={null}
-- '0xabcdef' as original
-- '0xefcdab' as reversed
SELECT '0xabcdef' as original,
       varbinary_reverse('0xabcdef') as reversed
```

#### varbinary\_starts\_with()

**`varbinary_starts_with(varbinary, varbinary)`** → boolean

Determines whether a varbinary starts with a prefix.

```sql theme={null}

-- get $ARKM claimers 
-- varbinary_starts_with checks whether 
-- data starts with 0x3d13f874 (claim methodID)
SELECT * FROM ethereum.transactions
WHERE block_time >= TIMESTAMP '2023-07-17'
AND varbinary_starts_with(data,0x3d13f874) -- returns true if starts with 0x3d13f874
AND success
LIMIT 100

```

**`varbinary_starts_with(varbinary, varbinary)`** → boolean

Determines whether a varbinary starts with a prefix.

```sql theme={null}
-- returns true if starts with 0x3d13f874
SELECT varbinary_starts_with(0x3d13f874abcd,0x3d13f874) 

```

#### varbinary\_substring()

**`varbinary_substring(varbinary, integer)`** → varbinary

Returns a suffix varbinary or string starting at a given index.

```sql theme={null}
-- using varbinary_substring starting from the 21th index
-- this returns 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 
SELECT 0x0000000000000000000000000000000000000000c02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 as original_bytearray,
       varbinary_substring(0x0000000000000000000000000000000000000000c02aaa39b223fe8d0a0e5c4f27ead9083c756cc2,21) as bytearraysubstring_data
```

Returns a subvarbinary of a given length starting at an index.

```sql theme={null}
-- getting the sizeDelta using varbinary_substring
-- and converting to uint256 using varbinary_to_uint256
SELECT tx_hash,
       varbinary_substring(data,65,32) as sizeDelta,
       varbinary_to_uint256(varbinary_substring(data,65,32)) as sizeDelta_uint256
FROM optimism.logs
WHERE contract_address = 0xa1ace9ce6862e865937939005b1a6c5ac938a11f
AND topic0 = 0xc9d5ada2ea384fe04826ecd1b258955ac73c3e2e20d755108eafde90bc5588d4
-- some sample transaction hash
AND tx_hash IN (0x3e3c558e7f723e3bb7de1d8f5f920ca206e3e878984296a2b8e6af2969003a19, 
                0xccfd2033adfb1fdd14fdfc047fe554ba7549e396abc6c559e9528a4259295b89) 
```

**`varbinary_substring(varbinary, integer, integer)`** → varbinary

Returns a subvarbinary of a given length starting at an index. Be aware that the length is in bytes, not characters.

```sql theme={null}
-- returns  0xabcdef
SELECT 0xabcdefabcdef as varbinary_data,
       varbinary_substring(0xabcdefabcdef,1,3) as varbinary_substring
```

#### keccak()

**`keccak(varbinary)`** → varbinary

Returns the Keccak-256 hash of `varbinary`.

```sql theme={null}
    SELECT keccak(to_utf8('Transfer(address,address,uint256)')) --0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef
```


# Varchar Utility Functions
Source: https://docs.dune.com/query-engine/Functions-and-operators/varchar-utility-functions

Reference guide to string helper functions in Dune SQL.

# Varchar Utility Functions

Dune SQL offers a series of functions designed to ease some common tasks when working with varchar data.

#### left()

**`left(varchar, bigint)`** → varchar

This function returns the leftmost `x` characters from a string, if `x` is less than or equal to 0 the result is an empty string. The first argument is the original string, and the second argument is `x`, the length of the resulting string.

```sql theme={null}
SELECT 
    "left"('123456', 2)
```

will return `12`

#### right()

**`right(varchar, bigint)`** → varchar

This function returns the rightmost `x` characters from a string, if `x` is less than or equal to 0 the result is an empty string. The first argument is the original string, and the second argument is `x`, the length of the resulting string.

```sql theme={null}
SELECT 
    "right"('123456', 2)
```

will return `56`

#### initcap()

**`initcap(varchar)`** → varchar

This function returns a string with the first letter of each word in uppercase and all other letters in lowercase. Words are delimited by white space or characters that are not alphanumeric. The only argument is the original string.

```sql theme={null}
SELECT 
    "initcap"('hellO woRld')
```

will return `Hello World`

#### address\_32\_from\_hex()

**`address_32_from_hex(varchar)`** → varbinary

This function converts a hexadecimal-formatted input string to varbinary, always producing an output of 32 bytes in length by left-padding with the 0x00 byte. The input string needs to be hexadecimal formatted, allowing characters from `[a-fA-F0-9]`; otherwise, an error is returned. While the input can be prefixed with '0x', this is not mandatory. The function accommodates the hexadecimal representation of any decimal number, provided it fits within 32 bytes.

This function proves useful in scenarios where addresses in the Aptos chain are utilized. In the Aptos chain, addresses serve as 32-byte identifiers for accounts or objects. All addresses in Aptos chain are represented as just that, using a 32-byte varbinary. However, it's quite common to represent addresses in their short-formed representation, having leading zeros trimmed. For example, a valid aptos account can have a 0x1 address. Additionally, it's typical to encounter the short format without the '0x' prefix. Therefore, this function serves to transform a short-form address into the internal representation format used for addresses

```sql theme={null}
-- The following query will return: true, true, true
SELECT
    address_32_from_hex('0x1') = address_32_from_hex('0x01'),
    address_32_from_hex('0x1') = address_32_from_hex('1'),
    address_32_from_hex('0x1') = 0x0000000000000000000000000000000000000000000000000000000000000001
```

In the aptos context, we can use the function to find transactions with the entry function address being 0x1.

```sql theme={null}
SELECT * FROM aptos.user_transactions WHERE entry_function_module_address = address_32_from_hex('0x1') LIMIT 10
```


# Window functions
Source: https://docs.dune.com/query-engine/Functions-and-operators/window

Documentation for ranking and analytic window functions.

## Window functions

Window functions perform calculations across rows of the query result.
They run after the `HAVING` clause but before the `ORDER BY` clause.
Invoking a window function requires special syntax using the `OVER`
clause to specify the window. For example, the following query ranks
orders for each clerk by price:

```sql theme={null}
    SELECT orderkey, clerk, totalprice,
           rank() OVER (PARTITION BY clerk
                        ORDER BY totalprice DESC) AS rnk
    FROM orders
    ORDER BY clerk, rnk
```

The window can be specified in two ways (see
`window_clause`):

* By a reference to a named window specification defined in the
  `WINDOW` clause,
* By an in-line window specification which allows to define window
  components as well as refer to the window components pre-defined in
  the `WINDOW` clause.

## Aggregate functions

All `aggregate` can be used as window functions by adding the `OVER` clause. The aggregate function is
computed for each row over the rows within the current row's window
frame.

For example, the following query produces a rolling sum of order prices
by day for each clerk:

```sql theme={null}
    SELECT clerk, orderdate, orderkey, totalprice,
           sum(totalprice) OVER (PARTITION BY clerk
                                 ORDER BY orderdate) AS rolling_sum
    FROM orders
    ORDER BY clerk, orderdate, orderkey
```

## Ranking functions

#### cume\_dist()

**cume\_dist()** → bigint

Returns the cumulative distribution of a value in a group of values. The
result is the number of rows preceding or peer with the row in the
window ordering of the window partition divided by the total number of
rows in the window partition. Thus, any tie values in the ordering will
evaluate to the same distribution value.

#### dense\_rank()

**dense\_rank()** → bigint

Returns the rank of a value in a group of values. This is similar to `rank`, except that tie values do not produce gaps in the sequence.

#### ntile()

**ntile(n)** → bigint

Divides the rows for each window partition into `n` buckets ranging from `1` to at most `n`. Bucket values will differ by at most `1`. If the number of rows in the partition does not divide evenly into the number of buckets, then the remainder values are distributed one per bucket, starting with the first bucket.

For example, with `6` rows and `4` buckets, the bucket values would be as follows: `1` `1` `2` `2` `3` `4`

#### percent\_rank()

**percent\_rank()** → double

Returns the percentage ranking of a value in group of values. The result is `(r - 1) / (n - 1)` where `r` is the `rank` of the row and `n` is the total number of rows in the window partition.

#### rank()

**rank()** → bigint

Returns the rank of a value in a group of values. The rank is one plus the number of rows preceding the row that are not peer with the row. Thus, tie values in the ordering will produce gaps in the sequence. The ranking is performed for each window partition.

#### row\_number()

**row\_number()** → bigint

Returns a unique, sequential number for each row, starting with one, according to the ordering of rows within the window partition.

## Value functions

By default, null values are respected. If `IGNORE NULLS` is specified,
all rows where `x` is null are excluded from the calculation. If
`IGNORE NULLS` is specified and `x` is null for all rows, the
`default_value` is returned, or if it is not specified, `null` is
returned.

#### first\_value()

**first\_value(x)** → \[same as input]

Returns the first value of the window.

#### last\_value()

**last\_value(x)** → \[same as input]

Returns the last value of the window.

#### nth\_value()

**nth\_value(x, offset)** → \[same as input]

Returns the value at the specified offset from the beginning of the window. Offsets start at `1`. The offset can be any scalar expression. If the offset is null or greater than the number of values in the window, `null` is returned. It is an error for the offset to be zero or negative.

#### lead()

**lead(x, offset , default\_value)** → \[same as input]

Returns the value at `offset` rows after the current row in the window partition. Offsets start at `0`, which is the current row. The offset can be any scalar expression. The default `offset` is `1`. If the offset is null, `null` is returned. If the offset refers to a row that is not within the partition, the `default_value` is returned, or if it is not specified `null` is returned. The `lead` function requires that the window ordering be specified. Window frame must not be specified.

#### lag()

**lag(x, offset , default\_value)** → \[same as input]

Returns the value at `offset` rows before the current row in the window partition. Offsets start at `0`, which is the current row. The offset can be any scalar expression. The default `offset` is `1`. If the offset is null, `null` is returned. If the offset refers to a row that is not within the partition, the `default_value` is returned, or if it is not specified `null` is returned. The `lag` function requires that the window ordering be specified. Window frame must not be specified.


# Datatypes
Source: https://docs.dune.com/query-engine/datatypes

Overview of the data types supported in DuneSQL.

DuneSQL has a set of built-in data types, described below.

Implicit Conversion and Casting to other datatypes is described in [the conversion function documentation](/query-engine/Functions-and-operators/conversion).

## Boolean

### `BOOLEAN`

This type captures boolean values `true` and `false`.

## Binary

### `VARBINARY`

Variable length binary data. In Dune, we store addresses, hashes, calldata and logs as `varbinary` data types.

SQL statements support usage of binary data with the prefix `0x`. The
binary data has to use hexadecimal format. For example, the binary form
of `eh?` is `X'65683F'`.

We have built custom functions to make it easier to work with varbinaries in DuneSQL. Check the [varbinary functions](/query-engine/Functions-and-operators/varbinary) page for more information.

## Integer

### `TINYINT`

A 8-bit signed two's complement integer with a minimum value of `-2^7`
and a maximum value of `2^7 - 1`.

### `SMALLINT`

A 16-bit signed two's complement integer with a minimum value of
`-2^15` and a maximum value of `2^15 - 1`.

### `INTEGER`

A 32-bit signed two's complement integer with a minimum value of
`-2^31` and a maximum value of `2^31 - 1`. The name `INT` is also
available for this type.

### `BIGINT`

A 64-bit signed two's complement integer with a minimum value of
`-2^63` and a maximum value of `2^63 - 1`.

### `UINT256` (Dune SQL)

A 256-bit unsigned integer with a minimum value of 0 and a maximum value of 2^256 - 1. This data type can represent only non-negative integers, including very large positive integers, as well as zero. Since there is no sign bit, all 256 bits can be used to represent the magnitude of the number. This data type is commonly used in EVM smart contracts to represent balances and other quantities.

### `INT256` (Dune SQL)

A 256-bit signed two's complement integer with a minimum value of -2^255 and a maximum value of 2^255 - 1. This data type can represent a wide range of values, including very large negative and positive integers, as well as zero.

This data type is commonly used in EVM smart contracts to represent balances and other quantities, more specifically when the value can be negative.

## Floating-point

### `REAL`

A real is a 32-bit inexact, variable-precision implementing the IEEE
Standard 754 for Binary Floating-Point Arithmetic.

Example literals: `REAL '10.3'`, `REAL '10.3e0'`, `REAL '1.03e1'`

### `DOUBLE`

A double is a 64-bit inexact, variable-precision implementing the IEEE
Standard 754 for Binary Floating-Point Arithmetic.

Example literals: `DOUBLE '10.3'`, `DOUBLE '1.03e1'`, `10.3e0`, `1.03e1`

## Fixed-precision

### `DECIMAL`

A fixed precision decimal number. Precision up to 38 digits is supported
but performance is best up to 18 digits.

The decimal type takes two literal parameters:

* **precision** - total number of digits
* **scale** - number of digits in fractional part. Scale is optional
  and defaults to 0.

Example type definitions: `DECIMAL(10,3)`, `DECIMAL(20)`

Example literals: `DECIMAL '10.3'`, `DECIMAL '1234567890'`, `1.1`

## String

### `VARCHAR`

Variable length character data with an optional maximum length.

Example type definitions: `varchar`, `varchar(20)`

SQL statements support simple literal, as well as Unicode usage:

* literal string : `'Hello winter !'`
* Unicode string with default escape character:
  `U&'Hello winter \2603 !'`
* Unicode string with custom escape character:
  `U&'Hello winter #2603 !' UESCAPE '#'`

A Unicode string is prefixed with `U&` and requires an escape character
before any Unicode character usage with 4 digits. In the examples above
`\2603` and `#2603` represent a snowman character. Long Unicode codes
with 6 digits require usage of the plus symbol before the code. For
example, you need to use `\+01F600` for a grinning face emoji.

### `CHAR`

Fixed length character data. A `CHAR` type without length specified has
a default length of 1. A `CHAR(x)` value always has `x` characters. For
example, casting `dog` to `CHAR(7)` adds 4 implicit trailing spaces.
Leading and trailing spaces are included in comparisons of `CHAR`
values. As a result, two character values with different lengths
(`CHAR(x)` and `CHAR(y)` where `x != y`) will never be equal.

Example type definitions: `char`, `char(20)`

```sql theme={null}
    Select * from ethereum.transactions where "from" = 0xc8ebccc5f5689fa8659d83713341e5ad19349448
```

### `JSON`

JSON value type, which can be a JSON object, a JSON array, a JSON
number, a JSON string, `true`, `false` or `null`.

## Date and time

See also [`date and time functions`](/query-engine/Functions-and-operators/datetime).

### `DATE`

Calendar date (year, month, day).

Example: `DATE '2001-08-22'`

### `TIME`

`TIME` is an alias for `TIME(3)` (millisecond precision).

### `TIME(P)`

Time of day (hour, minute, second) without a time zone with `P` digits
of precision for the fraction of seconds. A precision of up to 12
(picoseconds) is supported.

Example: `TIME '01:02:03.456'`

### `TIME WITH TIME ZONE`

Time of day (hour, minute, second, millisecond) with a time zone. Values
of this type are rendered using the time zone from the value. Time zones
are expressed as the numeric UTC offset value:

```sql theme={null}
    SELECT TIME '01:02:03.456 -08:00';
    -- 1:02:03.456-08:00
```

### `TIMESTAMP`

`TIMESTAMP` is an alias for `TIMESTAMP(3)` (millisecond precision).

### `TIMESTAMP(P)`

Calendar date and time of day without a time zone with `P` digits of
precision for the fraction of seconds. A precision of up to 12
(picoseconds) is supported. This type is effectively a combination of
the `DATE` and `TIME(P)` types.

`TIMESTAMP(P) WITHOUT TIME ZONE` is an equivalent name.

Timestamp values can be constructed with the `TIMESTAMP` literal
expression. Alternatively, language constructs such as
`localtimestamp(p)`, or a number of \`date and time functions and
operators can
return timestamp values.

Casting to lower precision causes the value to be rounded, and not
truncated. Casting to higher precision appends zeros for the additional
digits.

The following examples illustrate the behavior:

```sql theme={null}
    SELECT TIMESTAMP '2020-06-10 15:55:23';
    -- 2020-06-10 15:55:23

    SELECT TIMESTAMP '2020-06-10 15:55:23.383345';
    -- 2020-06-10 15:55:23.383345

    SELECT typeof(TIMESTAMP '2020-06-10 15:55:23.383345');
    -- timestamp(6)

    SELECT cast(TIMESTAMP '2020-06-10 15:55:23.383345' as TIMESTAMP(1));
     -- 2020-06-10 15:55:23.4

    SELECT cast(TIMESTAMP '2020-06-10 15:55:23.383345' as TIMESTAMP(12));
    -- 2020-06-10 15:55:23.383345000000
```

<h3>
  `TIMESTAMP WITH TIME ZONE` \\
</h3>

`TIMESTAMP WITH TIME ZONE` is an alias for `TIMESTAMP(3) WITH TIME ZONE`
(millisecond precision).

### `TIMESTAMP(P) WITH TIME ZONE`

Instant in time that includes the date and time of day with `P` digits
of precision for the fraction of seconds and with a time zone. Values of
this type are rendered using the time zone from the value. Time zones
can be expressed in the following ways:

* `UTC`, with `GMT`, `Z`, or `UT` usable as aliases for UTC.
* `+hh:mm` or `-hh:mm` with `hh:mm` as an hour and minute offset from
  UTC. Can be written with or without `UTC`, `GMT`, or `UT` as an
  alias for UTC.
* An [IANA time zone name](https://www.iana.org/time-zones).

The following examples demonstrate some of these syntax options:

```sql theme={null}
    SELECT TIMESTAMP '2001-08-22 03:04:05.321 UTC';
    -- 2001-08-22 03:04:05.321 UTC

    SELECT TIMESTAMP '2001-08-22 03:04:05.321 -08:30';
    -- 2001-08-22 03:04:05.321 -08:30

    SELECT TIMESTAMP '2001-08-22 03:04:05.321 GMT-08:30';
    -- 2001-08-22 03:04:05.321 -08:30

    SELECT TIMESTAMP '2001-08-22 03:04:05.321 America/New_York';
    -- 2001-08-22 03:04:05.321 America/New_York
```

### `INTERVAL YEAR TO MONTH`

Span of years and months.

Example: `INTERVAL '3' MONTH`

### `INTERVAL DAY TO SECOND`

Span of days, hours, minutes, seconds and milliseconds.

Example: `INTERVAL '2' DAY`

## Structural

### `ARRAY`

An array of the given component type.

Example: `ARRAY[1, 2, 3]`

### `MAP`

A map between the given component types.

Example: `MAP(ARRAY['foo', 'bar'], ARRAY[1, 2])`

### `ROW`

A structure made up of fields that allows mixed types. The fields may be
of any SQL type.

By default, row fields are not named, but names can be assigned.

Example: `CAST(ROW(1, 2e0) AS ROW(x BIGINT, y DOUBLE))`

Named row fields are accessed with field reference operator (`.`).

Example: `CAST(ROW(1, 2.0) AS ROW(x BIGINT, y DOUBLE)).x`

Named or unnamed row fields are accessed by position with the subscript
operator (`[]`). The position starts at `1` and must be a constant.

Example: `ROW(1, 2.0)[1]`

## Network address

### `IPADDRESS`

An IP address that can represent either an IPv4 or IPv6 address.
Internally, the type is a pure IPv6 address. Support for IPv4 is handled
using the *IPv4-mapped IPv6 address* range
(`4291#section-2.5.5.2`). When creating an
`IPADDRESS`, IPv4 addresses will be mapped into that range. When
formatting an `IPADDRESS`, any address within the mapped range will be
formatted as an IPv4 address. Other addresses will be formatted as IPv6
using the canonical format defined in `5952`.

Examples: `IPADDRESS '10.0.0.1'`, `IPADDRESS '2001:db8::1'`

## UUID

### `UUID`

This type represents a UUID (Universally Unique IDentifier), also known
as a GUID (Globally Unique IDentifier), using the format defined in
`4122`\\

Example: `UUID '12151fd2-7586-11e9-8f9e-2a86e4085a59'`

## HyperLogLog

Calculating the approximate distinct count can be done much more cheaply
than an exact count using the
[HyperLogLog](https://en.wikipedia.org/wiki/HyperLogLog) data sketch.

### `HyperLogLog`

A HyperLogLog sketch allows efficient computation of `approx_distinct`. It starts as a sparse
representation, switching to a dense representation when it becomes more
efficient.

### `P4HyperLogLog`

A P4HyperLogLog sketch is similar to `hyperloglog_type`, but it starts (and remains) in the dense representation.

## SetDigest

### `SetDigest`

A SetDigest (setdigest) is a data sketch structure used in calculating
[Jaccard similarity
coefficient](https://en.wikipedia.org/wiki/Jaccard_index) between two
sets.

SetDigest encapsulates the following components:

* [HyperLogLog](https://en.wikipedia.org/wiki/HyperLogLog)
* [MinHash with a single hash
  function](http://en.wikipedia.org/wiki/MinHash#Variant_with_a_single_hash_function)

The HyperLogLog structure is used for the approximation of the distinct
elements in the original set.

The MinHash structure is used to store a low memory footprint signature
of the original set. The similarity of any two sets is estimated by
comparing their signatures.

SetDigests are additive, meaning they can be merged together.

## Quantile digest

### `QDigest`

A quantile digest (qdigest) is a summary structure which captures the
approximate distribution of data for a given input set, and can be
queried to retrieve approximate quantile values from the distribution.
The level of accuracy for a qdigest is tunable, allowing for more
precise results at the expense of space.

A qdigest can be used to give approximate answer to queries asking for
what value belongs at a certain quantile. A useful property of qdigests
is that they are additive, meaning they can be merged together without
losing precision.

A qdigest may be helpful whenever the partial results of
`approx_percentile` can be reused. For example, one may be interested in
a daily reading of the 99th percentile values that are read over the
course of a week. Instead of calculating the past week of data with
`approx_percentile`, `qdigest`s could be stored daily, and quickly
merged to retrieve the 99th percentile value.

## T-Digest

### `TDigest`

A T-digest (tdigest) is a summary structure which, similarly to qdigest,
captures the approximate distribution of data for a given input set. It
can be queried to retrieve approximate quantile values from the
distribution.

TDigest has the following advantages compared to QDigest:

* higher performance
* lower memory usage
* higher accuracy at high and low percentiles

T-digests are additive, meaning they can be merged together.


# DuneSQL Architecture
Source: https://docs.dune.com/query-engine/dunesql-architecture

Understand how DuneSQL's query engine works.

**DuneSQL is built on a sophisticated architecture designed for handling blockchain data at scale. Understanding this architecture helps you write more efficient queries and get the most out of the system.**

DuneSQL is a Trino-based query engine designed for handling data stored in a columnar format. More specifically, we use Parquet files as the underlying storage format, with Delta Lake providing additional capabilities for data management and versioning.
This architecture allows for efficient data access and query processing, as well as fast data loading and data compression.

## Database Fundamentals

At their core, databases are sophisticated systems designed to store, retrieve, and manage data. Their primary goal is to provide fast, efficient, and reliable access to vast amounts of structured information. You can think of a database as a collection of tables, where each table is a collection of rows and columns. Conceptually, these tables exist in two ways:

* **Logical**: The logical view of a table is the way the data is organized and presented to the user. This is the view you see when you query a table.
* **Physical**: The physical view of a table is the way the data is stored on disk. This is the view you see when you look at the underlying files that make up the table.

Databases are designed to optimize for the logical view of a table, which is the view that users interact with. However, the physical view of a table is also important, as it determines how the data is stored and accessed. In order to optimize the usability of the logical view of a table, databases use a variety of techniques to optimize the physical view of a table. These techniques include:

* **Data partitioning**: Data partitioning is a technique that divides data into smaller chunks called partitions. This reduces the amount of data that needs to be stored and accessed, which improves performance.
* **Data indexing**: Data indexing is a technique that creates a data structure called an index. This data structure contains information about the data in a table, which allows the database to quickly find the data it needs.
* **Data storage layout**: Data storage layout relates to how the data is stored on disk. This includes the file format, how the data is physically stored on disk, and how the data is organized in memory. The right data storage layout can significantly improve performance.
* **Data compression**: Data compression is a technique that reduces the size of data by removing redundant information. This reduces the amount of data that needs to be stored and accessed, which improves performance.
* **Data caching**: Data caching is a technique that stores frequently accessed data in memory. This reduces the amount of data that needs to be stored and accessed, which improves performance.

For the most part, these techniques are employed in the background and are not visible to the user. However, understanding how **data partitioning**, **data indexing** and the **data storage layout** work is essential for understanding how DuneSQL works.

Databases employ these techniques to combat their most significant challenge: **the I/O bound nature of data storage**. I/O bound refers to the fact that the speed of data access is limited by the speed of the storage device. Read speed, the time it takes to load data from storage to memory, is an essential constraint of databases.

Every time you query a table, the database needs to read the data from disk into memory. This happens in a unit called a page. Pages are the smallest unit of data that can be read from disk into memory. Since reading pages from disk is slow, databases try to minimize the number of pages that need to be read into memory when querying a table. This is where data partitioning and data indexing come into play.

**To quickly summarize:** The goal of a database is to provide fast, efficient, and reliable access to vast amounts of structured information. In the end, we want to access the logical view of a table as quickly as possible. To do this, database administrators use a variety of techniques to optimize the physical view of a table. These techniques include data partitioning, data indexing, data compression, and data caching. The goal of these techniques is to minimize the number of pages that need to be read into memory when querying a table.

## DuneSQL Storage Architecture

Dune stores data in Parquet files, which are first and foremost columnar storage files, but also utilize some of the advantages of row-oriented storage. Data in Parquet systems is partitioned by rows into multiple Parquet files, and within each file, the data is further partitioned into row groups. However, the pages inside of row groups store data in columns rather than rows. As a result, the database appears row-oriented at a higher level, but it reads data from column-oriented pages when accessing specific values.

Additionally, each Parquet file contains metadata about the data it stores, mainly **min/max** column statistics for each column. This allows the database to efficiently skip entire Parquet files or row groups within files while scanning through a table, provided that the column contains values that are not random and can be ordered.

<Frame>
  <img />
</Frame>

<Frame>
  <img />
</Frame>

What's important to understand here is that the traditional index structure of a database is not needed in DuneSQL. Instead, the `min/max` values of each column are used to efficiently skip entire Parquet files or row groups within files while scanning through a table, provided that the column contains values that are not random and can be ordered. This is a key difference between DuneSQL and other databases like Snowflake.

## Query Processing in DuneSQL

If you query a table in DuneSQL, the system will access the data in the following order:

1. **File Level:** At the foundational level, the query engine locates the specific Parquet files associated with the table or a portion of the table being queried. It reads the metadata contained in the footer of each Parquet file to determine whether it might contain the data needed for the query. It will skip any files that do not contain the data needed for the query.

2. **Row Group Level:** Once the appropriate Parquet file is identified, the engine will access the relevant row groups within the file, based on the query conditions. Again, it will first read the metadata of each row group to determine whether it might contain the data needed for the query. If the row group does not contain the data needed for the query, it will skip the row group and move on to the next one.

3. **Column Chunk Level:** Once the appropriate row group is identified, the system will access the relevant column chunks within the row group, based on the query conditions. The column chunks contain the actual data that is needed for the query. The database will only read the column chunks that contain the data needed for the query. It will not read the logical row - saving time and resources.

4. **Page Level:** Within the column chunk, the data is further segmented into pages. The database reads these pages into memory, benefiting from any compression or encoding optimizations.

During this process the engine starts stream processing from the first chunks of data it has read. It will optimize on the fly: based on the data it has already read, it can resign from reading other data if that data is recognized as irrelevant. This is called dynamic filtering and will usually save a lot of resources.

If the query is too large to be processed in memory, the data will "spill" from memory to disk. This is called "spill to disk" and is a common occurrence in databases. This will negatively impact query performance, as reading data from disk is much slower than reading data from memory.

## Delta Lake Integration

DuneSQL also leverages Delta Lake for additional data management capabilities. Delta Lake provides:

* **ACID transactions**: Ensures data consistency and reliability
* **Schema evolution**: Allows tables to evolve over time without breaking existing queries
* **Time travel**: Enables querying historical versions of data
* **Upserts and deletes**: Supports more complex data operations than traditional Parquet files
* **Data versioning**: Maintains a complete history of changes to the data

The combination of Parquet's columnar storage format with Delta Lake's data management capabilities provides DuneSQL with both high performance and data reliability features essential for blockchain data processing.

## Time Partitioning

DuneSQL leverages time-based partitioning extensively, as blockchain data is inherently time-ordered. Most tables are partitioned by:

* **Block time**: The timestamp when a block was mined
* **Block date**: The date component of block time (often more efficient for queries)
* **Block number**: The sequential number of the block

This partitioning strategy allows the query engine to quickly identify and skip irrelevant time periods, dramatically reducing the amount of data that needs to be processed for time-based queries.

## Columnar Storage Benefits

The columnar storage format provides several key advantages for blockchain data:

* **Compression**: Similar data types in columns compress very well, reducing storage requirements
* **Selective column reading**: Only the columns needed for a query are read from disk
* **Vectorized processing**: Operations can be performed on entire columns at once
* **Better cache utilization**: Related data is stored together, improving memory access patterns

## Notable Exceptions

A notable exception to the general rule of using sequentially ordered columns is the Solana dataset `account_activity`, which is ordered by `account_keys` rather than `block_time`. This allows for utilizing the min/max values for `account_keys` when building queries based on raw Solana data.

This architecture makes DuneSQL particularly well-suited for blockchain data analysis, where queries often involve time-based filtering and aggregations across large datasets. The combination of Trino's distributed query processing, Parquet's columnar storage, and Delta Lake's data management provides a robust foundation for handling the scale and complexity of blockchain data.


# Incremental Queries
Source: https://docs.dune.com/query-engine/incremental-queries

Dramatically reduce query costs and execution time by only processing new data since your last run.

Every time you refresh a dashboard or re-run a scheduled query, Dune typically scans **all** historical data from scratch—even though most of that data hasn't changed. For a query calculating daily Ethereum transaction stats going back to 2020, this means:

* Rescanning 4+ years of immutable data
* Costing 100+ credits per run
* Taking 20+ minutes to execute
* When only the last day's data is actually new

**Incremental Queries** solve this by letting you reference your previous results and query only the new data since your last run. The result: **\~100x cheaper and faster** execution for recurring queries.

<Info>
  For complex data transformation pipelines with testing, CI/CD, and version control, see the [dbt Connector](/api-reference/connectors/dbt/overview). Incremental Queries are ideal for simpler dashboard updates using pure SQL.
</Info>

<Warning>
  Incremental Queries are currently only available for regular queries. Support for [Materialized Views](/query-engine/materialized-views) is coming soon.
</Warning>

## How It Works

When you run a query on Dune, your results are stored. With Incremental Queries, you can reference those stored results in your next run using a special table function.

```
First run:  No previous results → Query all historical data → Store results
Second run: Load previous results → Query only new data → Combine & store
Third run:  Load previous results → Query only new data → Combine & store
...and so on
```

Dune handles storing and retrieving your previous results automatically. You write SQL that says "give me my previous results" and "get me new data since then."

### The Table Function

The `TABLE(previous.query.result(...))` function returns your previous query results:

* **First run**: Returns an empty table (0 rows) with your specified schema
* **Subsequent runs**: Returns all data from your previous execution

The schema is defined using `DESCRIPTOR()` which specifies the column names and types:

```sql theme={null}
SELECT * FROM TABLE(previous.query.result(
    schema => DESCRIPTOR(
        day TIMESTAMP(3),
        tx_count BIGINT,
        total_gas BIGINT
    )
))
```

## The Pattern

Here's the standard incremental query pattern:

```sql theme={null}
WITH prev AS (
    -- 1. Load previous results (empty on first run)
    SELECT * FROM TABLE(previous.query.result(
        schema => DESCRIPTOR(
            day TIMESTAMP(3),
            tx_count BIGINT,
            total_gas BIGINT
        )
    ))
),
checkpoint AS (
    -- 2. Find where we left off (with 1-day lookback for incomplete data)
    SELECT COALESCE(MAX(day), TIMESTAMP '2020-01-01') - INTERVAL '1' DAY AS cutoff
    FROM prev
)
-- 3. Keep old data (before cutoff)
SELECT day, tx_count, total_gas
FROM prev
WHERE day < (SELECT cutoff FROM checkpoint)

UNION ALL

-- 4. Compute new data (from cutoff onwards)
SELECT
    date_trunc('day', block_time) AS day,
    COUNT(*) AS tx_count,
    SUM(gas_used) AS total_gas
FROM ethereum.transactions
WHERE block_time >= (SELECT cutoff FROM checkpoint)
GROUP BY 1

ORDER BY day
```

The following diagram shows how data flows through the query pattern:

```mermaid theme={null}
flowchart LR
    subgraph CTEs
        A[prev CTE<br/>Previous Results] --> B[checkpoint CTE<br/>Calculate Cutoff]
    end

    B --> C[Filter: day < cutoff]
    B --> D[Filter: block_time >= cutoff]

    A --> C
    E[(Source Table<br/>ethereum.transactions)] --> D

    C --> F[Old Data]
    D --> G[New Data]

    F --> H[UNION ALL]
    G --> H

    H --> I[Complete Result Set]
```

### Pattern Components

| Component        | Purpose                                                                                                                                           |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| `prev` CTE       | Loads your previous query results. Returns 0 rows on first run.                                                                                   |
| `checkpoint` CTE | Finds the max timestamp from previous results. Uses a default if no previous data exists. The lookback ensures incomplete periods get recomputed. |
| First SELECT     | Keeps historical data that doesn't need recomputing (before the cutoff).                                                                          |
| Second SELECT    | Queries only new/recent data from the source table (from cutoff onwards).                                                                         |
| UNION ALL        | Combines old + new into your complete result set.                                                                                                 |

## When to Use Incremental Queries

### Great For

* **Scheduled queries** that run daily or hourly
* **Dashboard refreshes** that update visualizations with new data
* **Time-series aggregations** (daily stats, hourly metrics)
* **Append-only data** (transactions, events, transfers)
* **Cumulative metrics** that build over time

### Not Ideal For

* **Ad-hoc exploratory queries** (one-time runs don't benefit)
* **Queries where historical data changes** (non-append-only sources)
* **Complex multi-way joins** that can't be easily partitioned by a checkpoint column

## Key Patterns

### Lookback Windows

The lookback window ensures incomplete time periods get recomputed. Choose based on your aggregation granularity:

```sql theme={null}
-- Daily aggregations: 1-day lookback
SELECT COALESCE(MAX(day), TIMESTAMP '2020-01-01') - INTERVAL '1' DAY AS cutoff

```

### Default Checkpoint Values

Use `COALESCE` to provide a sensible default for the first run when no previous results exist:

```sql theme={null}
-- Start of your data interest period
COALESCE(MAX(day), TIMESTAMP '2020-01-01')

-- Block number checkpoint
COALESCE(MAX(block_number), 0)
```

## Example Queries

### Example 1: Daily Transaction Aggregations

Track daily Ethereum transaction statistics with automatic incremental updates:

```sql theme={null}
WITH prev AS (
    SELECT * FROM TABLE(previous.query.result(
        schema => DESCRIPTOR(
            day TIMESTAMP(3),
            tx_count BIGINT,
            total_gas BIGINT
        )
    ))
),
checkpoint AS (
    SELECT COALESCE(MAX(day), TIMESTAMP '2015-07-30') - INTERVAL '1' DAY AS cutoff
    FROM prev
)
SELECT day, tx_count, total_gas FROM prev WHERE day < (SELECT cutoff FROM checkpoint)

UNION ALL

SELECT
    date_trunc('day', block_time) as day,
    COUNT(*) as tx_count,
    SUM(gas_used) as total_gas
FROM ethereum.transactions
WHERE block_time >= (SELECT cutoff FROM checkpoint)
GROUP BY 1

ORDER BY day
```

**First run**: Scans all historical data (expensive, but only happens once).

**Every subsequent run**: Only scans the last day or so of data (cheap and fast).

### Example 2: Hourly Gas Price Statistics

Track gas price percentiles by hour:

```sql theme={null}
WITH prev AS (
    SELECT * FROM TABLE(previous.query.result(
        schema => DESCRIPTOR(
            hour TIMESTAMP(3),
            min_gwei DOUBLE,
            p50_gwei DOUBLE,
            p95_gwei DOUBLE,
            max_gwei DOUBLE,
            tx_count BIGINT
        )
    ))
),
checkpoint AS (
    SELECT COALESCE(MAX(hour), TIMESTAMP '2015-07-30') - INTERVAL '1' HOUR AS cutoff
    FROM prev
)
-- Historical stats (before lookback window)
SELECT hour, min_gwei, p50_gwei, p95_gwei, max_gwei, tx_count
FROM prev
WHERE hour < (SELECT cutoff FROM checkpoint)

UNION ALL

-- Recompute recent hours (including potentially incomplete last hour)
SELECT
    date_trunc('hour', block_time) AS hour,
    MIN(gas_price / 1e9) AS min_gwei,
    APPROX_PERCENTILE(gas_price / 1e9, 0.5) AS p50_gwei,
    APPROX_PERCENTILE(gas_price / 1e9, 0.95) AS p95_gwei,
    MAX(gas_price / 1e9) AS max_gwei,
    COUNT(*) AS tx_count
FROM ethereum.transactions
WHERE block_time >= (SELECT cutoff FROM checkpoint)
GROUP BY 1

ORDER BY hour
```

### Example 3: Cumulative Sums

For cumulative metrics, the pattern is slightly different: select only the base values from previous results and recompute the cumulative over the combined data.

```sql theme={null}
WITH prev AS (
    SELECT * FROM TABLE(previous.query.result(
        schema => DESCRIPTOR(
            day DATE,
            eth_received DOUBLE,
            cumulative_received DOUBLE
        )
    ))
),
checkpoint AS (
    SELECT COALESCE(MAX(day), DATE '2015-07-30') - INTERVAL '1' DAY AS cutoff
    FROM prev
)
SELECT
    day,
    eth_received,
    SUM(eth_received) OVER (ORDER BY day) AS cumulative_received
FROM (
    -- Old daily values (drop the old cumulative, we'll recompute it)
    SELECT day, eth_received
    FROM prev
    WHERE day < (SELECT cutoff FROM checkpoint)

    UNION ALL

    -- New daily values
    SELECT
        CAST(date_trunc('day', block_time) AS DATE) AS day,
        SUM(value / 1e18) AS eth_received
    FROM ethereum.traces
    WHERE "to" = 0xd8dA6BF26964aF9A7eEd9e03E53415D37aA96045
        AND success = TRUE
        AND block_time >= (SELECT cutoff FROM checkpoint)
    GROUP BY 1
)
ORDER BY day
```

**Key insight**: We only select `day` and `eth_received` from previous results—NOT the old `cumulative_received`. Then we recompute the cumulative over the combined data. This is simpler and more reliable than trying to "continue" from the last cumulative value.

## Incremental Queries vs dbt Connector

The [dbt Connector](/api-reference/connectors/dbt/overview) is Dune's full-featured solution for production data pipelines. It provides everything data teams need: multiple incremental strategies (merge, delete+insert, append), built-in testing, auto-generated documentation, Git version control, and CI/CD integration with tools like GitHub Actions and Airflow.

**Incremental Queries give you a taste of that power with zero setup.** They provide the core incremental processing capability—referencing previous results and querying only new data—using pure SQL patterns you already know.

### When to Use Each

**Use Incremental Queries when:**

* You want immediate cost savings with no setup
* You're updating dashboards or running scheduled queries
* Your logic fits in a single query
* You don't need formal testing or CI/CD

**Use the [dbt Connector](/api-reference/connectors/dbt/overview) when:**

* You're building production data pipelines
* You need data quality tests and validation
* Multiple team members collaborate on transformations
* You want Git-based version control and PR reviews
* You need to chain multiple dependent transformations
* You require audit trails and documentation

### Feature Comparison

| Capability             | Incremental Queries   | dbt Connector                               |
| ---------------------- | --------------------- | ------------------------------------------- |
| Incremental processing | Single pattern        | 3 strategies (merge, delete+insert, append) |
| Setup required         | None                  | dbt project configuration                   |
| Data quality testing   | Manual                | Built-in framework                          |
| Documentation          | Manual                | Auto-generated                              |
| Version control        | Dune query versioning | Full Git integration                        |
| CI/CD pipelines        | Not supported         | GitHub Actions, Airflow, etc.               |
| Model dependencies     | Not supported         | Automatic ordering                          |
| Availability           | All users             | Enterprise                                  |

For most dashboard and reporting use cases, Incremental Queries provide excellent cost savings. For production analytics infrastructure, the [dbt Connector](/api-reference/connectors/dbt/overview) is the industry-standard choice.

## Tips and Best Practices

### Choose Appropriate Lookback Windows

Match your lookback window to your aggregation granularity and data characteristics:

* Daily aggregations typically need 1-day lookback
* Hourly metrics need 1-hour lookback
* TVL calculations might need 7-day lookback due to price changes and rebalancing

### Align Checkpoints with Partitions

Dune tables are partitioned by `block_date` or `block_time`. Using time-based checkpoints enables efficient partition pruning:

```sql theme={null}
-- Good: Aligns with partition column
WHERE block_time >= (SELECT cutoff FROM checkpoint)

-- Also good: Using block_date directly
WHERE block_date >= CAST((SELECT cutoff FROM checkpoint) AS DATE)
```

### First Run Costs

The first run of an incremental query processes all historical data and will be expensive. Subsequent runs will be dramatically cheaper. Plan accordingly:

* Run the initial query during off-peak hours if possible
* Consider the first run cost as a one-time investment

### Schema Consistency

Ensure your `DESCRIPTOR` schema exactly matches the columns and types your query produces. Mismatches will cause errors:

```sql theme={null}
-- Schema must match query output exactly
schema => DESCRIPTOR(
    day TIMESTAMP(3),      -- Matches date_trunc output
    tx_count BIGINT,       -- Matches COUNT(*) output
    total_gas BIGINT       -- Matches SUM(gas_used) output
)
```


# Materialized Views
Source: https://docs.dune.com/query-engine/materialized-views

Materialized tables are a way to store the results of a query in a table that can be queried like any other table. This is useful when you have a query that takes a long time to run, or when you want to use the results of a query in another query.

## Overview

The **"Materialized View"** feature on Dune allows you to use an existing query's results as table in another query. This functionality enables you to build your own simple data pipeline inside of Dune. This feature is especially useful when you have a query that takes a long time to run, or when you want to use the results of a query in another query. Instead of running the same query pattern over and over again, you can run it once and then use the results in other queries.

<Info>
  You can also create, manage, and refresh materialized views programmatically using the [Materialized Views API](/api-reference/materialized-views/overview).
</Info>

You should think of using this feature any time you run into:

1. You use the same query pattern across multiple queries
2. Query timeouts (running longer than 30 mintes)
3. Execution Error: Stage limits (exceeding stage limits in the planning stage, can happen when joining many tables)
4. Execution Error: Memory limits (exceeding the memory limits, can happen when you use too many large tables like `solana.transactions` or `ethereum.traces`)

This feature will help you to avoid these issues and save time and credits.

<Note>This feature will contribute to your storage quota, on the free tier you can only create a 1MB materialized view. Learn more [here](https://dune.com/pricing)</Note>

## Create a materialized view

Write a new query or go to an existing query. (We suggest creating via team context on a plan with sufficient credits)

1. Make sure all columns are explicitly named (i.e. `SELECT count(*)` will not work)
2. Save the query
3. After saving a “materialize” button will appear below the run button.
4. Click the materialize button, and set a refresh schedule and execution tier. Each refresh consumes credits based on actual compute resources used.

<div>
  <iframe title="Create a materialized view with an automatic refresh schedule" />
</div>

You can find the example query [here](https://dune.com/queries/3468697), and it can be queried with just:

```sql theme={null}
SELECT
*
FROM dune.dune.result_staking_rate_daily_mat
```

## Query a materialized view

Wait for a materialized view to finish creation first. It should be roughly similar to the time the query normally takes to execute - maybe a bit longer due to time it takes to write the new table.

Query the materialized view via `dune.<username>.result_<given_name>`.

If your username starts with a number, you'll need to wrap the \<username> in quotes i.e. `dune."21co".result_stablecoin_total_supply_on_ethereum`

When you query a materialized view in another query, it does not rerun the materialized view (unlike [query views](../query-engine/query-a-query.mdx)).

**You can find your matviews either [in the data explorer](https://dune.com/queries?category=materialized_views), or in your library. The table name can always be found on the query if you click into the query and then open the matview settings.**

## Things to keep in mind

* A query result has a 200MB limit in the editor but a materialized view doesn't have storage limits. Even though the results will look truncated in the editor.
* This materialized view refresh schedule is DIFFERENT from the query scheduler. Results from running the query or the normal query scheduler will NOT update the materialized view.
* Plans have total monthly storage limits (Enterprise has 200GB+, Plus has 15GB, Free has 100MB).
* You can delete your materialized in the same dialouge where you created it.
* If your team or account name starts with a number, you'll need to wrap the `name` in quotes i.e. `dune."21co".result_stablecoin_total_supply_on_ethereum`
* There currently is no way to nicely ensure sequential execution of materialized views. If you have a materialized view that depends on another materialized view, you'll need to ensure that the upstream materialized view is updated first. This can be done by setting the refresh schedule to be more frequent than the downstream materialized view.


# Query Engine
Source: https://docs.dune.com/query-engine/overview

DuneSQL, a Trino fork, is fine-tuned for blockchain analytics.

<Tip>
  New to DuneSQL? Watch our [DuneSQL overview video](/resources/learning/video-tutorials#dunesql-overview) for a quick introduction.
</Tip>

DuneSQL enhances blockchain data analysis by leveraging a Trino fork. This engine excels in performance for interactive queries across vast datasets, from gigabytes to petabytes.

## Key Features

DuneSQL shines with unique blockchain-focused capabilities:

* **Varbinary Data Types**: Store blockchain specifics like addresses and hashes efficiently.
* **Uint256 & Int256 Support**: Essential for blockchain's large numerical data.
* **Columnar Storage**: Optimizes read speed by organizing data by columns.
* **Query Views**: Enables complex query construction and reusability.
* **Materialized Views**: For enhanced query performance through pre-computed results.

## DuneSQL Essentials

DuneSQL offers a robust platform for blockchain data exploration. As a modified version of TrinoSQL, it supports scalable, interactive analysis across diverse data sizes.

Our documentation equips you with the necessary tools to efficiently harness DuneSQL.

<CardGroup>
  <Card title="Functions and Operators" icon="screwdriver-wrench" href="/query-engine/Functions-and-operators/">
    DuneSQL's syntax toolbox.
  </Card>

  <Card title="Data Types" icon="clipboard-list" href="/query-engine/datatypes">
    Understanding DuneSQL data formats.
  </Card>

  <Card title="Reserved Keywords" icon="book-open" href="/query-engine/reserved-keywords">
    Keywords off-limits for naming.
  </Card>

  <Card title="Writing Efficient Queries" icon="rocket" href="/query-engine/writing-efficient-queries">
    Strategies for query optimization.
  </Card>

  <Card title="Querying a Query" icon="circle-nodes" href="/query-engine/query-a-query">
    Layer queries for complex insights.
  </Card>

  <Card title="Materialized Views" icon="database" href="/query-engine/materialized-views">
    Boost query speed with stored views.
  </Card>
</CardGroup>

## Debugging

Need help with DuneSQL? Start here:

* Google `<problem> Trino SQL` for general inquiries.
* Chat with your favorite AI assistant and ask for `Trino SQL` help.
* Check [Trino's official documentation](https://trino.io/docs/current/functions.html) for detailed insights.


# Query Views
Source: https://docs.dune.com/query-engine/query-a-query

The "Query View" feature in DuneSQL allows you to use an existing query as a view in another query. This powerful functionality enables you to create reusable queries, build complex queries, and take advantage of existing queries as views.

## Overview

The "Query View" feature in DuneSQL allows you to use an existing query as a view in another query. This powerful functionality enables you to create reusable queries, build complex queries, and take advantage of existing queries as views.

**You can also pass on parameters when querying a query view.**

<Info>All upstream queries are executed as functional SQL views, which means that they will be executed every time they are queried. This means there currently is no performance benefit to using the "Query a Query" feature. If you are looking for a performance benefit, consider using [materialized views](/query-engine/materialized-views) instead.</Info>

## Using Query View

To use the "Query View" feature, you will need the queryID of the query you want to use as a view. The queryID can be found in the URL of a query. For example, if the URL of a query is [https://dune.com/queries/1746191](https://dune.com/queries/1746191), the queryID would be `1746191`.

Once you have the queryID, you can use it in your new query using the following syntax:

```sql theme={null}
select * from query_<queryID>
```

For example, if you want to use the query with queryID 1746191 as a view in your new query, you would write:

```sql theme={null}
select * from query_1746191 
```

### Adding Parameters When Using Query Views

You can also pass on parameters when querying a query view. This allows you to use the same query view with different parameters in different queries.

<Info>For detailed information about creating and configuring parameters in your queries, see the [Parameters documentation](/web-app/query-editor/parameters).</Info>

To pass on parameters when querying a query view, you need to use the following syntax:

```sql theme={null}

Select * from "query_<queryID>(<parameter1>='<value1>', <parameter2>='<value2>', ...)"
```

For example, if you want to use the query with queryID 3256410 as a view in your new query and pass on the parameter `blockchain` with the value `ethereum`, the setup would look like this:

```sql theme={null}
--query_3256410, our query to be invoked
Select 
    project,
    block_date,
    sum(amount_usd) as amount_usd
from dex.trades
where blockchain = '{{blockchain}}'
and block_time > now() - interval '7' day 
```

[link to query](https://dune.com/queries/3256410)

```sql theme={null}
--query_3256401, our query that invokes the query_3256410
Select 
    project,
    block_date,
    amount_usd 
from "query_3256410(blockchain='ethereum')"
```

[link to query](https://dune.com/queries/3256401)

Parameters in the query view are passed on as strings and therefore always need to be wrapped in single quotes. Since we sometimes want to pass a `string` including the single quotes, we need to escape the single quotes in the query view. We can do that by adding a backslash in front of the single quote. Escaping single quotes means that the single quote will be treated as a literal character and not as a string delimiter.

**For example:**

```sql theme={null}
--query to be invoked
Select 
    project,
    block_date,
    sum(amount_usd) as volume_in_usd
from dex.trades
where blockchain = {{blockchain}}
-- we want to pass a string including the single quotes to this query
```

```sql theme={null}
--query that invokes the query above
Select 
    project,
    block_date,
    volume_in_usd
from "query_3256410(blockchain='\'ethereum\'')"
--note the escaped single quotes
--this will pass the parameter blockchain with the value 'ethereum'
```

The backslash is not needed when passing on a parameter that doesn't need to be wrapped in single quotes on the receiving side, like `integers` or `booleans`.
You can choose to handle this on the query view side or on the query that invokes the query view side. If you wrap your parameter in single quotes on the receiving side, you don't need to escape the single quotes on the query view side.

**For example:**

```sql theme={null}
--query_3256410, our query to be invoked
Select 
    project,
    block_date,
    sum(amount_usd) as amount_usd
from dex.trades
where blockchain = '{{blockchain}}'
and block_time > now() - interval '7' day 
--note the single quotes around the parameter blockchain
```

```sql theme={null}
Select 
    project,
    block_date,
    amount_usd 
from "query_3256410(blockchain='ethereum')"
--since we wrap the parameter blockchain in single quotes on the receiving side, we don't need to escape the single quotes on the query view side
```

The table below shows how different parameter types are passed on when using the "Query view" feature:

| **Parameter Type**    | **Syntax**                                                                                                                                                                                                                                                                                 | **Example**                                                                                                                                                                                                                                                                                                                                      |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Literal               | `query(tableName='labels.all', whateverKey='lala')`                                                                                                                                                                                                                                        | **Original Query**: select \* from `{{tableName}}` <br /> **Macro**: select \* from "query\_123(tableName='labels.all')"                                                                                                                                                                                                                         |
| Integer, Bigint       | `query(integerKey='1')`                                                                                                                                                                                                                                                                    | **Original Query**: select `{{integerKey}}` <br /> **Macro**: select \* from "query\_123(integerKey='1')"                                                                                                                                                                                                                                        |
| Decimal, Double       | `query(decimalKey='1.2')` <br /> `query(realKey='1.2F')` <br /> `query(doubleKey='1.2E0')`                                                                                                                                                                                                 | **Original Query**: select `{{realKey}}` <br /> **Macro**: select \* from "query\_123(realKey='1.2F')"                                                                                                                                                                                                                                           |
| Varchar               | `query(varcharKey='\'ethereum\'')`                                                                                                                                                                                                                                                         | **Original Query**: select \* from labels.all where name = `{{varcharKey}}` <br /> **Macro**: select \* from "query\_123(varcharKey=''DEX Trader'')"                                                                                                                                                                                             |
| Char                  | `query(charKey='\'a\'')`                                                                                                                                                                                                                                                                   | **Original Query**: select `{{charKey}}` <br /> **Macro**: select \* from "query\_123(charKey=''a'')"                                                                                                                                                                                                                                            |
| Varbinary             | `query(varbinaryKey='0xabcd')`                                                                                                                                                                                                                                                             | **Original Query**: select \* from labels.all where address = `{{varbinaryKey}}` <br /> **Macro**: select \* from "query\_123(varbinaryKey='0xabcd')"                                                                                                                                                                                            |
| UINT256               | `query(uint256Key='UINT256 \'1\'')`                                                                                                                                                                                                                                                        | **Original Query**: select \* from arbitrum.transactions where gas\_price = `{{uint256Key}}` <br /> **Macro**: select \* from "query\_123(uint256Key='uint256 '1'')" <br /> **Original Query**: select \* from arbitrum.transactions where gas\_price = uint256 '`{{uint256Key}}`' <br /> **Macro**: select \* from "query\_123(uint256Key='1')" |
| INT256                | `query(int256Key='INT256 \'-1\'')`                                                                                                                                                                                                                                                         | **Original Query**: select \* from arbitrum.transactions where gas\_price = `{{int256Key}}` <br /> **Macro**: select \* from "query\_123(int256Key='int256 '-1'')" <br /> **Original Query**: select \* from arbitrum.transactions where gas\_price = int256 '`{{int256Key}}`' <br /> **Macro**: select \* from "query\_123(int256Key='1')"      |
| Date, Time, Timestamp | `query(dateKey='2023-01-02')` <br /> `query(dateKey='date \'2023-01-02\'')` <br /> `query(dateKey='13:45:30 +05:00')` <br /> `query(dateKey='time \'13:45:30 +05:00\'')` <br /> `query(dateKey='2023-08-24 13:45:30 UTC')` <br /> `query(dateKey='timestamp \'2023-08-24 13:45:30 UTC\'')` | **Original Query**: select \* from ethereum.blocks where time > `{{dateKey}}` <br /> **Macro**: select \* from "query\_123(dateKey='timestamp '2023-08-24'')" <br /> **Original Query**: select \* from ethereum.blocks where time > timestamp '`{{dateKey}}`' <br /> **Macro**: select \* from "query\_123(dateKey='2023-08-24')"               |
| Array                 | `query(arrayKey='array[1,2,3]')` <br /> `query(arrayKey='array[uint256 \'1\', uint256 \'2\']')` <br /> `query(arrayKey='array[\'these\', \'are\, \'varchar\]')`                                                                                                                            | **Original Query**: select \* from dex\_aggregator.trades where trace\_address = `{{arrayKey}}` <br /> **Macro**: select \* from "query\_123(arrayKey='array\[1, 2]')"                                                                                                                                                                           |
| Boolean               | `query(booleanKey='true')`                                                                                                                                                                                                                                                                 | **Original Query**: select \* from bitcoin.inputs where is\_coinbase = `{{booleanKey}}` <br /> **Macro**: select \* from "query\_123(booleanKey='false')"                                                                                                                                                                                        |
| Row                   | `query(rowKey='row(1, uint256 \'1\', \'hi\')')`                                                                                                                                                                                                                                            | **Original Query**: select `{{rowKey}}` <br /> **Macro**: select \* from "query\_123(rowKey='row(false, 1, uint256 '1', 'hi')')"                                                                                                                                                                                                                 |
| Map                   | `query(mapKey='map(array[\'key1\', \'key2\'], array[\'value1\', \'value2\'])')`                                                                                                                                                                                                            | **Original Query**: select `{{mapKey}}` <br /> **Macro**: select \* from "query\_123(mapKey='map(array\['key1', 'key2'], array\['value1', 'value2'])')"                                                                                                                                                                                          |

## Limitations

There are some important limitations and requirements to consider when using the "Query a Query" feature:

1. **Named output columns**: All output columns of the query being queried must be named. For example, you cannot query `select 1` or `select count(*) from ethereum.transactions`, but you can query `select 1 as v` and `select count(*) as total from ethereum.transactions`.
2. **Saved queries**: Only saved queries can be used with the "Query a Query" feature.
3. **Archived queries**: Archived queries cannot be queried.
4. **Dune SQL**: Only queries written in Dune SQL can be queried.
5. **Mixed cases on parameters:** If you pass parameters when querying a query, the parameter key and its values should be lower case (i.e.: `select "query_123(Key=\'VaLue\')"` will not work).
6. **List parameters:** the query you're querying cannot have parameters that use list options from the results of a separate query.

<Tip>
  Querying private queries is an [Enterprise feature](https://dune.com/enterprise) only. You can't query private queries with a free or plus account.
</Tip>

## Best Practices

When using the "Query View" feature, consider the following best practices:

1. **Naming conventions**: Ensure that your queries follow a consistent naming convention for output columns. This will make it easier to understand and reuse queries as views.
2. **Documentation**: Provide clear documentation and comments for your queries, especially when they are intended to be used as views in other queries.
3. **Modularity**: Break down complex queries into smaller, reusable components. This will make your queries more maintainable and easier to understand.
4. **Version control**: If you need to update a query that is being used as a view in other queries, consider creating a new version of the query instead of modifying the existing one. This will help prevent unexpected changes in dependent queries.
5. **Forking** If you use the query of another user as a view in your query, consider forking the query instead of querying it. That way, you will not be affected by changes made to the **Original Query**. On the other hand, you will also not be able to benefit from any improvements made to the **Original Query**.


# Query Executions
Source: https://docs.dune.com/query-engine/query-executions

Learn about query execution triggers and which engine size is best for your workload.

Every query on Dune must be triggered and then executed on one of our query engines. The execution trigger determines *when* and *how* a query runs, while the engine size determines the compute resources allocated to it. Understanding both helps you optimize for speed, cost, and reliability.

## Query Execution Triggers

Queries on Dune need to be triggered before they are executed. Query executions can be triggered by any user or team for public queries, and by the owner for private queries. There are four ways a query execution can be triggered:

<AccordionGroup>
  <Accordion title="Interactive Execution">
    Interactive executions are manually triggered by a user clicking the "Run" button in the query editor or by refreshing an entire dashboard. You can choose to route interactive executions through the Small, Medium, or Large engine depending on the engine size you select.

    <div>
      <iframe title="Change the Query Engine Size Before Running a SQL Query" />
    </div>
  </Accordion>

  <Accordion title="Scheduled Execution">
    Scheduled executions are triggered automatically at a specific time and frequency that you configure. Scheduled executions can be routed through the Medium or Large engine depending on the execution tier you select.

    <div>
      <iframe title="Schedule a Dune dashboard to refresh at a time interval" />
    </div>
  </Accordion>

  <Accordion title="API Execution">
    API executions are triggered programmatically through a Dune API call. This is useful for embedding query results in your own application or automating query runs via a cron job. API executions can be routed through the Small, Medium, or Large engine depending on the engine size you select.

    [→ Learn more about API executions](/api-reference/executions/endpoint/execute-query)
  </Accordion>

  <Accordion title="Popular Dashboard Execution">
    Popular dashboards are automatically refreshed by Dune based on their view count. The most popular dashboards are refreshed every hour, while less popular dashboards are refreshed every 24 hours. These executions run on the community cluster at no credit cost.

    <img alt="" />
  </Accordion>
</AccordionGroup>

## Query Engine Sizes

Dune has three query engine sizes: **Small**, **Medium**, and **Large**. The query engine size determines the amount of resources allocated to your query. The larger the engine, the more resources are allocated — meaning queries run faster and are less likely to time out.

<Note>
  The **Small** engine consumes a small amount of credits, while **Medium** and **Large** consume more credits based on actual compute used. [Learn more about credit usage](/resources/credits-billing/how-credits-work).
</Note>

<div>
  <iframe title="Run a SQL Query with Increased Engine Size" />
</div>

#### Small Engine

The Small engine is the default for all queries on Dune. It runs on a shared community cluster, which means performance can vary when many users are running queries at the same time. Executions on the Small engine consume a small amount of credits and will time out after 2 minutes. You are limited to a maximum of three (3) concurrent executions.

<div>
  <iframe title="Change Query Engine Size and Re-Run a SQL Query" />
</div>

#### Medium Engine

Run queries manually or programmatically with a larger timeout and no limit on concurrent executions. Credits are consumed based on actual compute resources used. Suitable for most standard queries and dashboards.

<div>
  <iframe title="Run a SQL Query and View Results in JSON Format" />
</div>

#### Large Engine

Optimized for complex workloads requiring maximum computational power. The Large engine provides approximately 2x the capacity of Medium, completing queries faster but consuming more credits for the same query. Ideal for data-intensive queries and heavy analytics.

<div>
  <iframe title="Choose a Query Engine Size for Running Blockchain Data Queries" />
</div>


# Reserved keywords
Source: https://docs.dune.com/query-engine/reserved-keywords

The following table lists all of the keywords that are reserved in DuneSQL, along with their status in the SQL standard. These reserved keywords must be quoted (using double quotes) in order to be used as an identifier.

For example to query the transactions table for all transactions from a specific address you would use the following query with `from` in double quotes:

```sql theme={null}
Select * from ethereum.transactions 
where "from" = 0xc8ebccc5f5689fa8659d83713341e5ad19349448
```

## Reserved keywords

| Keyword             | SQL:2016 |
| ------------------- | -------- |
| `ALTER`             | reserved |
| `AND`               | reserved |
| `AS`                | reserved |
| `ASOF`              | reserved |
| `BETWEEN`           | reserved |
| `BY`                | reserved |
| `CASE`              | reserved |
| `CAST`              | reserved |
| `CONSTRAINT`        | reserved |
| `CREATE`            | reserved |
| `CROSS`             | reserved |
| `CUBE`              | reserved |
| `CURRENT_CATALOG`   | reserved |
| `CURRENT_DATE`      | reserved |
| `CURRENT_PATH`      | reserved |
| `CURRENT_ROLE`      | reserved |
| `CURRENT_SCHEMA`    | reserved |
| `CURRENT_TIME`      | reserved |
| `CURRENT_TIMESTAMP` | reserved |
| `CURRENT_USER`      | reserved |
| `DEALLOCATE`        | reserved |
| `DELETE`            | reserved |
| `DESCRIBE`          | reserved |
| `DISTINCT`          | reserved |
| `DROP`              | reserved |
| `ELSE`              | reserved |
| `END`               | reserved |
| `ESCAPE`            | reserved |
| `EXCEPT`            | reserved |
| `EXECUTE`           | reserved |
| `EXISTS`            | reserved |
| `EXTRACT`           | reserved |
| `FALSE`             | reserved |
| `FOR`               | reserved |
| `FROM`              | reserved |
| `FULL`              | reserved |
| `GROUP`             | reserved |
| `GROUPING`          | reserved |
| `HAVING`            | reserved |
| `IN`                | reserved |
| `INNER`             | reserved |
| `INSERT`            | reserved |
| `INTERSECT`         | reserved |
| `INTO`              | reserved |
| `IS`                | reserved |
| `JOIN`              | reserved |
| `JSON_ARRAY`        | reserved |
| `JSON_EXISTS`       | reserved |
| `JSON_OBJECT`       | reserved |
| `JSON_QUERY`        | reserved |
| `JSON_VALUE`        | reserved |
| `LEFT`              | reserved |
| `LIKE`              | reserved |
| `LISTAGG`           | reserved |
| `LOCALTIME`         | reserved |
| `LOCALTIMESTAMP`    | reserved |
| `NATURAL`           | reserved |
| `NORMALIZE`         | reserved |
| `NOT`               | reserved |
| `NULL`              | reserved |
| `ON`                | reserved |
| `OR`                | reserved |
| `ORDER`             | reserved |
| `OUTER`             | reserved |
| `PREPARE`           | reserved |
| `RECURSIVE`         | reserved |
| `RIGHT`             | reserved |
| `ROLLUP`            | reserved |
| `SELECT`            | reserved |
| `SKIP`              | reserved |
| `TABLE`             | reserved |
| `THEN`              | reserved |
| `TRIM`              | reserved |
| `TRUE`              | reserved |
| `UESCAPE`           | reserved |
| `UNION`             | reserved |
| `UNNEST`            | reserved |
| `USING`             | reserved |
| `VALUES`            | reserved |
| `WHEN`              | reserved |
| `WHERE`             | reserved |
| `WITH`              | reserved |


# Writing Efficient Queries
Source: https://docs.dune.com/query-engine/writing-efficient-queries

Get the most out of DuneSQL by writing efficient queries.

This guide provides practical do's and don'ts specifically tailored to DuneSQL and Dune's architecture, allowing you to optimize credit spend.

## Key Principles

Dune's query engine is optimized for blockchain data analysis with time-partitioned tables and columnar storage.
Understanding the [DuneSQL architecture](/query-engine/dunesql-architecture) will help you write queries that execute faster and consume fewer resources.

## ✅ DO's: Query Optimization Best Practices

### 1. Leverage Time-Based Partitioning

Dune partitions most tables by `block_date` or by `block_time`

Check on the data explorer (left-side panel) to see which fields are used as partitions.
Always include time filters to enable partition pruning.

**Cross-chain tables:** Large cross-chain tables like `tokens.transfers`, `dex.trades`, and `evms.erc20_evt_transfers` are most often also partitioned by `blockchain` in addition to time. Wherever possible, specify the blockchain filter along with time filters to dramatically reduce the amount of data scanned.

```sql theme={null}
-- ✅ GOOD: Filters by block_date to enable partition pruning
SELECT 
    hash,
    "from",
    "to",
    value
FROM base.transactions
WHERE block_date >= TIMESTAMP '2025-09-01 00:00:00'
  AND block_date < TIMESTAMP '2025-10-02 00:00:00'
  AND "to" = 0x827922686190790b37229fd06084350E74485b72

-- ✅ EXCELLENT: Filters by both blockchain and time for cross-chain tables
SELECT 
    block_time,
    tx_hash,
    "from",
    "to",
    amount_usd
FROM dex.trades
WHERE blockchain = 'ethereum'
  AND block_time >= TIMESTAMP '2024-10-01'
  AND block_time < TIMESTAMP '2024-11-01'
```

### 2. Select Only Required Columns

Specify only the columns you need. Dune's columnar storage makes this especially effective.

```sql theme={null}
-- ✅ GOOD: Selects only necessary columns
SELECT 
    evt_block_time,
    "from",
    "to", 
    value
FROM erc20_ethereum.evt_Transfer
WHERE contract_address = 0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48
  AND evt_block_time >= NOW() - INTERVAL '7' DAY
```

### 3. Use Efficient JOIN Strategies

Put time filters in the ON clause and join on indexed columns when possible.

```sql theme={null}
-- ✅ GOOD: Efficient join with time filter in ON clause
SELECT 
    t.hash,
    t.block_time,
    l.topic0,
    l.data
FROM ethereum.transactions t
INNER JOIN ethereum.logs l 
    ON t.hash = l.tx_hash
    AND t.block_date = l.block_date
    AND l.block_date >= TIMESTAMP '2024-10-01'
    AND l.block_date < TIMESTAMP '2024-10-02'
WHERE t."to" = 0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48
    AND t.block_date >= TIMESTAMP '2024-10-01'
    AND t.block_date < TIMESTAMP '2024-10-02'
```

### 4. Use CTEs for Complex Logic

Break complex queries into readable Common Table Expressions.

```sql theme={null}
-- ✅ GOOD: Using CTEs for better performance and readability
WITH daily_volumes AS (
    SELECT 
        block_date as trade_date,
        SUM(amount_usd) as daily_volume
    FROM dex.trades
    WHERE blockchain = 'ethereum'
      AND block_date >= TIMESTAMP '2024-09-01'     
      AND block_date < TIMESTAMP '2024-10-01'
    GROUP BY block_date
),
volume_metrics AS (
    SELECT 
        trade_date,
        daily_volume,
        AVG(daily_volume) OVER (
            ORDER BY trade_date 
            ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
        ) as rolling_7day_avg
    FROM daily_volumes
)
SELECT * FROM volume_metrics
ORDER BY trade_date DESC
```

### 5. Use LIMIT with Large Result Sets

Always use LIMIT when you don't need all results, especially for exploratory queries.

```sql theme={null}
-- ✅ GOOD: Using LIMIT for large result sets
SELECT 
    hash,
    block_time,
    gas_used,
    gas_price
FROM ethereum.transactions
WHERE block_time >= TIMESTAMP '2024-10-01'
ORDER BY gas_price DESC
LIMIT 1000
```

### Use Curated Data Tables

Leverage Dune's [curated tables](https://docs.dune.com/data-catalog/overview) which are pre-computed and optimized rather than use raw logs and traces.

### Use Materialized Views

[Materialized views](https://docs.dune.com/query-engine/materialized-views) are a way to store the results of a query in a table that can be queried like any other table.
This is useful when you have a query that takes a long time to run, as you can re-use the results without having to re-execute your whole query.

### Use Incremental Queries for Recurring Workloads

For scheduled queries or dashboards that refresh regularly, [Incremental Queries](/query-engine/incremental-queries) can reduce costs by up to 100x by only processing new data since your last run.

Instead of rescanning years of historical data on every refresh, incremental queries:

* Load your previous results automatically
* Query only the new data since your last checkpoint
* Combine old + new results efficiently

```sql theme={null}
WITH prev AS (
    SELECT * FROM TABLE(previous.query.result(
        schema => DESCRIPTOR(day TIMESTAMP(3), tx_count BIGINT)
    ))
),
checkpoint AS (
    SELECT COALESCE(MAX(day), TIMESTAMP '2015-07-30') - INTERVAL '1' DAY AS cutoff FROM prev
)
-- Keep old data
SELECT day, tx_count FROM prev WHERE day < (SELECT cutoff FROM checkpoint)
UNION ALL
-- Query only new data
SELECT date_trunc('day', block_time) AS day, COUNT(*) AS tx_count
FROM ethereum.transactions
WHERE block_time >= (SELECT cutoff FROM checkpoint)
GROUP BY 1
```

This is ideal for daily aggregations, hourly metrics, and any time-series analysis that runs on a schedule. See the [full documentation](/query-engine/incremental-queries) for more patterns and examples.

## Query Performance Troubleshooting

* Monitor query execution time in the Dune interface
* Check the query plan for full table scans (run EXPLAIN ANALYZE YOUR\_QUERY)
* Consider query complexity vs. result value trade-offs

## ❌ DON'Ts: Query Anti-Patterns to Avoid

### 1. **DON'T** Use `SELECT *` on Large Tables

Avoid selecting all columns, especially on transaction and log tables.

```sql theme={null}
-- ❌ BAD: Select all columns unnecessarily
SELECT * 
FROM ethereum.transactions
WHERE block_time >= TIMESTAMP '2024-10-01'

-- ✅ GOOD: Select only needed columns
SELECT hash, from_address, to_address, value
FROM ethereum.transactions  
WHERE block_time >= TIMESTAMP '2024-10-01'
```

### 2. **DON'T** Create Unnecessary Subqueries

Avoid nested subqueries when JOINs or window functions work better.

```sql theme={null}
-- ❌ BAD: Inefficient correlated subquery
SELECT 
    b1.number,
    b1.gas_used,
    (
        SELECT AVG(b2.gas_used)
        FROM ethereum.blocks b2
        WHERE b2.time >= TIMESTAMP '2024-10-01'
          AND b2.number <= b1.number
          AND b2.number > b1.number - 100
    ) AS avg_100_blocks
FROM ethereum.blocks b1
WHERE b1.time >= TIMESTAMP '2024-10-01';

-- ✅ GOOD: Use window functions instead
WITH gas_used AS (
    SELECT 
        number,
        gas_used,
        AVG(gas_used) OVER (
            ORDER BY time
            ROWS BETWEEN 99 PRECEDING AND CURRENT ROW
        ) as avg_100_blocks
    FROM ethereum.blocks
    WHERE time >= TIMESTAMP '2024-10-01'
) 
SELECT 
    number,
    gas_used,
    avg_100_blocks
FROM gas_used
```

### 3. **DON'T** Use ORDER BY Without LIMIT on Large Results

Sorting large result sets is expensive.

```sql theme={null}
-- ❌ BAD: Ordering large result set without limit
SELECT hash, gas_price
FROM ethereum.transactions
WHERE block_time >= TIMESTAMP '2024-10-01'
ORDER BY gas_price DESC

-- ✅ GOOD: Add LIMIT when ordering
SELECT hash, gas_price
FROM ethereum.transactions
WHERE block_time >= TIMESTAMP '2024-10-01'
ORDER BY gas_price DESC
LIMIT 10000
```

## Summary

Efficient DuneSQL queries on Dune require understanding the platform's time-partitioned architecture. Focus on:

1. **Time filtering** with time fields for partition pruning
2. **Column selection** to leverage columnar storage
3. **Strategic joins** with proper filter placement
4. **Avoiding anti-patterns** that prevent optimizations


# How Credits Work
Source: https://docs.dune.com/resources/credits-billing/how-credits-work

How Dune's usage-based credit system works for fair and flexible querying

# How you spend credits on Dune

Dune uses a usage-based credit system that charges based on actual compute resources consumed, ensuring fair pricing for all users regardless of query complexity.

See full blog post announcement [here](https://dune.com/blog/credits-changing)

## How the Credit System Works

Our query engine uses a flexible credit-based pricing model that scales with your actual resource consumption. When you run a query, credits are spent in proportion to the resources used—simple queries cost fewer credits, while complex queries that require more computational resources use more credits.

This approach ensures fair pricing across our platform, which spans 100+ chains, complex tables, and multiple ways to consume data through APIs and various connector options. The credit system adapts to your needs: small, efficient queries are economical, while larger, more complex queries can leverage extended timeouts and additional resources as needed.

Your credits work seamlessly across all query types and data consumption methods, providing transparent and predictable pricing that scales with your usage.

**Key benefits:**

* **Usage-based** – Pay in proportion to actual consumption
* **Efficiency** – Incentives to write cleaner, optimized queries
* **Scalable** – Sustainable future support for larger workloads with longer timeouts and expanded connector options to come in the near future

This fair, usage-based model ensures Dune can keep pace with your most ambitious data needs.

## Credit Pricing

Credits are consumed based on the actual compute resources used for each query execution. The more complex your query, the more credits it consumes, but simple queries cost significantly less. At the moment, we don't share a single, per-query formula because credit usage depends on real-time factors (the compute your query actually uses, the engine you choose, and current network/data access conditions.

To stay in full control, you can set:

* a global query cost cap (per-execution ceiling). More info on how to do this [here](https://app.arcade.software/share/C60r4u7ESOp5RXRuzbSN).
* a monthly extra credit limit (account-level ceiling).
  These controls ensure you never exceed what you're comfortable spending per run or per month. Learn how to set this up [here](https://app.arcade.software/share/so8QGM4H4MU0OWRWhNe9).

**Credit Pricing = Extra Credit Pricing**\
Extra credits are charged at the same rate as your plan. The price per 100 credits shown for each plan is what you pay for any usage beyond your included credits, keeping things simple and transparent.

**Quick Plan Reference**

| Plan                 | Monthly Price               | Annual Price | Credits/Month | Cost per 100 Credits                                               |
| -------------------- | --------------------------- | ------------ | ------------- | ------------------------------------------------------------------ |
| **Free**             | Free                        | -            | 2,500         | \$5.00                                                             |
| **Analyst**          | \$75/month                  | -            | 4,000         | \$1.875                                                            |
| **Analyst (Annual)** | \$65/month billed annually  | \$780/year   | 4,000         | \$1.625                                                            |
| **Plus**             | \$399/month                 | -            | 25,000        | \$1.596                                                            |
| **Plus (Annual)**    | \$349/month billed annually | \$4,188/year | 25,000        | \$1.396                                                            |
| **Legacy Premium**   | No longer available         | -            | Varies        | [Contact support](mailto:support@dune.com)                         |
| **Enterprise**       | Favorable Custom Pricing    | -            | Custom        | **Favorable rates** - [Contact sales](https://dune.com/enterprise) |

<Tip>
  **Save with Enterprise Pricing**: Enterprise plans receive **significantly lower per-credit rates** compared to standard plans, plus customized support and tailored solutions. Whether you're scaling up or just getting started, [contact our sales team](https://dune.com/enterprise) to discuss custom pricing that fits your needs.
</Tip>

<Note>
  **Legacy Premium**: This plan is no longer available for new subscriptions. Existing Premium customers can continue to use their plan.
</Note>

<Info>
  Explore the complete pricing plan with credit limits and features for each tier: [dune.com/pricing](https://dune.com/pricing)
</Info>

## Managing Your Credit Usage

* **Review your usage.** Check your query volume and costs regularly to stay informed about your credit consumption.
* **Optimize your queries.** Efficient queries save credits and run faster. See [here](https://docs.dune.com/query-engine/writing-efficient-queries) for tips.
* **Pick the plan that fits.** If you anticipate heavy usage or notice extra credits usage, consider upgrading to Enterprise for **significantly lower per-credit rates**. Contact our sales team at [dune.com/enterprise](http://dune.com/enterprise) to discuss custom pricing and tailored solutions for your needs.
* **Cap your query costs.** Control spending by setting a maximum credit limit for individual queries. More info on how to do this [here](https://app.arcade.software/share/C60r4u7ESOp5RXRuzbSN).
* **Set extra credit limits.** Configure your extra credit spending limits to control costs. Learn how to set this up [here](https://app.arcade.software/share/so8QGM4H4MU0OWRWhNe9).

## Need Help?

Have questions or need additional support? [Contact Us](mailto:support@dune.com)

## FAQ

### Pricing & Plans

<AccordionGroup>
  <Accordion title="How does Dune's credit system work?">
    Dune uses a usage-based credit system that charges based on actual compute resources consumed. This ensures fair pricing where lightweight queries cost less and complex queries cost more based on their actual resource requirements, providing everyone with a fair and flexible experience.
  </Accordion>

  <Accordion title="Is there a Free plan?">
    Yes. The Free plan includes **2,500 credits per month at no cost**. With the usage-based system, credits are consumed based on actual query resources. Small, efficient queries use fewer credits, allowing you to run more queries within your monthly allowance. Larger or more complex queries will use credits more quickly. If you consistently need more capacity, you can upgrade to a paid plan anytime.
  </Accordion>

  <Accordion title="Can I run bigger queries if I stay on a Free plan?">
    Yes, but you will be limited to the Small and Medium engine. If you often hit timeout limits, consider the Analyst or Plus plans.
  </Accordion>

  <Accordion title="How are credits calculated?">
    Credits are based on the actual compute effort measured in CPU-seconds and network resources a query consumes. This means lightweight queries cost fewer credits, while complex, resource-intensive operations require more credits.

    At the moment, we don't share a single, per-query formula because credit usage depends on real-time factors (the compute your query actually uses, the engine you choose, and current network/data access conditions).

    In practice:
    Credits scale with compute used. Heavier queries consume more credits; lighter ones consume fewer.
    Engine matters. Large runs complex queries fastest and therefore consumes credits at a higher rate than Medium; Small prioritizes queue time over speed and is most efficient for simple jobs.

    To stay in full control, you can set:
    a global query cost cap (per-execution ceiling), and
    a monthly extra credit limit (account-level ceiling).
  </Accordion>

  <Accordion title="I run a lot of API queries. Will they cost more?">
    Cost will depend on compute used by those API queries. You can check the usage dashboard in Settings to track API-specific consumption.
  </Accordion>
</AccordionGroup>

### Usage & Monitoring

<AccordionGroup>
  <Accordion title="How can I monitor my credit consumption?">
    The usage and billing dashboard shows credits used, extra credits, and historical usage.
  </Accordion>

  <Accordion title="Will I see the cost before running a query?">
    You'll see costs after execution.
  </Accordion>

  <Accordion title="Can I run bigger queries now?">
    Yes more complex queries and higher data volumes with longer timeouts for Enterprise clients.
  </Accordion>

  <Accordion title="What is a system user? Is that for scheduled jobs?">
    Yes, the system user represents automated executions on the Dune platform. This includes scheduled query runs, materialized view refreshes, and other background jobs that run without direct user interaction. When you see credit usage attributed to a system user, it typically means those credits were consumed by your scheduled queries or automated data refresh processes rather than manual query executions.
  </Accordion>
</AccordionGroup>

### Optimization & Support

<AccordionGroup>
  <Accordion title="How can I lower my credit usage?">
    Write efficient SQL, limit unnecessary joins or scans, and reuse results when possible. Our docs include [query optimization tips](https://docs.dune.com/query-engine/writing-efficient-queries).
  </Accordion>

  <Accordion title="What if I consistently exceed my plan credits?">
    You can upgrade to a higher plan or contact our sales team to discuss a custom Enterprise solution.
  </Accordion>

  <Accordion title="Who do I contact for help?">
    Reach out to [support@dune.com](mailto:support@dune.com) or your Dune account manager for Enterprise plans.
  </Accordion>
</AccordionGroup>


# Overview
Source: https://docs.dune.com/resources/credits-billing/overview

What is the credit system on Dune and how credits work on Dune

Dune's operations largely rely on a credit system. This guide will explain the concept of credits, their consumption, and management.

### What are credits?

Credits are the key to accessing a wide range of functions on the Dune platform. Whether you're delving into writing queries or simply exploring dashboards, knowing how credits operate is crucial.

### Why are credits important?

All actions on Dune, from refreshing a dashboard to exporting data via the API, consume credits. It's vital for every user, viewer, or creator alike, to be mindful of their credit usage.

## Your Credit Allocation

No worries, every Dune user gets a monthly credit allowance. Here's how it works:

### 🎟️ Monthly Credit Allowance

* **Set Number of Credits:** Each month, your subscription plan provides a set allotment of credits.
* **Top-Up:** Run out of credits? Our "pay as you go" option lets you add more anytime, ensuring your work is always in flow.

### 🔄 Rollover Policy

* **Monthly Refresh:** Credits reset at the start of each billing cycle; they do not roll over to the next month.
* **Maximize Use:** Plan your activities to maximize the utility of your credits.

### 👥 Team Accounts

* **Collective Pool:** All team members draw from a shared pot of credits. Sync up to make the most of your resources.

## Understanding Credit Use on Dune

Credits power your work on Dune, and here's how they're typically used:

<CardGroup>
  <Card title="Queries" icon="clipboard-question" href="/web-app/query-editor/query-window">
    Running and creating queries consumes credits, with the amount varying based on complexity.
  </Card>

  <Card title="Engine Power" icon="gauge" href="/query-engine/query-executions#query-engine-size">
    Larger tasks consume more computational resources, which increases credit usage based on actual compute used.
  </Card>

  <Card title="Refreshes" icon="arrows-rotate" href="/web-app/dashboards#keeping-your-dashboard-up-to-date">
    Refreshing dashboards or widgets consumes credits; exact numbers are displayed contextually.
  </Card>

  <Card title="Exports" icon="file-export" href="/learning/how-tos/export-data-out">
    Exporting data costs credits, with higher amounts for larger exports. Estimates are provided beforehand.
  </Card>

  <Card title="Auto-Runs" icon="timer" href="/web-app/query-editor/query-scheduler">
    Scheduling queries to run regularly consumes credits each time, with details available in the setup options.
  </Card>
</CardGroup>

### Estimating Credit Usage

Understanding how your activities on Dune consume credits can help you manage your resources more effectively:

* **Credit Estimates:** Always check for tooltips or on-screen indicators that provide real-time estimates of credit costs before you perform actions.
* **Active Monitoring:** Keep a regular tab on your credit usage through your settings dashboard to avoid surprises.

## Managing Your Credits

### Tracking Your Usage

Hover over the odometer icon in your navigation bar for a quick glance at your credits. Make sure you're looking at the right account context.

### Detailed Credit Information

Go to **Settings** → **Subscriptions** for a deeper dive into your credit usage and options.

### Handling Excess Usage

Exceeding your monthly allocation? Here's how to handle it:

1. Add a payment method to your account to use additional credits at a fee above your included limit.
2. Set a cap in the **limit extra credits** field to keep your spending in check.

### 📊 Export Credit Usage Data

Teams and users can export detailed credit usage metrics to analyze consumption patterns and optimize their Dune usage.

#### How to Export Usage Data

1. Navigate to your team's usage dashboard
2. Click the **"Export usage"** button
3. Your team's last 30 days of usage data will be downloaded as a CSV file

#### Understanding the Exported Data

The exported CSV file contains comprehensive usage information with the following columns:

| Column                      | Description                                                               |
| --------------------------- | ------------------------------------------------------------------------- |
| timestamp                   | The exact date and time when the credit was consumed                      |
| user\_id                    | Unique identifier for the user who consumed the credits                   |
| user\_name                  | Display name of the user                                                  |
| service                     | The Dune service that consumed credits (e.g., query execution, API calls) |
| record\_type                | Type of usage record                                                      |
| credit\_cost                | Number of credits consumed for this action                                |
| plan                        | Your team's current subscription plan                                     |
| skipped\_quota\_enforcement | Indicates if quota limits were bypassed (true/false)                      |
| query\_id                   | Unique identifier for queries (when applicable)                           |
| metadata                    | Additional contextual information about the usage                         |

#### Use Cases for Exported Data

The exported usage data enables teams to:

• **Track individual user consumption:** Identify which team members are using the most credits\
• **Analyze service usage patterns:** Understand which Dune services consume the most credits\
• **Budget planning:** Use historical data to forecast future credit needs\
• **Optimize queries:** Identify expensive queries using the query\_id field\
• **Compliance and reporting:** Generate usage reports for internal auditing\
• **Cost allocation:** Distribute costs across different teams or projects based on actual usage

#### Data Analysis Tips

• Import the CSV into spreadsheet software or data analysis tools\
• Create pivot tables to summarize usage by user, service, or time period\
• Use the timestamp field to analyze usage patterns over time\
• Filter by query\_id to identify and optimize resource-intensive queries\
• Monitor the credit\_cost column to track spending trends

#### Important Notes

• The export includes the last 30 days of data\
• All timestamps are in UTC\
• Credit costs reflect your team's pricing plan at the time of usage\
• The metadata field may contain additional JSON-formatted information depending on the service


# Video Tutorials
Source: https://docs.dune.com/resources/learning/video-tutorials

Watch step-by-step video guides covering all aspects of Dune

We've created tutorials covering all product surfaces of Dune—from navigating the platform and understanding data tables to creating compelling visualizations and becoming a skilled crypto data analyst.

<Tip>
  New to Dune? Start with the [Getting Started](#getting-started-with-dune) section and work your way through. Already familiar with the basics? Jump to the section that interests you most.
</Tip>

***

## Getting Started with Dune

These videos will help you get up and running with Dune quickly, understanding how data flows through the platform and how to navigate the app effectively.

### Dune Official Getting Started Series

Learn how the data flows and how to navigate the Dune app to create queries, visualizations, and dashboards. This comprehensive playlist covers all the essentials you need to get started.

<iframe title="YouTube video player" />

[View the full playlist on YouTube →](https://www.youtube.com/playlist?list=PLK3b5d4iK10ext4v-GBySekaA8-GP8quD)

***

## Creating and Managing Dashboards

Dashboards are where Dune's content lives and gets discovered. Learn how to create dashboards, add widgets, embed visualizations, and share your work with the community.

<iframe title="YouTube video player" />

**Related docs:** [Create Dashboards](/web-app/dashboards)

***

## Learning DuneSQL and Our Engines

DuneSQL is a Trino fork fine-tuned for blockchain analytics. Learn about its key features including varbinary data types, uint256 support, columnar storage, and materialized views.

<iframe title="YouTube video player" />

**Related docs:** [Query Engine](/query-engine/overview)

***

## Exploring Queries (Views and Matviews)

The Query Editor is where you'll spend most of your time on Dune. Learn how to use its features effectively, including autocomplete, running query selections, and using keyboard shortcuts.

<iframe title="YouTube video player" />

**Related docs:** [Writing Queries](/web-app/query-editor/query-window)

***

## Searching and Contributing to Spellbook

Learn how to contribute to Dune's curated datasets through Spellbook—our community-driven data modeling framework. Discover how curated datasets are built and learn how you can contribute your own data models to help the entire Dune community.

<iframe title="YouTube video player" />

**Related docs:** [Curated Data](/data-catalog/curated/overview)

***

## Understanding Tables (Raw, Decoded, Curated, Views, Uploads)

Explore Dune's comprehensive data catalog to find blockchain data, curated datasets, and community data. This video covers how to browse categories, filter tables, and preview data.

<iframe title="YouTube video player" />

**Related docs:** [Data Catalog](/data-catalog/overview), [Finding Tables](/web-app/query-editor/data-explorer)

***

## Creating Visualizations (Charts)

Visualizations make your data come to life. Learn how to create bar charts, area charts, scatter charts, line charts, pie charts, and mixed graphs from your query results.

<iframe title="YouTube video player" />

**Related docs:** [Create Graphs](/web-app/visualizations/charts-graphs)

***

## Decoding Contracts

Learn how to decode smart contracts on Dune to transform raw blockchain bytecode into human-readable, queryable tables. This video covers how decoding works on Dune and walks through the contract submission process step-by-step.

<iframe title="YouTube video player" />

**Related docs:** [Decoding Contracts](/web-app/decoding/decoding-contracts), [Submit a Contract](/web-app/decoding/short-guide-contract-submission)

***

## SQL API and Developer API

Learn how to build your own custom API endpoints using SQL queries. This video shows how to leverage Dune's API to create tailored data endpoints for your specific needs.

<iframe title="YouTube video player" />

**Related docs:** [API Quickstart](/api-reference/quickstart/results-eg)

***

## Roadmap to Becoming a Top Crypto Data Analyst

Ready to level up? Follow the crypto data analyst roadmap to build your skills and establish yourself as an expert in blockchain analytics.

<iframe title="YouTube video player" />

***

## NEAR + Dune Tutorial

Understand how data flows on the NEAR blockchain—from transactions to actions to receipts. This video explains NEAR's unique transaction lifecycle and sharded architecture.

<iframe title="YouTube video player" />

**Related docs:** [NEAR Data](/data-catalog/near/overview)

***

## More Tutorials

These additional tutorials cover specialized topics not included in the main playlist.

### Query Filters vs Execution Parameters

Understand the two primary methods for fetching data from the Dune API: using filters with scheduled queries for speed, or executing queries with parameters for real-time data. This video explains when to use each approach.

<iframe title="YouTube video player" />

**Related docs:** [Executions Overview](/api-reference/executions/execution-object), [Filtering Results](/api-reference/executions/filtering)

### Building Farcaster Frames with Dune API

Build a Farcaster Frame using TypeScript and the Dune API. This step-by-step guide walks through creating a user recommendation frame, using filters for fast API responses, and deploying your frame.

<iframe title="YouTube video player" />

**Related docs:** [Build a Frame with Dune API](/learning/how-tos/dune-frames)

### Uniswap in 12 Days

A comprehensive 12-part series covering end-to-end Uniswap analysis, including metrics like price impact, TVL, MEV volume, and liquidity stability.

<iframe title="YouTube video player" />

[View the full playlist on YouTube →](https://www.youtube.com/playlist?list=PLK3b5d4iK10cIrN8c_au9RrC0_eBCOyR2)

### Gnosis Safe Point-in-Time Analysis

Learn how to analyze Gnosis Safe (now Safe) wallets with metrics including signers, diversification, and valuations.

<iframe title="YouTube video player" />

***

## Additional Resources

Looking for more learning materials? Check out these resources:

<CardGroup>
  <Card title="Quickstart Guide" icon="rocket" href="/quickstart">
    Dive into Dune in five minutes with our hands-on quickstart tutorial.
  </Card>

  <Card title="Web3 Data Resources" icon="book" href="/learning-resources">
    Curated guides, dashboards, and tips for web3 data analysis.
  </Card>

  <Card title="Discord Community" icon="discord" href="https://discord.gg/ErrzwBz">
    Get help from the community in #beginners and #query-questions channels.
  </Card>
</CardGroup>


# Support & Contact
Source: https://docs.dune.com/resources/support/overview

Get help with Dune and contact our team

# Support & Contact

Need help with Dune? Here's how to get support and reach our team.

## Enterprise Support

Enterprise customers receive dedicated support channels:

* **Dedicated Slack channel** — Direct access to the Dune team
* **Telegram** — Real-time communication with your account team
* **Email** — Priority response from our support team

<Card title="Learn about Enterprise" icon="building" href="/enterprise/data-hub/overview">
  See Enterprise pricing and features →
</Card>

## Email Support

<CardGroup>
  <Card title="General Support" icon="envelope" href="mailto:support@dune.com">
    For general questions and technical issues

    **[support@dune.com](mailto:support@dune.com)**
  </Card>

  <Card title="Sales & Enterprise" icon="building" href="https://dune.com/enterprise">
    For Enterprise pricing and custom solutions

    **Contact Sales →**
  </Card>
</CardGroup>

## Additional Resources

<CardGroup>
  <Card title="FAQs" icon="circle-question" href="/learning/how-tos/pricing-faqs">
    Common questions about pricing, credits, and plans
  </Card>

  <Card title="Video Tutorials" icon="video" href="/resources/learning/video-tutorials">
    Step-by-step video guides for using Dune
  </Card>

  <Card title="Migrating from Flipside" icon="arrow-right-arrow-left" href="/learning/flipside-migration-guide">
    Guide for teams moving from Flipside to Dune
  </Card>

  <Card title="Bug Bounty" icon="bug" href="/web-app/bug-bounty">
    Report security vulnerabilities
  </Card>
</CardGroup>

## Community Support

<CardGroup>
  <Card title="Discord" icon="discord" href="https://discord.gg/ErrzwBz">
    Join our Discord community for real-time help from the community and Dune team

    * `#🐥︱beginners` — New to Dune? Start here
    * `#🙋︱query-questions` — Get help with SQL and queries
  </Card>

  <Card title="Telegram" icon="telegram" href="https://t.me/dune_updates">
    Product updates, announcements, and a direct line for potential customers exploring Dune
  </Card>
</CardGroup>

## Social

Follow us for updates and community content:

* **X/Twitter:** [@dune](https://x.com/dune)
* **LinkedIn:** [Dune](https://www.linkedin.com/company/dune-analytics)
* **YouTube:** [Dune](https://www.youtube.com/@dunecom)
* **GitHub:** [duneanalytics](https://github.com/duneanalytics)


# Web3 Data Resources
Source: https://docs.dune.com/resources/web3-data-resources

Navigate the Ever-Expanding World of Web3 Data with Ease, from Beginners to Experts

# Web3 Data Resources

After you've gone through the quickstart guide, you'll be ready to start learning how to navigate the Web3 data analytics space.

Analyzing protocols in web3 is both really easy and hard. It's really easy because everything is transparent and standardized - a deployed contract has a set of functions and events that are pretty much immutable. However, it's an ever-expanding data arena as new protocols, tokens, and wallets join the fray.

To build your reputation as an expert analyst, you must stay centered on what you want to analyze and what metrics you want to present.

## Dune Tutorials

### Metrics-Driven Analysis

**Video Series:** Delve deep with our end-to-end video series guides:

* [Uniswap in 12 Days](https://www.youtube.com/playlist?list=PLK3b5d4iK10cIrN8c_au9RrC0_eBCOyR2) (includes metrics like price impact, TVL, MEV volume, liquidity stability)
* [Gnosis Safe Point-in-Time](https://www.youtube.com/watch?v=S-cctFmR828) (includes metrics like signers, diversification, and valuations)

**Dashboards for Insights:**

* To understand token trends and contexts, check out ERC20 and NFT dashboards
* To understand wallet/user segments, you'll need to leverage labels to enhance your analysis

Once you have metrics and also understand the underlying tokens and users, it will start to become clear what that real narrative is. Try and pull together a few insights, and then create a compelling dashboard and story around them.

<Warning>
  Don't try too hard to capture everything at once - it will become overwhelming for both you and those you share it with.
</Warning>

## Analysis Tips

* **Start with a solid foundation.** Master basic SQL and blockchain concepts.
* **Scope Your Work:** When looking into a protocol, you'll need to understand the contract architecture and context. That starts with functions, events, and wallet overviews.

Remember that no protocol lives in isolation - there is always some mix of onchain events happening. That could be some new airdrop, a new upstream/downstream protocol integration, large whales making moves, governance changes in protocol parameters, and more.

Once you have a solid understanding of protocol history in usage, user, and integration trends, you're ready to start building some metrics.

## Engage with the Community

When you're done, be sure to share your work in the Discord `#📺︱show-your-work` channel and on Twitter tagging [@dune](https://twitter.com/dune).

We'll be sure to give great analysts a boost! Web3 is all about connecting with communities - your queries and dashboards will do nothing if you don't share it around.


# Set Up Alerts
Source: https://docs.dune.com/web-app/alerts

Configure email and webhook notifications that trigger each time a scheduled query runs.

Alerts allows users to set notifications for a scheduled query. These notifications are triggered each time the query runs. Supported delivery methods include:

* **Email:** Multiple email addresses can be added.
* **Webhooks:** Alerts can be sent to a specified callback URL, including Slack.

## Setup

### Accessing Alerts

<div>
  <iframe />
</div>

To use Alerts, follow these steps:

1. Open a saved query that you own.
2. Click the "Schedule" button.
3. Configure the query schedule.
4. Activate the Alerts option.
5. Configure the alert delivery method.
6. Save the schedule.
7. Every time the query runs, the alert will be triggered.

### Alert Timing

Alerts are triggered after query execution. Delays may occur due to factors like query complexity or system queues. Note that retry mechanisms for failed deliveries are not yet implemented.

<Warning>Alerts are not recommended for time-sensitive or critical applications at this stage.</Warning>

## Alert Content

### Email Alerts

Email alerts include screenshots of the visualizations you have defined. If you have defined no visualizations, we include a screenshot of the query results by default. Here's an example:

<img alt="Default email alert" />

If you have defined a visualization, we will include it instead of the table, like this:

<img alt="Email Alert with visualization" />

If your query contains multiple visualizations, or table visualizations (outside the default "Query results" table), they will all be included, such as here:

<img alt="Email Alert with multiple visualizations" />

### Webhook Alerts

Webhook alerts adhere to the following schema:

```jsx theme={null}
{
  message: string,
  query_result: {
    execution_id: string;
    query_id: number;
    state: string;
    submitted_at: string;
    expires_at: string;
    execution_started_at: string;
    execution_ended_at: string;
    result: {
      data_uri: string;
      metadata: {
        column_names: string[];
        result_set_bytes: number;
        total_row_count: number;
        datapoint_count: number;
        pending_time_millis: number;
        execution_time_millis: number;
      };
    };
  },
  visualizations: [
    {
      title: string;
      image_url: string;
    }
  ]
}
```

Here is an example corresponding to the last email example shared earlier:

```
{
  "message": "Query ETH SMA alert was submitted for execution at Wed, 13 Dec 2023 13:42:40 GMT by your query schedule and it was successfully executed with a non-empty result.\nYou can check its latest result here: https://dune.com/queries/3137182?utm_source=webhook&utm_campaign=alerts",
  "query_result": {
    "execution_id": "01HHHPMKG6NBY0B04A36TS3AQH",
    "query_id": 3137182,
    "state": "QUERY_STATE_COMPLETED",
    "submitted_at": "2023-12-13T13:42:40Z",
    "expires_at": "2024-03-12T13:42:48Z",
    "execution_started_at": "2023-12-13T13:42:40Z",
    "execution_ended_at": "2023-12-13T13:42:48Z",
    "result": {
      "data_uri": "https://api.dune.com/api-referencev1/execution/01HHHPMKG6NBY0B04A36TS3AQH/results",
      "metadata": {
        "column_names": [
          "day",
          "avg_price",
          "sma_20",
          "sma_50",
          "sma_100",
          "sma_200"
        ],
        "result_set_bytes": 10710,
        "total_row_count": 91,
        "datapoint_count": 546,
        "pending_time_millis": 13,
        "execution_time_millis": 8038
      }
    }
  },
  "visualizations": [
    {
      "title": "SMA",
      "image_url": "https://prod-dune-media.s3.eu-west-1.amazonaws.com/screenshots/3137182/01HHHPMKG6NBY0B04A36TS3AQH/5232261.png"
    },
    {
      "title": "Counter",
      "image_url": "https://prod-dune-media.s3.eu-west-1.amazonaws.com/screenshots/3137182/01HHHPMKG6NBY0B04A36TS3AQH/5451006.png"
    },
    {
      "title": "Last days of data",
      "image_url": "https://prod-dune-media.s3.eu-west-1.amazonaws.com/screenshots/3137182/01HHHPMKG6NBY0B04A36TS3AQH/5451008.png"
    }
  ]
}
```

Validation of the webhook format can be done at [Webhook.site](https://webhook.site/). You can easily test it out by triggering manual deliveries by clicking the Manual trigger link below the URL field.

## Integration with Third-Party Apps

### Slack Support via Webhook

Following these simple steps you have get query results posted directly in Slack at your desired frequency.

1. Click Create `Create New App` on your [Slack app page](https://api.slack.com/apps).
2. Choose `From scratch` and give your alert a name, pick the workspace and click `Create App`
3. Then click "Incoming Webhooks" and activate with the top right toggle.
4. Click `Add New Webhook to Workspace` at the bottom of the page.
5. Select the Slack channel you want the alert to go to.
6. Copy the Slack Webhook URL and paste it into the Dune Alert configuration.
7. The help text below the field should indicate that a Slack URL has been detected:

<img alt="Slack Setup" />

Once saved, you will start receiving messages on Slack. Here is an example of how it looks:

<img alt="Slack message" />

### Zapier Integration

[Zapier](https://zapier.com/) is a third party solution that supports building integrations between different software solutions without writing any code. With it you can build advanced workflows that relay data between Dune and your favorite work tools.

We currently offer an experimental [Zapier app](https://zapier.com/developer/public-invite/194504/2174c6b998748b657f28dab4097f3e80/) to support connecting Dune with thousands of other tools via Zapier.

To set it up, follow these steps:

1. Accept the invite to use our private Zapier app via [this link](https://zapier.com/developer/public-invite/194504/2174c6b998748b657f28dab4097f3e80/).
2. Create a new zap, with a [Webhook trigger](https://zapier.com/apps/webhook/integrations).
3. Copy the webhook URL provided by Zapier's Webhook trigger, and paste it in the Dune webhook URL field.
4. Now, on Zapier you can click Test to test that the webhook works.
5. Trigger a manual hook request from the Alerts configuration form to test it out, and it should show up on Zapier.
   1. If you want to relay screenshots to other tools, the screenshots will be in the payload.
   2. If you want to relay query results, the Dune Zapier App includes an action to fetch a query's latest results by query id, which will allow you to easily fetch query results.

This is where you can trigger manual hook deliveries:

<img alt="Manual hook" />

Your setup on Zapier should look something like this:

<img alt="Zapier zap" />

## Known Issues and Solutions

1. **Manual Alert Triggering:** Currently, manual triggering is only available for webhooks.

   1. We're planning to add it to Email and Slack. In the meantime, you can set your query on a 15-minute schedule for quicker testing.

2. **No results in webhook:** Instead of including query results in the callback, the webhook payload includes a URL to fetch the query's results in case you need to action on them.

   1. We do not include datapoints in the hook callback in order to prevent unwanted credit spend on data exports.
   2. We're open to feedback on changing this behavior. If you have thoughts, let us know.

## Feedback

Feedback can be provided through the Alerts Beta Telegram channel.

[Join the channel](https://t.me/+bt5J1QlJ3_FhMDU0)

## Acknowledgement

Thank you to everyone that participated in our beta testing program. Your feedback has been essential for improving this feature.

***


# Bug Bounty Submission
Source: https://docs.dune.com/web-app/bug-bounty

Found a security issue within our application?

If you believe you have discovered a security issue within our web application or API, we highly encourage you to report it to us. We appreciate the efforts of ethical hackers and reward those who responsibly disclose vulnerabilities.

Please submit any vulnerability or bug discovered via this form: [https://forms.gle/NTK3FGMYRsAWKkY4A](https://forms.gle/NTK3FGMYRsAWKkY4A)

Please note, it is essential to provide a video or script reproducing the issue. This greatly speeds up our understanding of the issue.

We do not accept email submissions of vulnerabilities. All reports must go through the form above to ensure they are tracked and processed appropriately.

Due to the high volume of submissions we receive, we only provide responses to reports that result in a payout.

If you do not hear back from us within one month, you can assume that your submission has been classified as informational or duplicate.

Emailing us for updates will not speed up the review process, and repeated inquiries may result in disqualification.

We value transparency and will work with you to resolve any legitimate issues found. Your efforts help us maintain the security and trustworthiness of our platform. Thank you for your contribution to our security.

### Bounty Sizes

Bounty sizes are determined at Dune's sole discretion. We consider the severity and impact of the vulnerability as well as the quality of the submission. The rubric we use to determine bug bounties is as follows:

| Level       | Mental model                                       | Example                                                                                                                                                                                                                                                                                                                                                   | Maximum Bug Bounty |
| ----------- | -------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ |
| 5. Severe   | The platform is compromised                        | Remote code execution on Dune-operated servers · Access to internal infrastructure, secrets, or databases · Mass extraction or destruction of customer data across tenants · SQL injection enabling cross-tenant data access · Theft of customer funds                                                                                                    | Let's talk         |
| 4. Critical | Any user can be compromised                        | Full account takeover of arbitrary users · Exploiting application or API endpoints to read another user's restricted data · Privilege escalation within the application (e.g. non-admin gaining admin rights on a team they don't own)                                                                                                                    | Up to \$5,000      |
| 3. High     | A specific user is compromised, with bounded scope | SQL injection enabling exfiltration of another user's data · Authentication bypass with limited or single-account scope (e.g. bypassing a specific check rather than logging in as anyone) · Ability to delete or manipulate another user's data or analytics · Auth/OAuth flaws enabling theft of authorization codes or session tokens from other users | Up to \$2,500      |
| 2. Medium   | A user is impacted with limited reach              | Stored or reflected cross-site scripting (XSS) with script execution in an authenticated context · CSRF affecting user accounts · Authenticated IDOR exposing other users' non-public data · Business-logic flaws with a realistic abuse path beyond plan-limit bypasses                                                                                  | Up to \$1,000      |
| 1. Info     | No demonstrated user impact                        | Suggestions, hardening recommendations, security misconfigurations without a demonstrated impact, server info or stack traces with no path to exploit                                                                                                                                                                                                     | No bounty          |

### Duplicate Submissions Policy

We value all security research, but we do not provide rewards for submissions that cover known issues already reported by other researchers or internally identified by our team. If your report is a duplicate, we will notify you of the status and appreciate your effort, but no bounty will be issued.

### Variations and Bypasses of Previously Reported Issues

If you discover a bypass or a variation of a previously reported vulnerability, this will typically be considered part of the same issue and not eligible for an additional full bounty. This applies especially to cases where:

* A fix for a previously reported issue was incomplete or could be bypassed
* The vulnerability uses a similar technique with minor variations
* The vulnerability affects the same endpoint or feature

We encourage researchers to thoroughly test our fixes and report bypasses, but these will generally be bundled with the original report for bounty considerations. In some cases, at our discretion, we may offer a smaller reward for significant bypasses that require substantial new techniques.

### Out of Scope

The following classes of report are considered out of scope or below the payment threshold and will not be rewarded:

* **Externally leaked credentials.** Issues stemming from stolen or compromised credentials (e.g. through malware, phishing, or credentials surfaced via third-party leak databases or web archives) do not qualify as vulnerabilities in our systems.
* **Business-logic limit bypasses.** Race conditions or other techniques used to exceed free-plan limits (team count, private content count, member count, etc.) without a security impact.
* **Reflected text or HTML in non-sensitive contexts** without script execution (often referred to as "content spoofing").
* **Public assets and installer scripts.** Files we publish as public artifacts (installers, SDKs, documentation, marketing content) are intentionally public.
* **Session-handling preferences** that do not enable cross-user access (e.g. session lifetime, lack of forced re-login on profile changes).
* **Missing security headers, TLS configuration concerns, and best-practice recommendations** without a demonstrated exploit path.
* **Reports generated by automated scanners** without verification or a working proof of concept.

### Bug Bounty Rules and Safe Harbor

By participating in this program, you agree to abide by the following rules to help us maintain a secure environment for all users.

* **Safe Harbor:** We authorize participants to test and report vulnerabilities in our systems, provided they act with due care and in good faith to minimize harm or disruption to our users and services. Actions conducted in compliance with the rules and within the scope of this program are considered authorized, and we will not pursue legal action or report you for such activities. If a third party challenges your research, we will confirm that it was authorized under this program. This protection applies only to our systems and does not extend to third-party property. If you are unsure about the scope or your actions, please contact us for clarification.
* **Ethical Conduct:** Participants must adhere to the highest standards of ethical, good-faith behavior. We reserve the right to disqualify submissions from researchers who do not follow these rules or engage in unethical behavior.
* **Responsible Reporting:** Report findings directly to us via the designated form and provide sufficient details to reproduce and address the issue. Do not publicly disclose vulnerabilities before we have resolved them.
* **No Social Engineering:** Do not engage in social engineering or phishing attack on our users or employees.
* **No Unauthorized Access to Data:** Do not access, modify, or delete data that does not belong to you. Use separate test accounts.
* **Original Work Only:** All submissions must be the original work of the researcher. Submissions generated by AI or automation tools, or identical to previously submitted reports, will be disqualified. Researchers are responsible for thoroughly verifying their findings before submission to ensure their validity and uniqueness.
* **No Partnership:** Participation in this program does not create an employment or partnership relationship. Rewards are discretionary and provided without further obligations or benefits.
* **Legal Compliance:** Participation must not violate any applicable laws or regulations. Participants are responsible for reporting and paying any taxes owed on rewards received under this program. We do not withhold taxes or provide tax advice, but upon request, we may provide basic information about payments to assist with tax obligations.
* **Sanctions:** Rewards will not be issued to participants located in or associated with countries or regions subject to U.S., EU, or UN sanctions.


# Build Dashboards
Source: https://docs.dune.com/web-app/dashboards

Create, customize, and schedule interactive dashboards to present your query results and visualizations.

<Tip>
  Watch our [dashboard tutorial video](/resources/learning/video-tutorials#building-dashboards) to see how to build dashboards step-by-step.
</Tip>

Dashboards on Dune consist of widgets. Widgets can either be Visualizations or Text. It is also possible to embed images or GIFs inside of the text widget.

You can freely resize every widget to match the layout you want to create.

## Creating a Dashboard

<div>
  <iframe title="Create a dashboard and add a query visualization" />
</div>

**To create a dashboard on Dune:**

1. Use the create menu and pick "New Dashboard"
2. Give your Dashboard a name
3. Click on "Save and Open"
4. You are now inside of your Dashboard
5. Enter the edit mode by clicking on the "Edit" button in the top right corner
6. Add widgets by clicking on the "Add Widget" button in the top right corner
7. Pick the widget you want to add
8. You can now resize the widget by dragging the bottom right corner
9. You can also move the widget by dragging it around
10. Click on the "Save" button in the top right corner to save your changes

The initial name that you give to your Dashboard will also be the URL slug. You can't change the URL slug afterwards, so be mindful of the name you choose. Changing the Dashboard's display name is always possible though.

## Add Widgets from the Query Editor

You can add widgets directly from the Query Editor.

<div>
  <iframe title="Add Widgets to a Dashboard from the Query Editor" />
</div>

**To add widgets from the query editor:**

1. Navigate to the query Editor
2. Pick the Visualization you want to add to your Dashboard
3. Click on the "Add to Dashboard" button
4. Choose the Dashboard you want to add the Visualization to
5. The Visualization is now added to your Dashboard

The widget will be added to the bottom of your Dashboard. You can move it around and resize it as you like.

## Adding Text Widget

You can add text widgets to your dashboard.

Text widgets support a subset of Markdown. You can manipulate text and embed images and GIFs.

## Embedding Images and GIFs

Text boxes can also be used to embed images or GIFs into your Dashboard.

The Syntax for embedding images is:

```markdown theme={null}
![alt text](image url)
```

Since you can't store images locally on our servers, you need to upload your images somewhere else or find the raw file somewhere on the internet.

In practice this might look like this:

```markdown theme={null}
![text](https://pbs.twimg.com/media/FEWVLQwWUAQcqLY?format=jpg&name=medium)
```

You can resize the image by simply resizing the widget it is contained in.

You can combine images and text in one widget.

## Keeping your Dashboard up to date

Dashboards on Dune are not updated automatically. You can refresh your Dashboard by clicking on the "Run" button in the top right corner.

<div>
  <iframe title="Run all queries to refresh a Dune dashboard fork" />
</div>

Alternatively, you can schedule your Dashboard to be refreshed in regular intervals.

<div>
  <iframe title="Schedule a Dune dashboard to refresh at a time interval" />
</div>

To schedule a dashboard:

1. Click on the "clock" icon in the top right corner
2. Select the frequency you want your Dashboard to be refreshed
3. Select the execution tier you want to use
4. Click on "Save"

You can also schedule individual queries to be refreshed. This is useful if you have a Dashboard with many queries and only want to refresh a few of them. Learn more about scheduling queries [here](/web-app/query-editor/query-scheduler).

## Sharing your Dashboard

<Note>
  To learn how to share, embed, and control access to your dashboards, visit the [Share and Embed](/web-app/share) page.
</Note>


# Submission Best Practices
Source: https://docs.dune.com/web-app/decoding/best-practices

Best practices for submitting smart contracts for decoding on Dune, covering all contract types and patterns.

# Dune Contract Decoding Best Practices Guide

## Introduction

This comprehensive guide covers best practices for decoding smart contracts on Dune. Whether you're dealing with simple single-chain contracts or complex multi-chain factory deployments, this guide will help you submit contracts correctly for optimal decoding.

### Before You Begin

* **Reference documentation @** [Dune Docs | Decoding Contracts](https://docs.dune.com/web-app/decoding/decoding-contracts)
* **Leverage AI assistance**: Use the "Ask AI" feature throughout Dune documentation for quick help

<img alt="Ask AI" />

## Quick Reference: Submission Checklist

Before submitting any contract:

* Identify the contract type (single, created by a factory, proxy)
* Locate the correct ABI (implementation, not proxy)
  * For more information, check this [Documentation by OpenZeppelin](https://docs.openzeppelin.com/contracts/4.x/api/proxy)
* If submitting for multiple chains use a multichain explorer like [Blockscout](https://www.blockscout.com/) to determine which chains a contract has been deployed on (**Please note:** if an address exists on another chain that doesn't mean that it is a contract on that chain, so make sure to validate this by ensuring that the address is a contract on that specific chain)
* Check for [identical bytecode](https://etherscan.io/find-similar-contracts) across addresses
* Document any special patterns or versions

**Dune Contract Submission Page:** [https://dune.com/contracts/new](https://dune.com/contracts/new)

## Quick Decision Tree

<Tip>
  <strong>How to use this decision tree:</strong> Start at Step 1 and follow the YES/NO paths. Each step will guide you to the correct contract submission method. Use the links and callouts for extra help!
</Tip>

<Accordion title="Step 1: Is your contract a proxy?">
  [Check using Etherscan Proxy Checker →](https://etherscan.io/proxyContractChecker)

  <Check>
    **If YES:**

    * Use implementation ABI at proxy address
    * Submit the proxy address
    * Use the implementation contract's ABI (not the proxy's ABI)
    * The implementation contains the actual business logic
  </Check>

  <Info>
    **If NO:**
    → Go to Step 2
  </Info>
</Accordion>

<Accordion title="Step 2: Is it created by a factory?">
  [Check Dune documentation for details →](https://docs.dune.com/web-app/decoding/decoding-contracts)

  <Check>
    **If YES:**

    * Enable "Decode other contracts created by the same factory" flags
    * Submit the ABI for the created contracts, NOT the factory ABI
    * Mark as factory-deployed in submission
    * Include sample addresses of created contracts
  </Check>

  <Info>
    **If NO:**
    → Go to Step 3
  </Info>
</Accordion>

<Accordion title="Step 3: Do all instances share identical bytecode?">
  [Verify using Etherscan Similar Contracts →](https://etherscan.io/find-similar-contracts)

  <Check>
    **If YES:**

    * Enable bytecode matching
    * Submit one ABI that covers all instances
    * Check the "Enable bytecode matching" checkbox
    * Note the shared bytecode pattern
  </Check>

  <Warning>
    **If NO:**

    * Standard submission process
    * Submit the contract's ABI with the specific contract address and chain
    * This is the most common scenario
    * If unsure, always default to Standard Submission
  </Warning>
</Accordion>

## Contract Decoding Scenarios

### Single Smart Contract on Single Chain

**Definition**: One contract deployed to one blockchain

**How to Submit:**

* Submit the contract's ABI with the specific contract address and chain
* Straightforward process with no special considerations

**Example**: Ethereum Name Service (ENS) Registry

* Contract: `0x00000000000C2E074eC69A0dFb2997BA6C7d2e1e` (Ethereum only)
* Action: Submit ENS Registry ABI for this specific address on Ethereum

### Single Contract on Multiple Chains

**Definition**: Same contract deployed across different blockchains

**How to Submit:**

* Submit the same ABI once
* Specify all chains where it's deployed
* Use the same submission if addresses match across chains

**Example**: LayerZero Endpoint

* Contract: `0x66A71Dcef29A0fFBDBE3c6a460a3B5BC225Cd675` (multiple chains)
* Action: Submit as "Submit as multiple chains" with same ABI for all chains with this address and select the chains

<Tip>
  Use [Blockscout](https://www.blockscout.com/) to verify deployments. It's okay if you miss a chain initially—you can always add more chains later. To add more chains later go to the [Contract Submission Page](https://dune.com/contracts/new). If it is a single chain select the chain, add the address, and submit as normal. If there are multiple chains, select the "Submit on Multiple Chains" in the dropdown and include all the new chains of the contract, and submit the contracts.
</Tip>

### Factory-Deployed Contracts (Single Chain)

**Definition**: A factory contract creates multiple instances of the same contract type

**How to Submit:**

* Submit the ABI for the **created contracts**, NOT the factory ABI
* Mark as factory-deployed in submission
* Include sample addresses of created contracts

**Example**: Uniswap V2 Pairs on Ethereum

* Factory: `0x5C69bEe701ef814a2B6a3EDD4B1652CB9cc5aA6f`
* Sample Pair: `0xB4e16d0168e52d35CaCD2c6185b44281Ec28C9Dc` (USDC/ETH)
* Action: Submit UniswapV2Pair contract & ABI (not factory ABI)
* **Tip:** If an ABI isn't verified for certain addresses, the ABI will be the same across chains in the same project (ie., UniswapV2Pair ABI is going to be the same on all EVM chains regardless of the address)

### Factory-Deployed Contracts (Multiple Chains)

**Definition:** Factory pattern deployed across multiple chains

**How to Submit:**

* Submit the created contract's ABI once
* Select all chains where factories exist
* Check the "Decode other contracts deployed by the same factory" checkbox
* The submission will detect factory-created instances on each selected chain

**Example:** Uniswap V2 Factory Pattern

* Ethereum Factory: `0x5C69bEe701ef814a2B6a3EDD4B1652CB9cc5aA6f`
* Polygon Factory: `0x5757371414417b8C6CAad45bAeF941aBc7d3Ab32`
* Arbitrum Factory: `0xf1D7CC64Fb4452F05c498126312eBE29f30Fbcf9`
* Action: Submit UniswapV2Pair ABI once, select all three chains, enable factory flag

**Note:** Dune will automatically find all pairs created by each chain's factory

### Contracts with Identical Bytecode (Single Chain)

**Definition**: Multiple contracts with identical bytecode but different addresses

**How to Submit:**

* Submit one ABI that covers all instances
* Check the "Enable bytecode matching" checkbox
* Note the shared bytecode pattern

**Example**: Compound V2 cToken Contracts

* cUSDC: `0x39AA39c021dfbaE8faC545936693aC917d5E7563`
* cETH: `0x4Ddc2D193948926D02f9B1fE9e1daa0718270ED5`
* Action: One cToken ABI submission covers all

### Contracts with Identical Bytecode (Across Multiple Chains)

**Definition**: Same bytecode deployed across multiple chains

<Warning>
  Use bytecode matching with extreme caution when submitting across multiple chains! This feature can produce many false positives, as different contracts may have identical bytecode but have completely different purposes or contexts. Only use when you're certain the contracts are truly identical implementations.
</Warning>

**How to Submit:**

* Submit one ABI specifying all chains and addresses
* Check the "Enable bytecode matching" checkbox

**Example**: Safe Singleton 1.3.0

* Address: `0xd9Db270c1B5E3Bd161E8c8503c55cEABeE709552` (multiple chains)
* Action: One Safe ABI submission for all chains

## Proxy Contract Patterns

### Basic Proxy Rules

**Critical**: Always use the **implementation contract's ABI**, not the proxy's ABI

* Submit the proxy address
* Decode using the implementation's functions
* The implementation contains the actual business logic
* To check if your contract is a proxy, you can visit a block explorer like [etherscan.io](http://etherscan.io) and click into the "Contract" section. If you see "Read as Proxy" and "Write as Proxy" as the image below then select the ABI of the implementation contract.
* For more resources:
  * [https://info.etherscan.com/what-is-proxy-contract/](https://info.etherscan.com/what-is-proxy-contract/)
  * [https://etherscan.io/proxyContractChecker](https://etherscan.io/proxyContractChecker)

<img alt="" />

### Proxy Contract (Single Chain)

**Definition**: Proxy that delegates calls to an implementation

**Example**: USDC Token on Ethereum

* Proxy: `0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48`
* Action: Use implementation ABI, submit proxy address

### Proxy Contract (Multiple Chains)

**Definition**: Same proxy pattern across chains

**How to Submit:**

* Use implementation ABI
* Specify all proxy addresses across chains
* Include implementation addresses in notes

## Advanced Patterns

### Upgradeable Proxies

#### Transparent Upgradeable Proxy

**Challenge**: Implementation changes over time. More info [here](https://www.rareskills.io/post/transparent-upgradeable-proxy).

**How to Submit:**

* **Use the Proxy Contract Address:** Submit using the proxy contract's address (not the implementation contract address)
* **Use the Implementation Contract's ABI:** You must provide the ABI of the implementation contract (not the proxy contract's ABI)
* Submit Initial implementation then it is best to:
  * Resubmit each implementation version as "upgrade the ABI of a contract" with the new implementation ABI each time.
* Use the same name for all implementations (e.g., just "uniswap\_v3" for all versions)
  * The system will handle merging and version tracking automatically
* Track upgrade events if needed

**Example**: Uniswap V3 Upgradeable Proxy

* Proxy: `0xEe6A57eC80ea46401049E92587E52f5Ec1c24785`
* Implementation V1: `0x0882477e7895bdc5cea7cb1552ed914ab157fe56`

#### Beacon Proxy

**Definition**: Multiple proxies point to a beacon holding the implementation. More info [here](https://www.rareskills.io/post/beacon-proxy).

**How to Submit:**

* **Contract Address:** Use the Beacon proxy contract address (the actual proxy that users interact with)
* **Submit beacon's implementation ABI**: Use the implementation contract's ABI (not the beacon or proxy ABI)
* For additional beacon proxies with the same implementation:
  * Use the same project name and contract name
  * Check "Are there several instances of this contract?" if they have identical bytecode
  * This will consolidate them into the same decoded tables
* All proxies decode using same ABI
* Note the beacon pattern in comments

#### Diamond Proxy (EIP-2535)

**Definition**: Modular proxy with multiple implementation contracts (facets), more info [here](https://eips.ethereum.org/EIPS/eip-2535).

**How to Submit:**

* **Option A**: Submit each facet's ABI separately as upgrades
  * Submit the first facet ABI as a new contract
  * Submit additional facet ABIs as "upgrades" to the same contract
  * Use the same project name and contract name for all submissions
  * Dune will merge the ABIs in the background
* **Option B**: Create one combined ABI with all facet functions
  * Merge all facet ABIs into a single file before submission
  * Submit once as a new contract

**Important Notes:**

* Each facet typically has its own purpose (e.g., deposits, payments, lending)
* Even though facets have distinct names, submit all under the **same contract name**
* Query by event/function name to distinguish between facets
* Facets can be updated independently - submit new versions as upgrades
* **Contact Dune support** via Slack (For Enterprise Customers), Telegram (Paid Customers), [Discord](https://discord.com/invite/ErrzwBz), or email [support@dune.com](mailto:support@dune.com) if you have questions about the submission process

### Factory Variations

#### Multi-Type Factories

**Definition**: Factory deploys different contract types

**How to Submit:**

* Submit separate contracts individually, in this case **do NOT check "is created by factory"**
* Submit separate ABIs for each contract type
* TLDR; you will need to submit each contract individually
* Clear naming convention for each type
* Document the factory's capabilities
* Reach out to Dune Support if you have any questions

#### Minimal Proxy (EIP-1167)

**Definition**: This standard specifies a minimal bytecode implementation that delegates all calls to a known, fixed address, more info [here](https://eips.ethereum.org/EIPS/eip-1167).

**How to Submit:**

* **Address:** Use minimal proxy contract address
* **ABI:** Submit implementation (master/template) contract ABI
* For EIP-1167 minimal proxies that have multiple clones deployed from the same factory:
  * Check the "Are there several instances of this contract?" box during submission
  * Dune only considers a contract a dynamic instance if the bytecode matches 100%
* Note the clone pattern

**Example**: Gnosis Safe Clones

* Master: `0xd9Db270c1B5E3Bd161E8c8503c55cEABeE709552`
* All clones use master's ABI

### Version Management

#### Multiple ABI Versions

**Challenge**: Different versions active simultaneously

**How to Submit:**

* Submit each version separately
  * First submission, submit normally, then each submission afterwards would need to be a resubmission with the upgraded ABI
* Document version differences

#### Gradual Cross-Chain Rollouts

**Challenge**: Slight ABI differences across chains

**How to Submit:**

* Start with latest/most complete ABI
* Add chains as they deploy
* Note any chain-specific differences

## Edge Cases & Special Situations

### Self-Destructed and Redeployed Contracts

**Situation**: Same address, different bytecode

**How to Submit:**

* Resubmit new ABI with updated deployment info
* Clearly note the redeployment
* Include destruction/redeployment dates

### Factory-Deployed Proxies

**Situation**: Factory creates proxies, not implementations

**How to Submit:**

* The address to use would be the address of one of the created proxies
* Submit the proxy's implementation ABI
* Note both factory and proxy patterns
* Clear documentation is crucial

## Common Mistakes to Avoid

1. **Submitting Factory ABIs**: Always submit the created contract's ABI, not the factory's
2. **Using Proxy ABIs**: Always use implementation ABIs for proxy contracts
3. **Missing Chains**: Use tools like Blockscout to find all deployments
4. **Poor Naming**: Use descriptive names that include version/type info
5. **Incomplete Documentation**: Always note special patterns or deployment methods

## Best Practices Summary

1. **Start Simple**: Begin with one chain, expand gradually
2. **Focus on Logic**: Always decode using the contract with actual business logic
3. **Document Everything**: Use submission comments for complex patterns
4. **Version Clearly**: Use descriptive naming for different versions/types
5. **Verify Thoroughly**: Double-check addresses and bytecode matches
6. **Think User-First**: Make contract interactions readable regardless of complexity

## Troubleshooting Tips

* **Can't find all deployments?** Start with what you have—you can add more chains later
* **Unsure about bytecode?** Use Etherscan's "Similar Contracts" feature
* **Complex proxy pattern?** Focus on the final implementation that executes
* **Factory creating variants?** Submit separate ABIs for each variant type

Remember: The goal is to make contract interactions readable and queryable. When in doubt, prioritize clarity and usability over technical perfection. You can always refine your submission later!

## Additional

## Check Your Work

### Check Contract Submissions for Decoding

Use this Dune query to verify your contract submissions and check decoding status: [Contract Submission Checker](https://dune.com/queries/4093792)

### Check if Contract is decoded on the specific blockchain

```sql theme={null}
select *
from {blockchain}.contracts
where address = 0x...
```

### Verify the table exists and has data

```sql theme={null}
/* Verify the table exists and has data */
SELECT
    COUNT(*) AS total_rows,
    MIN(evt_block_time) AS first_event,
    MAX(evt_block_time) AS latest_event
FROM eigenlayer_ethereum.DelegationManager_evt_OperatorSharesIncreased
-- replace above line with {your_project_ethereum.yourcontract_evt_yourevent};
```

**Please note:** We display the full list of tables to be created in the submission form

### Check all columns are properly decoded

```sql theme={null}
-- Check all columns are properly decoded
DESCRIBE eigenlayer_ethereum.DelegationManager_evt_OperatorSharesIncreased;
-- replace above line with {your_project_ethereum.yourcontract_evt_yourevent};

-- Or get column info
-- Ethereum
SELECT 'ethereum' as chain, column_name, data_type
FROM information_schema.columns
WHERE table_name = 'factory_evt_poolcreated'
AND table_schema = 'uniswap_v3_ethereum'
UNION ALL
-- Add other chains as needed
SELECT 'worldchain' as chain, column_name, data_type
FROM information_schema.columns
WHERE table_name = 'uniswapv3factory_evt_poolcreated'
AND table_schema = 'uniswap_worldchain';
```

### Expected Tables and Event Types

* Search the contract in the data explorer to view both the tables and events related to the contract

### When NOT to Decode

**Skip These Contracts:**

* Pure libraries (no deployable bytecode)
* Contracts with only view functions
* Simple forwarder/relay contracts
* Contracts that only emit standard ERC20/721 events
* Test/deprecated contracts with no usage
* Contracts with no transactions are not needed to decode

**Consider Carefully:**

* Governance contracts (usually low activity)
* Admin/owner contracts (minimal events)
* Price oracle contracts (mostly reads)

## Remember

* One ABI can decode thousands of contracts
* Namespaces can't be merged or moved
* 100% bytecode match is strict
* Factory pattern and bytecode finds future contracts too
* Plan namespace structure before submitting


# How Contract Decoding Works
Source: https://docs.dune.com/web-app/decoding/decoding-contracts

Dune decodes smart contract bytecode into human-readable, queryable data tables using contract ABIs.

**Dune's extensive catalog of decoded smart contracts are driven by our analysts. Our decoding process empowers our community to submit the data and build the tables that they'd like to query on Dune!**

But what does decoding mean? Blockchain transaction data starts as bytecode, a low level programming language that can be read by machines. Using the ABI (Application Binary Interface) that is specific to each contract, we translate that bytecode into query-able data tables.

<CardGroup>
  <Card title="Explore decoded data" icon="table" href="/data-catalog/evm/ethereum/decoded/overview" />
</CardGroup>

# A. The Lifecycle of Decoding

## Step 1: Submission

Our decoding process begins with our [contract submission page](https://dune.com/contracts/new).

<img alt="" />

To successfully submit a contract, you will need four pieces of information:

1. **Blockchain**: Blockchain the contract is deployed on
2. **Contract Address**: The address of the contract you want to decode
3. **Project Name**: The name of the project that the contract originates from (e.g. Tether, Uniswap, Bancor)
4. **Contract Name**: The name of the smart contract as given by the project (ex. USDT, Pair, LiquidityFactory)
5. **ABI**: Unique to each smart contract. Further details can be found [here](https://docs.soliditylang.org/en/latest/abi-spec.html). Note that for contracts that are verified by a chain's explorer we will attempt to auto-fetch the ABI. Otherwise the ABI will need to be entered manually.

In most cases, the contract name will be pulled directly from a blockchain scanner. We recommend using the name provided. If the name is not automatically provided, please follow our naming conventions to assure the contract is properly assimilated into Dune's database.

### When do you need Several Instances Options?

#### Enable bytecode matching

Contract "instances" are contracts on the same chain with the same bytecode (and therefore the same ABI) for **the same project**. If you check this box, Dune can decode all instances of this project on the given blockchain with the same bytecode and ABI, consolidating them into the same tables under one `namespace.project` directory without multiple submissions.

To check for other instances of the contract, go to a blockchain explorer and look for "Similar Match Source Code" under the Contract tab. Here is [an example](https://etherscan.io/address/0x58a70c59cb1f0e30c3d7ad84b96170221cbf322f#code):

<img alt="" />

**Decoded via dynamic contract detection**

Contracts decoded this way are referred to as dynamically decoded by Dune. These are contracts that are decoded automatically because users checked the box "Are there several instances of this contract?" when submitting the contract. Note that Dune only considers a contract a dynamic instance if the bytecode matches 100%. This is done by querying the `<chain>_creation_traces` table and matching the `code` field. If the bytecode does not match 100%, we will not decode that instance.

For example, [this contract](https://arbiscan.io/address/0x999946a4f40fd2c82d66a68edfefa8430f206c9c#code) is nearly identical to [this other contract](https://arbiscan.io/address/0x692e92da68f9b8445a167b985ee0cb38c3bbe594#code) in terms of bytecode, but Dune currently does not dynamically decode the first contract because we currently require a 100% bytecode match.

#### Decode other contracts created by the same factory

A [factory contract](https://betterprogramming.pub/learn-solidity-the-factory-pattern-75d11c3e7d29) is a smart contract that creates other smart contracts. If there are multiple instances of a contract, it might be due to a factory contract. If you check this box, Dune can decode all contracts created by the same factory that use the same ABI, consolidating them into the same tables under one `namespace.project` directory (e.g., [Pair contract from Uniswap V2](https://dune.com/queries?category=decoded_project\&blockchain=ethereum\&namespace=uniswap_v2\&contract=Pair\&blockchains=ethereum)).

When you submit a contract as a factory contract, Dune verifies it by checking if the deployer (`from` address) is a contract and not an EOA. This is done by querying the `<chain>_creation_traces` table. If the `from` address is a contract, Dune will gather all `address` fields created by it for decoding.

To check if a contract is created by a factory, use a blockchain explorer to see if the "From" address in a Contract Creation transaction is a contract or an EOA. For example, this is [a factory-created contract](https://etherscan.io/address/0x5d5ce36e0b328a48539b48d4f22c31f0fe3dc040#internaltx) by [Uniswap V3 factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984).

<img alt="" />

**Decoded via the factory pattern**

Contracts decoded this way are referred to as factory decoded by Dune. These contracts are automatically decoded because users checked "Is it created by a factory contract?" when submitting. Dune detects this by querying the `<chain>_creation_traces` table and fetching all `address` fields created by the same `from`.

#### Dynamic vs Factory Decoded

Dynamic decoding anchors on the bytecode being the same, while factory decoding also requires the contract to be deployed by another contract (not an EOA) with the same deployer address.

**Dynamically Decoded Contracts** share the same bytecode but may have different deployers.

For example, [this contract](https://etherscan.io/address/0x58a70c59cb1f0e30c3d7ad84b96170221cbf322f) can be decoded as dynamic because it has the same bytecode as [this contract](https://etherscan.io/address/0x6d396aaff9f438e2f86979d8367cd9deb364b16f). Both will appear under the same decoded tables in the [SmartTokens for Bancor](https://dune.com/queries?category=decoded_project\&blockchain=ethereum\&namespace=bancor\&contract=SmartToken\&blockchains=ethereum) directory but have different deployers (`from` address).

**Factory Decoded Contracts** are deployed by a factory contract and share the same deployer address.

For example, contracts created by the [Uniswap V3 Factory](https://etherscan.io/address/0x1f98431c8ad98523631ae4a59f267346ea31f984), such as [this one](https://etherscan.io/address/0xb5925e4c1912e3999891f0e71bd3d9b5492d1486#internaltx) and [this one](https://etherscan.io/address/0x5d5ce36e0b328a48539b48d4f22c31f0fe3dc040#internaltx), are factory decoded because they share the same bytecode and deployer. These contracts will appear under the same decoded tables in the [Pair for Uniswap V3](https://dune.com/queries?category=decoded_project\&blockchain=ethereum\&namespace=uniswap_v3\&contract=Pair\&blockchains=ethereum) directory.

### Other Special Contracts

Other special smart contracts can be decoded as well, following these conventions:

#### [Proxy contract](https://info.etherscan.com/what-is-proxy-contract/)

Submit using the proxy address but with the ABI of the implementation.

You can identify a proxy contract by looking for the "Read as Proxy" tab on a blockchain explorer. This tab will also show the implementation contract. Here is [an example](https://arbiscan.io/address/0x90a664846960aafa2c164605aebb8e9ac338f9a0#readProxyContract).

<img alt="" />

To decode:

1. Use the address of the [proxy contract](https://arbiscan.io/address/0x90a664846960aafa2c164605aebb8e9ac338f9a0).
2. Fetch the ABI of the [implementation contract](https://arbiscan.io/address/0x90a664846960aafa2c164605aebb8e9ac338f9a0#readProxyContract).

<img alt="" />

#### Diamond proxy contracts

Submit all the facets using just the same name for the project and contract and upload all the relevant ABIs. This can be done with one ABI representing all facets or separate ABIs for each facet.

<Note>
  **Where can I find this information?**

  Contract addresses can usually be found in a project's docs. Once you have the contract address, you can use a blockchain explorer to get the rest of the information. Most blockchain explorers have everything you need!
</Note>

### Resubmissions

Sometimes you need to resubmit a contract because the name is originally submitted wrong, or you need to update the ABI. Follow the steps as guided. But if you are resubmitting for other reason not listed in the dropdown, provide as much detail as possible to avoid the resubmission being rejected.

<img alt="" />

## Step 2: Decoding

Once the contract has been approved for decoding, you will receive a notification in your email. While the table itself may be visible after approval, it may be empty. No reason to worry! Note that it takes around 24 hours from the time the contract has been approved to be fully decoded and incorporated into the Dune database.

At any point you can check the status of your submitted contract under "Contracts" in your settings.

## Step 3: Finding Your Decoded Contract

One quick tip to find and begin querying your decoded table is to use Dune's Explorer. When beginning a new query, the Explorer is located to the left side of the Query Editor. From there, follow simple steps:

1. Drop the contract address of your decoded contract in the search bar
2. Pull up the specific function or event you are looking for
3. use the **>>** button to immediately populate that table in your Query Editor.

<img alt="The search bar and >> symbol that will help you get started" />

Then it's all ready for you to query. Let the data flow!

# B. Need Help?

For frequently asked questions about decoding contracts, check out our [Decoding FAQs](/web-app/decoding/faqs).

### Additional Questions?

Head over to the [#decoding Discord channel](https://discord.com/channels/757637422384283659/850326962152538122) and we'll be happy to help!


# Decoding FAQs
Source: https://docs.dune.com/web-app/decoding/faqs

Frequently asked questions about decoding contracts on Dune.

# Frequently Asked Questions

## General FAQs

<Accordion title="How do I figure out if my contract has been decoded?">
  There are two main ways to find out if your contract has been decoded.

  First: Account Settings

  Information on submitted contracts can be found in your account settings under "Contracts". The status of the contract will reflect one of the following:

  1. Pending
  2. Approved/Rejected\*

  Note that once a contract has been approved, it takes around 24 hours for the data to be fully decoded and populated into our database.

  \*If the contract is rejected, hover your mouse over the status to see the reason for the rejection.

  Second: Our [Contract Decoding Dashboard](https://dune.com/dune/is-my-contract-decoded-yet-v2)

  <img alt="" />

  Built by our decoding team, this dashboard gives you information on the status of any submitted contract. Input the contract address in the box at the top of the dashboard and if the contract has been decoded, the contract information will populate the box along with where it is located in the Dune database.
</Accordion>

<Accordion title="I see data on Dune but it doesn't match or is missing what I expected to see">
  Unfortunately, Dune only has access to contract data in circumstances that the contract performed an event that left a trace. Our recommendation is to check out the .traces table to see what information is available for a particular contract.

  Alternatively, some contracts are upgradeable (ie., the smart contract code can be modified). In this case we may not have all of the ABIs. ABIs can be checked in the ABI column of the .contracts tables. A contract can always be resubmitted with missing ABIs so we can update our data.
</Accordion>

<Accordion title="How do I submit contract information manually?">
  <Info>If the contract being manually submitted is a Proxy contract, we recommend you to move on to the next section.</Info>

  Although we try to fetch contract information such as the ABI, sometimes this information might not be available through our sources.

  In those instances, you will need to manually input the contract's name and its ABI.

  If the contract has been verified by the chain's block explorer, you should be able to find this information there.
</Accordion>

<Accordion title="How do I submit a proxy contract?">
  In order to properly decode transactions for contracts that fit the [Proxy pattern](https://blog.openzeppelin.com/proxy-patterns/), Dune needs to map the Proxy contract's address with the implementation contract's ABI.

  We avoid monitoring the implementation contract's address because its logic is accessed in transactions via the [`DelegateCall` function](https://medium.com/coinmonks/delegatecall-calling-another-contract-function-in-solidity-b579f804178c).

  If we did monitor the implementation contract's address directly, we would miss out on any event logs in its logic since these are actually fired by the caller (the Proxy in this case) when calling a function through `DelegateCall`.

  <Warning> When submitting Proxy-patterned contracts to Dune, you should input the Proxy contract's address and, if you have it, the Implementation contract's ABI. If the Proxy has a new implementation upgraded that you wish to decode, use the same project name + contract name and select <b>'NO'</b> for several instances! </Warning>

  <img alt="new proxy implementation submission" />

  When you submit the Proxy contract's address, we'll attempt to fetch the proxy's contract name and the implementation address it's pointing towards to source the Implementation contract's ABI.

  If we can't find the Implementation contract's ABI, you'll need to find it using the relevant chain's blockchain explorer and input it manually.

  You can use the [Etherscan Proxy Contract Checker](https://etherscan.io/proxyContractChecker) to help verify and link proxy contracts with their implementation ABIs.
</Accordion>

<Accordion title="How do I submit Diamond Proxy contracts?">
  Similar to vanilla Proxy contracts, [EIP-2535](https://eips.ethereum.org/EIPS/eip-2535) contracts can be supported by passing in the address of the Diamond Proxy as well as **a single ABI representing the totality of all the facets interfaces**.
</Accordion>

<Accordion title="My submission got rejected, why?">
  The most common reason that your submission got rejected is because it has already been decoded! You can make use of [this dashboard](https://dune.com/dune/is-my-contract-decoded-yet-v2) to check whether the contract have been decoded.

  **Enter the contract that you wish to decode and hit enter to run:**

  <img alt="check if contract is decoded" />

  **Viewing results:**

  <img alt="query results to determine whether contract is decoded" />

  If you see results after running the query, that means the contract is already decoded! You'll be able to find the decoded tables under 'Decoded Projects' in the data explorer.

  In the interest of data quality, we reject duplicative, incorrect or low quality submissions. To avoid rejection, be sure to submit accurate contract information! Submissions can be rejected for a number of reasons, including not following the naming conventions, not providing clear data at submission, etc. The particular reason for a contract submission being rejected can be found in account settings under "Contracts" by hovering the mouse over the "Rejected" status.
</Accordion>

<Accordion title="Why am I missing historical data for my contract?">
  It may take up to six hours from the time of contract approval for the contract to be fully decoded along with its historical data. If you still can't see the data after this period, please reach out to us through our [#decoding Discord channel](https://discord.com/channels/757637422384283659/850326962152538122).
</Accordion>

<Accordion title="I'm waiting for my data to fully decode. What can I do in the meantime?">
  Need some data urgently but the contract have yet to be fully decoded? You can refer to these queries that utilizes the logs table to get the events:

  * [Querying Synthetix's PerpsTracking Event](https://dune.com/queries/2743182)
  * [Querying USDT's AddedBlackList Event](https://dune.com/queries/3250843)
</Accordion>

## Duplicate Data & Namespace Issues

<Accordion title="My contracts are being decoded under multiple folders/namespaces, causing duplicate records. How do I fix this?">
  This happens when the same contract is submitted multiple times under different names, across different blockchains. To resolve:

  1. **Identify the duplicate submissions** in your contracts list
  2. **Choose which namespace to keep** (e.g., LiFiDiamond\_v2 vs LiFiDiamond)
  3. **Resubmit the contract** and select "Rename a contract" as the reason for resubmission

  !\[Resubmission UI example]\(/web-app/images/alerts/Contract resubmission sc.png)

  4. **Contact Dune support** via Slack (For Enterprise Customers), Telegram (Paid Customers), [Discord](https://discord.com/invite/ErrzwBz), or email ([support@dune.com](mailto:support@dune.com)) to remove the duplicate namespace

  **Going forward: Before submitting, [search](https://dune.com/dune/is-my-contract-decoded-yet-v2) if the contract already exists under your project**

  To prevent this:

  * Check existing decoded contracts before submitting
  * Use consistent naming conventions across your team
  * Document which contracts are already decoded
</Accordion>

<Accordion title="Can I move contracts from one namespace to another without losing data?">
  **No**, you cannot move contracts between namespaces after decoding. You would need to:

  1. Resubmit under the correct namespace
  2. Wait for new decoding to complete
  3. Migrate your queries to use the new tables
  4. Submit a request to Dune support via Slack (For Enterprise Customers), Telegram (Paid Customers), [Discord](https://discord.com/invite/ErrzwBz), or email ([support@dune.com](mailto:support@dune.com)) to remove the old namespace

  **Plan your namespace structure carefully before submission.**
</Accordion>

## Rejection & Missing Data Issues

<Accordion title="My contract was rejected with no explanation. What happened?">
  When a contract is rejected without a detailed explanation, it's often for one of these common reasons:

  * **Duplicate submission**: Contract is already decoded under another name
  * **Invalid ABI**: ABI doesn't match the deployed bytecode
  * **Wrong contract type**: Submitted a library or abstract contract

  To debug: Find a specific transaction hash where your event/function was called and include it in your resubmission notes.
</Accordion>

<Accordion title="I see the contract on Etherscan but functions/events are missing on Dune. Why?">
  Dune only displays functions and events that have actual onchain data:

  ✅ **Visible**: Events/functions that have been called at least once\
  ❌ **Hidden**: Events/functions with zero onchain activity\
  ❌ **Hidden**: View/pure functions (read-only, no on-chain traces)

  **Most common cause**: This often happens when a proxy contract's implementation is upgraded. The new functions/events won't appear until:

  1. They're actually called onchain, AND
  2. The new ABI is submitted to Dune for decoding (requires manual approval, which can take some time)

  **To verify**:

  1. Find a transaction that calls the missing function/event
  2. Check if it appears in `ethereum.traces` or `ethereum.logs` raw tables

  **To check**:

  ```sql theme={null}
  -- Check if tx hash exists in traces
  SELECT 
      'traces' as table_name,
      COUNT(*) as record_count
  FROM ethereum.traces
  WHERE tx_hash = 0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef;
  ```

  OR

  ```sql theme={null}
  -- Check if tx hash exists in logs  
  SELECT 
      'logs' as table_name,
      COUNT(*) as record_count
  FROM ethereum.logs
  WHERE tx_hash = 0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef;
  ```

  If yes but not in decoded tables, contact Dune support with the tx hash
</Accordion>

## Bytecode Matching & Instance Detection

<Accordion title="I enabled bytecode matching but other instances aren't appearing. How long should I wait?">
  **Bytecode matching timeline**:

  * **Initial contract**: Typically decodes within 24 hours
  * **Bytecode matching scan**: Additional 24-48 hours
  * **Status remains "Pending"**: This is normal during scanning
  * **All instances appear**: Usually within 48-72 hours total

  **To verify it's working**:

  ```sql theme={null}
  -- Check if other instances are detected
  SELECT DISTINCT contract_address 
  FROM namespace.contractname_evt_YourEvent
  ```

  If after 72 hours only one address appears, verify:

  * Other contracts have 100% identical bytecode
  * You enabled "bytecode matching" during submission
  * Contracts aren't variations (even slight differences prevent matching)
</Accordion>

<Accordion title="How do I know if bytecode matching actually found other instances?">
  After decoding completes, you can check:

  1. **Query the decoded tables for multiple contract addresses**
  2. **Can use [dune.com/agent](https://dune.com/agent)**:

  ```sql theme={null}
  -- Find all contracts with the same bytecode as a specific contract
  SELECT *
  FROM contracts.contract_mapping 
  WHERE code = (
      SELECT code 
      FROM contracts.contract_mapping 
      WHERE contract_address = 0x7ac96180C4d6b2A328D3a19ac059D0E7Fc3C6d41
      AND blockchain = 'ethereum'  -- or your target chain
  )
  ORDER BY code_deploy_rank_by_chain, created_time
  ```
</Accordion>

## Complex Namespace Management

<Accordion title="How do I ensure specific contracts fall under the right namespace when using bytecode matching?">
  You cannot selectively include/exclude contracts with bytecode matching. Options:

  **If contracts should be in different namespaces**:

  * Submit them separately
  * Don't enable bytecode matching
  * Manually submit each address

  **If you need selective grouping**:

  * Submit the main contract with bytecode matching
  * Create a view filtering only desired addresses:

  ```sql theme={null}
  CREATE VIEW my_filtered_events AS
  SELECT * FROM namespace.contract_evt_Event
  WHERE contract_address IN (
      '0xAddress1',
      '0xAddress2'
  )
  ```

  **For different versions under same namespace**:

  * For upgradeable contracts (e.g., proxy pattern), submit only the proxy contract address with the current implementation's ABI.
  * Use the same project and contract names for consistency.
  * When a new implementation is deployed, resubmit the proxy contract with the updated ABI and the same names (select 'NO' for several instances).
  * Do not submit multiple versions as separate contracts; just update the ABI as needed via resubmission.
</Accordion>

<Accordion title="Multiple teams deployed our contracts. How do we organize the data?">
  **Best practices for shared contract code**:

  * **Coordinate namespace ownership**: Decide who "owns" the namespace
  * **Use project-specific namespaces**: teamA\_token vs teamB\_token
  * **Create cross-project views**: Combine data post-decoding
  * **Document deployment addresses**: Maintain a registry of who deployed what

  **Note**: Dune cannot always determine exactly what onchain data passes through a given project. This limitation applies broadly, but is especially relevant for aggregators, interfaces, or infrastructure layers that interact with data indirectly. As a result, usage and attribution metrics may be incomplete or ambiguous.
</Accordion>

## Performance & Query Optimization

<Accordion title="How do I efficiently query factory contracts with thousands of instances?">
  **Optimize your queries by**:

  **Filter early and specifically**:

  ```sql theme={null}
  -- Good: Filter by contract_address first
  SELECT * FROM uniswap_v2.Pair_evt_Swap
  WHERE contract_address = 0xSpecificPair
  AND evt_block_time > now() - interval '1 day'

  -- Bad: Scan all pairs first
  SELECT * FROM uniswap_v2.Pair_evt_Swap
  WHERE evt_block_time > now() - interval '1 day'
  AND token0 = 0xSpecificToken
  ```

  **Identify relevant contracts upfront**:

  * Before querying, determine which token pairs or contract instances matter to your analysis
  * You can do this by:
    * Looking them up on a block explorer or the project's official documentation/site
    * Querying Dune itself to find pairs involving a specific token of interest
  * Use materialized views for common filters
  * Partition by time when querying historical data
  * Index on contract\_address in downstream tables
</Accordion>

<Accordion title="My decoded tables are huge. How do I find specific contract instances?">
  **Use these strategies**:

  **Create a contract registry view**:

  ```sql theme={null}
  WITH my_protocol_contracts AS (
      SELECT 
          contract_address,
          MIN(evt_block_time) as first_seen,
          COUNT(*) as event_count
      FROM uniswap_v2_multichain.uniswapv2factory_evt_paircreated
      GROUP BY contract_address
  )
  SELECT * FROM my_protocol_contracts
  ORDER BY event_count DESC
  ```

  * Use Dune's search in Data Explorer with specific addresses
  * Filter by deployment block for newer contracts
  * Maintain an off-chain registry of your contract deployments
</Accordion>

## Special Cases & Edge Scenarios

<Accordion title="How do I handle contracts deployed by CREATE2 with identical addresses across chains?">
  **For deterministic deployments**:

  * Submit once per chain (multichain decoding handles this automatically if criteria are met)
  * Use consistent naming across all chains
  * Note in submission: "CREATE2 deterministic deployment"

  **Query efficiently**:

  ```sql theme={null}
  -- Query all chains at once
  SELECT * FROM namespace.contract_evt_Event
  WHERE chain IN ('ethereum', 'polygon', 'arbitrum')
  ```
</Accordion>

## Submission-Related FAQs

<Accordion title="I submitted the wrong ABI type (proxy instead of implementation). How do I fix this?">
  You'll need to resubmit the contract with the correct implementation ABI. Use the resubmission process and select "Upgrade the ABI of a contract" as the reason. In the notes, clearly state you're switching from proxy to implementation ABI. The original submission will be replaced once approved.

  **Please note**: You will need to wait until the original submission has completed the decoding process to resubmit. Submitting back to back will result in both submissions getting rejected.
</Accordion>

<Accordion title="How do I know if I should use bytecode matching vs factory pattern?">
  * **Use bytecode matching when**: Multiple contracts have identical code but different deployers (e.g., token contracts deployed by different teams)
  * **Use factory pattern when**: All contracts are created by the same factory contract (e.g., Uniswap pairs)
  * **Use both when**: A factory creates contracts with identical bytecode

  Check the "From" address in the creation transaction - if it is a contract (not EOA), consider the factory pattern.
</Accordion>

<Accordion title="My contract has been upgraded multiple times. Should I submit all versions?">
  **Handling Upgraded Contracts on Dune**

  When your contract has been upgraded multiple times, you don't need to submit all versions. Here's what you should do:

  **For Proxy Contracts (Most Common Upgrade Pattern)**
  If your contract uses a proxy pattern for upgrades:

  * Submit only the proxy contract address with the current implementation's ABI
  * Use the same project name and contract name for consistency
  * When you have a new implementation that you want to decode, resubmit the contract with:
    * Same proxy address
    * Updated ABI from the new implementation
    * Same project and contract names
    * Select 'NO' for "several instances" option

  **Resubmission Process**
  The documentation specifically mentions resubmissions for cases like yours:

  > Sometimes you need to resubmit a contract because the name is originally submitted wrong, or you need to update the ABI.

  When resubmitting:

  * Go to the contract submission page
  * Select the resubmission reason from the dropdown
  * If your reason isn't listed, provide detailed information about why you're resubmitting to avoid rejection

  **Key Points About Contract Upgrades**

  * Dune handles upgradeable contracts by allowing ABI updates through resubmission
  * The documentation notes: "some contracts are upgradeable (i.e., the smart contract code can be modified). In this case we may not have all of the ABIs. ABIs can be checked in the ABI column of the .contracts tables. A contract can always be resubmitted with missing ABIs so we can update our data."
  * You only need to submit the current/latest version that you want decoded

  **What NOT to Do**

  * Don't submit multiple versions of the same contract as separate submissions
  * Don't submit implementation contract addresses directly (for proxy patterns)

  The most efficient approach is to submit your current proxy contract with the latest implementation's ABI, and resubmit when you have significant upgrades that require new decoding.
</Accordion>

## Decoding Process FAQs

<Accordion title="Why does my decoded table show data from other contracts I didn't submit?">
  This happens when you enabled bytecode matching or factory pattern detection. Your submission automatically decoded all contracts with:

  * Same bytecode (if bytecode matching enabled)
  * Same factory deployer (if factory pattern enabled)

  This is a feature, not a bug - it gives you comprehensive protocol data.
</Accordion>

<Accordion title="How long does decoding take for factory contracts with thousands of instances?">
  Factory contracts with many instances (like Uniswap pairs) can take 24-48 hours to fully decode. The table appears immediately but populates gradually. Large factories may take longer due to the volume of historical data.
</Accordion>

## Query-Related FAQs

<Accordion title="How do I identify which specific contract instance generated an event in factory-decoded tables?">
  Use the `contract_address` column present in all decoded tables. This shows which specific instance (e.g., which Uniswap pair) generated each event.
</Accordion>

<Accordion title="Why can't I find my multichain decoded tables?">
  Multichain views require:

  1. Identical ABIs across chains
  2. Same project namespace and contract name
  3. Contracts submitted on multiple chains

  Check that all three criteria are met. Look for the multichain symbol in the Data Explorer.

  **Please Note**: There are sometimes delays that occur before the decoded tables show up in the multichain tables after they are decoded.
</Accordion>

## Troubleshooting FAQs

<Accordion title="I see similar contracts on Etherscan but bytecode matching isn't working. Why?">
  Dune requires 100% bytecode match. Even minor differences (like constructor parameters stored in bytecode) prevent matching. Check if contracts were compiled with different:

  * Solidity versions
  * Optimizer settings
  * Constructor parameters embedded in bytecode

  You can use [Etherscan's Find Similar Contracts tool](https://etherscan.io/find-similar-contracts) to check for bytecode similarity and see if your contract matches others on-chain.

  You may need to submit contracts individually.
</Accordion>

## Best Practices FAQs

<Accordion title="Should I decode every contract in my protocol?">
  **No**, focus on contracts that emit important events or have a queryable state:

  ✅ **Core protocol contracts with business logic**\
  ✅ **Contracts emitting analytical events**\
  ❌ **Simple ownership or access control contracts**\
  ❌ **Libraries (can't be decoded directly)**
</Accordion>

<Accordion title="When should I resubmit vs. submit a new contract?">
  **New submission when**:

  * Different contract address
  * New version with different address
  * Different contract type in protocol
  * Adding missed chains

  **Resubmit when**:

  * Updating ABI for the same contract
  * Fixing naming errors
  * Request contract deletion
  * Submitting for another reason
</Accordion>

### Additional Questions?

Head over to the [#decoding Discord channel](https://discord.com/channels/757637422384283659/850326962152538122) and we'll be happy to help!


# Multichain Decoding
Source: https://docs.dune.com/web-app/decoding/multichain-decoding

Consolidate decoded contract data across EVM chains into unified, queryable tables.

Multichain Decoding consolidates decoded contract data across all supported EVM chains into a single table per contract. Instead of maintaining separate `UNION ALL` queries for every chain your protocol operates on, you submit once and query one table — with a `chain` column to filter or aggregate by network.

This eliminates the most common sources of broken cross-chain queries: missing a newly supported chain, inconsistent table naming across deployments, or schema drift between separate submissions.

<Info>Multichain contract submissions require a **paid team plan**. See [pricing](https://dune.com/pricing) for details.</Info>

<Tip>Multichain tables have the same data freshness and latency as single-chain decoded tables. See [data freshness](../../data-catalog/data-freshness) for SLA details.</Tip>

## Prerequisites

Before submitting a multichain contract, ensure the following:

| Requirement           | Details                                                                                                                |
| --------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| **Identical ABI**     | Contracts must share the exact same ABI across all chains.                                                             |
| **Consistent naming** | Contracts must use the same project namespace and contract name (e.g., `uniswap_v3` / `UniswapV3Pool`).                |
| **Paid team plan**    | Multichain submissions are only available to teams on a paid subscription. [Compare plans →](https://dune.com/pricing) |

Dune uses this standardized labeling to merge data from different chains into a single cross-chain table.

## Submitting Contracts

To submit a multichain contract, use the [contract submission page](https://dune.com/contracts/new). Select **Submit on Multiple Chains**, provide the ABI, and select all target chains.

When contracts with the same ABI are submitted across multiple chains, Dune combines them into a single table — no additional configuration needed.

For detailed submission instructions — including factory contracts, proxy patterns, and bytecode matching — see the [Contract Decoding Best Practices Guide](/web-app/decoding/best-practices).

## Querying Multichain Tables

### Naming Convention

Multichain decoded tables follow the naming pattern:

```
{project}_multichain.{ContractName}_{evt|call}_{EventOrFunctionName}
```

For example:

* `gnosis_safe_multichain.Safe_v1_4_1_call_execTransaction`
* `zora_multichain.ZoraTimedSaleStrategy_evt_SaleSet`

### Schema

Each multichain table includes a `chain` column identifying the source network, alongside all standard decoded columns (`evt_block_time`, `evt_tx_hash`, `call_block_time`, etc.).

```sql theme={null}
-- All execTransaction calls on Ethereum
SELECT chain, call_block_time, call_tx_hash
FROM gnosis_safe_multichain.Safe_v1_4_1_call_execTransaction
WHERE chain = 'ethereum'
```

### Finding Tables in the Data Explorer

Multichain decoded tables are accessible in the Data Explorer alongside regular decoded tables. They display a distinct multichain icon and list all supported chains.

<img alt="Multichain table in Data Explorer" />

## Examples

The following examples compare multichain queries against the equivalent manual `UNION ALL` approach. In each case, multichain tables reduce query complexity and eliminate the need to track per-chain table names.

<Accordion title="Finding Zora Uniswap Collections">
  <Tabs>
    <Tab title="Multichain table">
      ```sql theme={null}
        SELECT * 
        FROM (
            SELECT 
                --this event is emitted on sale set updates too so we take distinct
                distinct
                l.blockchain
                , l.collection as nft_address
                , l.erc20zAddress as erc20_address
                , l.tokenId as token_id
                , nft.name as nft_collection_name
                , nft.defaultAdmin as creator
                , json_value(salesConfig, 'strict $.name') as nft_name
                , json_value(salesConfig, 'strict $.symbol') as nft_symbol
                , COALESCE(try(from_unixtime(cast(json_value(salesConfig, 'strict $.saleStart') as bigint))),timestamp '1970-01-01') as start_time
                , COALESCE(try(from_unixtime(cast(json_value(salesConfig, 'strict $.saleEnd') as bigint))),timestamp '2050-01-01') as end_time
                , l.poolAddress as uni_pool
                , l.evt_block_time
                , row_number() over (partition by collection, erc20zAddress, tokenId order by evt_block_time desc) as last_sale_set
            FROM ( SELECT collection, erc20zAddress, tokenId, salesConfig, evt_block_time, poolAddress, chain AS blockchain
                  FROM zora_multichain.ZoraTimedSaleStrategy_evt_SaleSet ) l 
            LEFT JOIN ( SELECT name, defaultAdmin, newContract, chain AS blockchain
                        FROM zora_multichain.ZoraCreator1155FactoryImpl_evt_SetupNewContract ) nft 
                  ON l.collection = nft.newContract AND l.blockchain = nft.blockchain
        ) 
        WHERE last_sale_set = 1
      ```
    </Tab>

    <Tab title="Manual UNION ALL (per-chain)">
      ```sql theme={null}
        SELECT 
        * 
        FROM (
            SELECT 
                --this event is emitted on sale set updates too so we take distinct
                distinct
                l.blockchain
                , l.collection as nft_address
                , l.erc20zAddress as erc20_address
                , l.tokenId as token_id
                , nft.name as nft_collection_name
                , nft.defaultAdmin as creator
                , json_value(salesConfig, 'strict $.name') as nft_name
                , json_value(salesConfig, 'strict $.symbol') as nft_symbol
                , COALESCE(try(from_unixtime(cast(json_value(salesConfig, 'strict $.saleStart') as bigint))),timestamp '1970-01-01') as start_time
                , COALESCE(try(from_unixtime(cast(json_value(salesConfig, 'strict $.saleEnd') as bigint))),timestamp '2050-01-01') as end_time
                , l.poolAddress as uni_pool
                , l.evt_block_time
                , row_number() over (partition by collection, erc20zAddress, tokenId order by evt_block_time desc) as last_sale_set
            FROM (
                SELECT collection, erc20zAddress, tokenId, salesConfig, evt_block_time, poolAddress, 'zora' as blockchain FROM zora_zora.ZoraTimedSaleStrategy_evt_SaleSet
                UNION ALL
                SELECT collection, erc20zAddress, tokenId, salesConfig, evt_block_time, poolAddress, 'base' as blockchain FROM zora_base.ZoraTimedSaleStrategy_evt_SaleSet
                UNION ALL
                SELECT collection, erc20zAddress, tokenId, salesConfig, evt_block_time, poolAddress, 'optimism' as blockchain FROM zora_optimism.ZoraTimedSaleStrategy_evt_SaleSet
                UNION ALL
                SELECT collection, erc20zAddress, tokenId, salesConfig, evt_block_time, poolAddress, 'arbitrum' as blockchain FROM zora_arbitrum.ZoraTimedSaleStrategy_evt_SaleSet
                UNION ALL
                SELECT collection, erc20zAddress, tokenId, salesConfig, evt_block_time, poolAddress, 'blast' as blockchain FROM zora_blast.ZoraTimedSaleStrategy_evt_SaleSet
            ) l 
            LEFT JOIN (
                SELECT name, defaultAdmin, newContract, 'zora' as blockchain FROM zora_zora.ZoraCreator1155_evt_SetupNewContract 
                UNION ALL 
                SELECT name, defaultAdmin, newContract, 'base' as blockchain FROM zora_base.ZoraCreator1155FactoryImpl_evt_SetupNewContract
                UNION ALL  
                SELECT name, defaultAdmin, newContract, 'optimism' as blockchain FROM zora_optimism.ZoraCreator1155FactoryImpl_evt_SetupNewContract
                UNION ALL 
                SELECT name, defaultAdmin, newContract, 'arbitrum' as blockchain FROM zora_arbitrum.ZoraCreator1155Factory_evt_SetupNewContract
                UNION ALL 
                SELECT name, defaultAdmin, newContract, 'blast' as blockchain FROM zora_blast.ZoraCreator1155FactoryImpl_evt_SetupNewContract
            ) nft ON l.collection = nft.newContract AND l.blockchain = nft.blockchain
        ) 
        WHERE last_sale_set = 1
      ```
    </Tab>
  </Tabs>
</Accordion>

<Accordion title="Gnosis Safe `execTransaction` Calls">
  <Tabs>
    <Tab title="Multichain table">
      ```sql theme={null}
        select chain, date_trunc('day', call_block_time) AS block_date, count(*) as cnt
        from gnosis_safe_multichain.Safe_v1_4_1_call_execTransaction
        group by 1, 2
      ```
    </Tab>

    <Tab title="Manual UNION ALL (per-chain)">
      ```sql theme={null}
        select chain, date_trunc('day', call_block_time) AS block_date, count(*) as cnt
        from (
        SELECT 'arbitrum' AS chain, call_block_time
        FROM gnosis_safe_arbitrum.Safe_v1_4_1_call_execTransaction

        UNION ALL

        SELECT 'avalanche_c' AS chain, call_block_time
        FROM gnosis_safe_avalanche_c.Safe_v1_4_1_call_execTransaction

        UNION ALL

        SELECT 'blast' AS chain, call_block_time
        FROM gnosis_safe_blast.Safe_v1_4_1_call_execTransaction

        UNION ALL

        SELECT 'base' AS chain, call_block_time
        FROM gnosis_safe_base.Safe_v1_4_1_call_execTransaction

        UNION ALL

        SELECT 'bnb' AS chain, call_block_time
        FROM gnosis_safe_bnb.Safe_v1_4_1_call_execTransaction

        UNION ALL

        SELECT 'celo' AS chain, call_block_time
        FROM gnosis_safe_celo.Safe_v1_4_1_call_execTransaction

        UNION ALL

        SELECT 'ethereum' AS chain, call_block_time
        FROM gnosis_safe_ethereum.Safe_v1_4_1_call_execTransaction

        UNION ALL

        SELECT 'gnosis' AS chain, call_block_time
        FROM gnosis_safe_gnosis.Safe_v1_4_1_call_execTransaction

        UNION ALL

        SELECT 'linea' AS chain, call_block_time
        FROM gnosis_safe_linea.Safe_v1_4_1_call_execTransaction

        UNION ALL

        SELECT 'optimism' AS chain, call_block_time
        FROM gnosis_safe_optimism.Safe_v1_4_1_call_execTransaction

        UNION ALL

        SELECT 'polygon' AS chain, call_block_time
        FROM gnosis_safe_polygon.Safe_v1_4_1_call_execTransaction
        )
        group by 1,2
      ```
    </Tab>
  </Tabs>
</Accordion>


# Contract Submission Guide
Source: https://docs.dune.com/web-app/decoding/short-guide-contract-submission

A guide for chains and protocols to submit contracts for decoding on Dune.

## Why Submit Contracts for Decoding?

Decoding creates structured, queryable datasets for your protocol's smart contracts on Dune. Once decoded, your team and the broader community can build dashboards and analytics using human-readable event and function data instead of raw bytecode.

## How to Submit Contracts

### Submit via UI (Recommended)

Use the Dune UI for a guided submission process: [https://dune.com/contracts/new](https://dune.com/contracts/new).

### Batch Submission via CSV (Advanced)

If you are looking to submit dozens of protocol contracts, you may submit via CSV. Work with us through Slack or Telegram, ensuring the CSV is formatted correctly for batch submission.

<Warning>
  Batch submission bypasses UI safeguards, so make sure all flags are accurate, the ABI is formatted correctly, and naming follows Dune standards. Using the UI is preferred, as it includes checks that reduce errors and debugging time.
</Warning>

Follow [this Google Sheet template](https://docs.google.com/spreadsheets/d/1yxJqlmSE2yYgXgSIXcPRr5xxP9ck9JZB8_sGOITtYEM/edit?gid=0#gid=0) for exact format, and refer to [Dune’s documentation](./decoding-contracts) for guidance on fields like:

* **`has_multiple_instances`** is flag for for [dynamic contracts](./decoding-contracts#are-there-several-instances-of-this-contract-dynamic-contract)
* **`is_created_by_factory`** is flag for [factory contracts](./decoding-contracts#is-it-created-by-a-factory-contract-factory-contract)

## Submission Strategy

* **For Chains:** Encourage top protocols to submit their key contracts.
* **For Protocols:** Collaborate with your developers or data analysts to identify which contracts include the main logic and events.

## Special Instructions by Contract Type

### Proxy Contracts

If using a proxy pattern, submit the **implementation contract's ABI**.
<Note> Dune’s pipeline cannot handle dynamic proxies or complex patterns automatically yet. </Note>

### ERC20, ERC721, ERC1155 Tokens

These contracts typically don’t need submission, as Dune already covers standard approvals and transfers. Submit only if custom events are needed.

### DEX Contracts

Look for below sets of contracts:

* **Factory Contract**: should emit pool creation events.
* **Pair/Pool Contract**: should emit swap events.

If decoding is required for additional contracts like routers or position managers, please submit those as well.

### NFT Marketplace Contracts

Submit the main marketplace contract with key events, such as:

* `ERC721BuyOrderFilled`
* `ERC721SellOrderFilled`
* `ERC1155BuyOrderFilled`
* `ERC1155SellOrderFilled`

### Unverified Contracts

If the contract isn’t verified on the block explorer, contact the protocol developers to obtain the ABI.


# Solana Program Decoding Submissions
Source: https://docs.dune.com/web-app/decoding/solana-decoding-submissions

How to submit Solana programs for IDL decoding on Dune — UI flow, requirements, IDL validation, new vs upgrade submissions, and what to expect.

Decoding turns raw Solana instruction data into human-readable, queryable tables. Dune supports **Anchor**, **native**, and **system** programs. Submissions are validated and then written to the decoding pipeline; once processed, decoded tables appear under a `{namespace}_solana` schema.

# How to submit

1. Go to **[dune.com/contracts/new](https://dune.com/contracts/new)** (you must be logged in).
2. In **"Search for decoding submission"**, open the blockchain dropdown and select **Solana**.
3. Enter the **program address** (Solana program ID). For **Anchor** programs, Dune may fetch the IDL from chain and pre-fill it.
4. Select **program type**: **Anchor**, **Native**, or **System**.
5. In **"Program information"**, fill in **project name**, **program name**, **start block slot** (and optionally **end block slot**), and paste or edit the **IDL**. The preview can help you find a suitable start slot for new programs or upgrades.
6. Click **Submit**. The submission is validated (client- and server-side); if validation passes, it is sent to the pipeline and you are redirected to your workspace **Contracts** page. You can also check status under **Settings → Contracts**.

<CardGroup>
  <Card title="Submit a Solana program" icon="file-import" href="https://dune.com/contracts/new">
    Select Solana, then fill program address, type, names, slot range, and IDL.
  </Card>

  <Card title="Explore decoded Solana data" icon="table" href="/data-catalog/solana/idl-tables">
    Learn how decoded tables are named and how to query them.
  </Card>
</CardGroup>

# What you need to submit

| Field                         | Description                                                                                                                                                                                                                                        |
| ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Program ID**                | The Solana program address (base58). Entered in the "Search for decoding submission" address field.                                                                                                                                                |
| **Project name**              | The protocol or project name (e.g. `jupiter`, `marinade`, `raydium`). Lowercase, no spaces; use underscores if needed (e.g. `my_protocol_v2`). Used as the schema namespace: `{project_name}_solana`.                                              |
| **Program name**              | The program name as given by the project (e.g. `JupiterV6`, `MarinadeFinance`). Must match the IDL program name.                                                                                                                                   |
| **Program type**              | **Anchor**, **Native**, or **System**. Determines how instruction data is decoded.                                                                                                                                                                 |
| **IDL**                       | Interface Description Language JSON. For Anchor programs with on-chain IDL, it may be auto-filled when you enter the program address; otherwise paste from [Solscan](https://solscan.io) (e.g. "Anchor Program IDL" tab) or from the project repo. |
| **Start block slot**          | The slot from which this IDL version is valid. For new programs, use deployment or first-use slot; for upgrades, the slot where the new version became active. The UI preview can suggest a value.                                                 |
| **End block slot** (optional) | If the program was upgraded or deprecated, the last slot this version was active. Leave blank if still active.                                                                                                                                     |

<Note>
  **Finding the IDL**

  * **Anchor programs:** Many expose the IDL on-chain. Use [Solscan](https://solscan.io) (e.g. [Jupiter](https://solscan.io/account/JUP4Fb2cqiRUcaTHdrPC8h2gNsA2ETXiPDD33WcGuJB#anchorProgramIDL)) or the project's GitHub (e.g. `sdk/src/artifacts/*.json`).
  * **Native programs:** No IDL is published automatically — you must write one manually. See below.
</Note>

## Writing an IDL for native programs

Native programs don't use Anchor, so there is no auto-generated IDL. You need to construct one manually in [Anchor IDL format](https://github.com/solana-idl-foundation/solana-idl-spec), using the program's source code or documentation as the reference.

Key things to get right:

* **Instruction discriminators** — Native programs typically identify instructions via the first byte(s) of instruction data (e.g. a `u8` enum variant index). Check the program's Rust source for the instruction enum to find the correct discriminator value for each instruction.
* **Argument types** — All instruction arguments must be borsh-serializable. Map the Rust types in the instruction struct fields to their IDL equivalents (e.g. `u64`, `i64`, `publicKey`, `bool`, custom structs defined in `types`).
* **Account ordering** — List accounts in `accounts` in exactly the order the program expects them. The names you give them will become the `account_<name>` columns in the decoded table.
* **Program name** — Set `name` (or `metadata.name`) to match the program name you enter in the submission form. Use only letters, numbers, and underscores.

If the program is open source, the canonical reference is the instruction enum and its `Pack`/`BorshDeserialize` implementations in the Rust source. If source is unavailable, transaction data on [Solscan](https://solscan.io) or [Explorer](https://explorer.solana.com) can help you reverse-engineer the instruction layout.

# IDL requirements

Your IDL is validated in the UI and server-side before approval. The following must hold:

* **Valid JSON** — No trailing commas, valid escaping. Doc comments and `errors` arrays are stripped during validation.
* **Program name** — Must be set (in `metadata.name` or top-level `name`) and contain only letters, numbers, and underscores (no hyphens).
* **Custom types** — Every custom type referenced in instructions, accounts, or other types must be defined in the `types` array.
* **Instruction args** — Only types that use **borsh** serialization are allowed in instruction arguments. Other serializations (e.g. bytemuck) are not supported for instruction decoding.
* **No generics** — IDLs that use generic type definitions are not supported.

If the IDL fails validation, the submission will be **rejected** with a reason (e.g. invalid program name, missing type definition, or non-borsh type in instructions). The UI runs validation before submit and shows validation errors.

# New vs upgrade submissions

* **New program** — First time submitting this program (no existing entry for this project + program ID). In the UI, use submission type **New**. Provide the IDL and the slot range where it is valid.
* **Upgrade** — The program is already decoded and you are adding a new IDL version (e.g. after a program upgrade). Use submission type **Upgrade** in the UI.
  * **Soft upgrade:** Your new **start block slot** is **after** the end of the current active entry (no overlap). These are **approved automatically**. The previous version is closed at `end_slot = your start_slot`, and the new version is added.
  * **Hard upgrade:** Your new **start block slot** **overlaps** with an existing version’s range. These are marked for **manual review** so the team can confirm slot boundaries and avoid conflicting decoding.

When in doubt, use the slot where the new program or IDL version actually became active on-chain. The in-app preview (e.g. min/max instruction calls, existing program entries) can help you choose slots.

# Submission status and what happens next

After you submit:

1. **Pending** — The submission is in the queue and will be validated (IDL checks, upgrade logic).
2. **Approved** — Validation passed. The submission is then processed and written to the decoding pipeline (`solana.programs` and related systems).
3. **Rejected** — Validation failed (e.g. invalid IDL, empty required field). Check the rejection reason and fix the submission.
4. **Needs manual review** — Typically a hard upgrade (overlapping slots). The team will review and either approve or reject.
5. **Processed** — The program has been written to the pipeline. Decoded tables will appear and backfill; this can take some time (similar to EVM decoding latency).

**Where to check status:** Go to your workspace **Contracts** page or **Settings → Contracts**.

# Decoded table naming and usage

Once processed, decoded instructions appear as tables named:

```text theme={null}
{namespace}_solana.{programName}_call_{instructionName}
```

Example: `whirlpool_solana.whirlpool_call_initializePool`. Columns include the decoded instruction arguments and account arguments (with a `call_` prefix for inherited fields like `call_tx_id`, `call_block_time`). For details and examples, see [Solana IDL decoded tables](/data-catalog/solana/idl-tables).

# Summary

| Topic              | Detail                                                                                                                            |
| ------------------ | --------------------------------------------------------------------------------------------------------------------------------- |
| **Submit**         | **[dune.com/contracts/new](https://dune.com/contracts/new)** → select Solana → fill the form.                                     |
| **Fields**         | Program ID, project name, program name, program type (Anchor/Native/System), IDL, start (and optional end) block slot.            |
| **IDL**            | Valid JSON, program name (letters/numbers/underscores), all custom types in `types`, borsh-only in instruction args, no generics. |
| **Upgrades**       | Soft (no slot overlap) → auto-approved; hard (overlap) → manual review.                                                           |
| **After approval** | Entry is processed and written to the pipeline; decoded tables appear under `{namespace}_solana` with some delay.                 |

For more on querying decoded Solana data, see [IDL decoded tables](/data-catalog/solana/idl-tables). For EVM contract decoding, see [How contract decoding works](/web-app/decoding/decoding-contracts).


# AI Query Tools
Source: https://docs.dune.com/web-app/dune-ai

Use AI-powered tools to generate, edit, and debug SQL queries in the Dune query editor.

**Dune is launching a beta suite of tools for writing SQL queries with the help of large language models.**

### Wand Create

The Wand Create feature allows you to automatically generate SQL queries from natural language questions. It utilizes a suite of Dune-specific few-shot examples and automatically fetches table schemas to include in the prompt. (You must explicitly include the relevant tables in your natural language question to include table schemas.)

This feature simplifies the process of writing getting started writing a SQL query, especially for users who may not be familiar with the database structure. Your mileage may vary depending on the complexity of your question and how well the underlying tables are suited to answering it. We recommend using this feature as a starting point and then refining the query using the Wand Edit feature.

You can find this feature in the query page below the query editor.

<div>
  <iframe />
</div>

### Wand Edit

The Wand Edit feature allows you to edit an existing SQL query based on a natural language question. Similar to query generation, any additional tables required should be explicitly included in the natural language edit request to make use of schemas. This feature simplifies the process of refining and fine-tuning SQL queries generated by the system or existing queries in your application.

You can find this feature in the query editor and click the wand logo in the top right corner to open the Wand bar.

<div>
  <iframe />
</div>

#### Adding statistics to a query

Add the remaining components of a five point summary.

Original query:

```sql theme={null}
SELECT 
    date_trunc('day', block_time) AS time
    , (PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY gas_price))/1e9  AS median_gas
    , COUNT(*) AS daily_tx
FROM ethereum.transactions
GROUP BY time
```

Edited query:

```sql theme={null}
SELECT 
    date_trunc('day', block_time) AS time
    , MIN(gas_price)/1e9 AS min_gas
    , (PERCENTILE_CONT(0.25) WITHIN GROUP (ORDER BY gas_price))/1e9 AS lower_quartile_gas
    , (PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY gas_price))/1e9  AS median_gas
    , (PERCENTILE_CONT(0.75) WITHIN GROUP (ORDER BY gas_price))/1e9 AS upper_quartile_gas
    , MAX(gas_price)/1e9 AS max_gas
    , COUNT(*) AS daily_tx
FROM ethereum.transactions
GROUP BY time
```

#### Adding a join to a query

Join nft.wash\_trades to nft.trades to get the percentage of sellers who have been involved in wash trading.

Original query:

```sql theme={null}
SELECT  date_trunc('day', block_time) as day, COUNT(distinct seller) as sellers
FROM nft.trades
WHERE project = 'blur'
GROUP BY 1
```

Edited query:

```sql theme={null}
SELECT  
    date_trunc('day', t.block_time) as day, 
    COUNT(distinct t.seller) as sellers, 
    COUNT(distinct wt.seller) as wash_traders, 
    (COUNT(distinct wt.seller) * 100.0 / COUNT(distinct t.seller)) as wash_traders_percentage
FROM 
    nft.trades t
LEFT JOIN 
    nft.wash_trades wt ON t.seller = wt.seller
WHERE 
    t.project = 'blur'
GROUP BY 
    1
```

#### Reformat Output

Return monthly volume with each year from 2023 to 2019 as a separate column

Original query:

```sql theme={null}
SELECT
 DATE_TRUNC('month', block_time),
 SUM(CAST(amount_usd AS DOUBLE)) AS usd_volume
FROM
 dex.trades AS t
WHERE
block_time > CAST('2019-01-01' AS TIMESTAMP)
GROUP BY
 1
```

Edited query:

```sql theme={null}
SELECT
  DATE_TRUNC('month', block_time) AS month,
  SUM(CASE WHEN EXTRACT(YEAR FROM block_time) = 2019 THEN CAST(amount_usd AS DOUBLE) ELSE 0 END) AS usd_volume_2019,
  SUM(CASE WHEN EXTRACT(YEAR FROM block_time) = 2020 THEN CAST(amount_usd AS DOUBLE) ELSE 0 END) AS usd_volume_2020,
  SUM(CASE WHEN EXTRACT(YEAR FROM block_time) = 2021 THEN CAST(amount_usd AS DOUBLE) ELSE 0 END) AS usd_volume_2021,
  SUM(CASE WHEN EXTRACT(YEAR FROM block_time) = 2022 THEN CAST(amount_usd AS DOUBLE) ELSE 0 END) AS usd_volume_2022,
  SUM(CASE WHEN EXTRACT(YEAR FROM block_time) = 2023 THEN CAST(amount_usd AS DOUBLE) ELSE 0 END) AS usd_volume_2023
FROM
  dex.trades AS t
WHERE
 block_time >= CAST('2019-01-01' AS TIMESTAMP)
GROUP BY
  1
```

#### Adding a CTE

Add a CTE to calculate the number of mints with nft.mints by day and then return the average number of mints per day and join it to the existing query

Original query:

```sql theme={null}
select
 date_trunc('day', block_time) as dt
 ,count(hash) as num_transactions
 ,count(distinct "from") as users
 ,sum(gas_used) as gas_used
 ,avg(gas_used) as avg_gas_used
 ,avg(gas_price)/1e9 as avg_gas_price
from ethereum.transactions
where
 success
 and block_time >= cast('2022-01-01' as date)
 and date_trunc('day', block_time) < date_trunc('day', current_timestamp)
group by 1
```

Updated query:

```sql theme={null}
WITH daily_mints AS (
    SELECT 
        date_trunc('day', block_time) as dt,
        count(*) as num_mints
    FROM nft.mints
    WHERE 
        block_time >= cast('2022-01-01' as date) 
        and date_trunc('day', block_time) < date_trunc('day', current_timestamp)
    GROUP BY 1
)

SELECT 
    et.dt,
    et.num_transactions,
    et.users,
    et.gas_used,
    et.avg_gas_used,
    et.avg_gas_price,
    dm.num_mints,
    avg(dm.num_mints) over () as avg_daily_mints
FROM (
    SELECT 
        date_trunc('day', block_time) as dt,
        count(hash) as num_transactions,
        count(distinct "from") as users,
        sum(gas_used) as gas_used,
        avg(gas_used) as avg_gas_used,
        avg(gas_price)/1e9 as avg_gas_price
    FROM ethereum.transactions
    WHERE 
        success
        and block_time >= cast('2022-01-01' as date) 
        and date_trunc('day', block_time) < date_trunc('day', current_timestamp)
    GROUP BY 1
) et
LEFT JOIN daily_mints dm ON et.dt = dm.dt
```

## Wand Debug

The Wand Debug feature helps fix SQL queries that have syntax errors. When an executed query encounters a syntax error, the Fix Query button should appear in the results/visualization panel. Clicking this button collect your query and the error message and send it to the Wand Debug feature. The Wand Debug feature will then attempt to fix the query and return the fixed query to you. If the Wand Debug feature is unable to fix the query, it will return the updated query with message indicating it is not fully debugged. The query submitted for debugging will be saved in your query history, so you can also recover it.

You can find this feature in the results/visualization panel if you've executed a query that failed on a syntax error.

<div>
  <iframe />
</div>


# Google SSO Domain Restriction
Source: https://docs.dune.com/web-app/google-sso-domain-restriction

Restrict team join requests via Google SSO to the admin's email domain.

<Note>
  **Enterprise Feature** — Domain-restricted SSO is available on the [Enterprise plan](https://dune.com/enterprise). [Contact sales](https://dune.com/enterprise) to learn more.
</Note>

<Info>
  If your teams are under a Dune **[organization](/web-app/organizations)**, manage Google SSO domain restriction in **organization settings → Security**. Team-level Security does not control this for those teams.
</Info>

Dune can restrict **Google SSO join requests** so that only users with an email address on an approved domain can join your team.

## How the allowed domain is determined

The **allowed domain is automatically set to the email domain of the team admin** who enables the setting.

Example:

* If the admin enabling the setting has `admin@dune.com`, then the allowed domain will be `dune.com`.

## What this setting does

When enabled:

* Only users signing in with Google SSO using the **allowed domain** can join the team.
* Users attempting to join with a different email domain will be blocked.

This is useful to prevent personal Gmail accounts (or other unapproved domains) from joining your team.

## Before you enable this

> **Important:** You must remove any existing team members whose email domain does **not** match the admin’s domain **before** enabling this setting.

Also note:

* While enabled, **users cannot change their email address** in Dune.
* Users who previously used **email/password** will be prompted to sign in using **Google SSO**.

## Enable Google SSO domain restriction

1. Go to **Settings → Security & Privacy → Google SSO domain restriction**.
2. Toggle **Restrict Google SSO** on.
3. **Authenticate** your email domain.

Once enabled, Dune will display the allowed domain (for example: `dune.com`) in the setting.


# Okta SSO Setup
Source: https://docs.dune.com/web-app/okta-sso

Configure Okta SSO (OIDC) for your Dune team, including domain verification and redirect URLs.

<Note>
  **Enterprise Feature** — Okta SSO is available on the [Enterprise plan](https://dune.com/enterprise). [Contact sales](https://dune.com/enterprise) to learn more.
</Note>

<Info>
  If your teams are under a Dune **[organization](/web-app/organizations)**, configure Okta SSO and SSO domains in **organization settings → Security**. The steps below are the same in principle; open them from the organization, not an individual team.
</Info>

This guide walks you through enabling **Okta SSO** for your Dune team using **OIDC**.

## Prerequisites

You’ll need:

* Admin access for your **Dune team**
* Admin access for your **Okta tenant**
* Access to your domain’s **DNS provider** (to add TXT records)

## Step 1 — Add and verify your SSO domain(s)

1. In Dune, go to **Settings → Security & Privacy → Okta authentication**.
2. Under **Configure SSO domains**, click **Add domains**.
3. Enter the email domain(s) your team uses (for example, `company.com`).

### Verify the domain (DNS TXT record)

After adding a domain, it may show as **Pending**. Dune will display DNS instructions like:

* **Host**: `dune-verification`
* **Type**: `TXT`
* **Value**: a unique verification token

Add a TXT record in your DNS provider:

* **Name / Host**: `dune-verification` (some providers require the full name like `dune-verification.company.com`)
* **Type**: `TXT`
* **Value**: (paste the token from Dune exactly)

Then return to Dune and click **Verify** next to the domain.

> **Tip** DNS changes can take time to propagate. If verification fails, double-check the host/name formatting in your DNS provider and try again after propagation.

## Step 2 — Create an Okta OIDC app (Web)

In Okta:

1. Go to **Applications → Create App Integration**.
2. Choose **OIDC - OpenID Connect**.
3. Choose **Web Application**.
4. In the app settings, add the **Sign-in redirect URIs** shown in Dune.
5. Save the app.

> **Note** Use the redirect URIs **exactly** as shown in Dune. A mismatch is the most common cause of Okta sign-in errors.

## Step 3 — Copy Okta credentials into Dune

Back in Dune (**Settings → Security & Privacy → Okta authentication**), fill in:

* **Client ID**: from your Okta OIDC application
* **Client secret**: from your Okta OIDC application
* **Okta domain**: your Okta org URL, for example:
  * `https://your-domain.okta.com`

## Step 4 — Enable Okta SSO

1. Make sure at least one domain shows as **Verified**.
2. Toggle **Enable Okta SSO** on.
3. Click **Enable**.

> **Important**
>
> * Existing members with **non-matching domains must be removed** before enabling.
> * Users **cannot change their email** while Okta SSO is enforced.
> * Users with **email/password** accounts will be prompted to log in with Okta SSO.


# Organizations
Source: https://docs.dune.com/web-app/organizations

Enterprise organizations group multiple teams under one subscription, shared usage, and centralized security and billing controls.

<Note>
  **Enterprise** — Organizations are provisioned for companies on an Enterprise agreement. [Contact sales](https://dune.com/enterprise) if your company needs multiple teams under a single contract and administrative layer.
</Note>

An **organization** on Dune is an administrative and billing container for **multiple teams**. It suits enterprises that want several team workspaces while keeping one subscription, consolidated usage, and consistent security policies.

Organizations are optional. Standalone teams (not linked to an organization) continue to work as described in [Teams and Roles](/web-app/teams): they hold their own plan, usage, and security settings.

## How organizations relate to teams

| Layer            | What it owns                                                                                                  | Typical responsibilities                                              |
| ---------------- | ------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- |
| **Organization** | The Enterprise subscription, organization-wide usage pool, invoices, and organization-level security policies | Company administrators align billing, credit policy, and who may join |
| **Team**         | Queries, dashboards, API keys, uploads, and [team roles](/web-app/teams) (admin, editor, viewer)              | Day-to-day analytics work and collaboration                           |

Teams under an organization behave like other teams for **content**: creation, sharing, ownership transfer, and the context switcher work the same way. What differs is that **billing, plan, and certain security controls live at the organization**, not on each team.

## Plans and usage

* The **organization** carries the **paid Enterprise subscription**. Individual teams inside it do **not** have separate plans; they draw from the organization’s entitlements and usage pool.
* **Organization administrators** can govern how usage is shared:
  * **Organization extra credit limit** — Optionally cap pay-as-you-go (extra) spend for the **entire** organization.
  * **Team usage limits** — Optionally set **per-team credit caps** so teams cannot consume the full pool without limits, while still respecting the organization’s overall allowance.

Exact limits and commercial terms are defined in your agreement with Dune.

## Organization membership and roles

Users can be members of an organization with one of two roles:

* **Admin** — May open **organization settings** and manage teams, people, plan, usage, security, and organization profile (where the product allows).
* **Member** — May participate in teams according to **team** membership; they do not manage organization-level settings.

This is separate from **team** roles (admin, editor, viewer on a given team). A user can be an organization member and have different roles on different teams.

## Opening organization settings

Organization settings are available only to users whose organization role is **Admin**.

1. Open the **global context switcher** at the top of Dune.
2. Find your **organization** in the list.
3. Select the **more options** menu (three dots) next to the organization name.
4. Choose the section you need — for example **Teams**, **People**, **Usage**, **Plan**, **Security**, or **Profile**.

The product opens the corresponding page under `https://dune.com/settings/o/…` (the exact path is assigned for your organization).

### What each section covers

* **Teams** — List teams in the organization, open **Add team** to create another team workspace, and manage team-level actions available from this view.
* **People** — View organization members and, as an organization admin, assign **Admin** or **Member** at the organization level.
* **Usage** — Monitor consumption for the organization, including breakdowns that help you understand usage across teams.
* **Plan** — Subscription details, billing address and payment method where applicable, invoices, and the **Enable limits** controls (organization-wide extra credit cap and optional per-team usage limits).
* **Security** — Organization-wide controls including **Google SSO domain restriction**, **Okta SSO**, optional **Okta event hook** configuration when Okta is enabled, and **two-factor authentication** requirements. These apply to how people join and authenticate under the organization’s policy.
* **Profile** — Organization display name and profile image.

## Teams under an organization

When a team belongs to an organization:

* The **Plan** tab is **not** shown in that team’s settings — billing and plan changes are handled in **organization settings → Plan**.
* **Security & Privacy** settings that are governed at the organization (SSO domains, Okta, mandatory two-factor) are **locked at the team level**; configure them under **organization settings → Security**. Team-level options that remain (such as default content privacy where applicable) still appear in the team’s Security tab.

For step-by-step SSO setup, see [Google SSO domain restriction](/web-app/google-sso-domain-restriction) and [Okta SSO setup](/web-app/okta-sso). When your teams are under an organization, complete those steps in **organization** security settings unless your onboarding specifies otherwise.

## Related documentation

<CardGroup>
  <Card title="Teams and Roles" icon="users" href="/web-app/teams">
    Team workspaces, invites, and team roles
  </Card>

  <Card title="Enterprise plan" icon="building" href="/enterprise/data-hub/overview">
    Enterprise capabilities and how to engage with Dune
  </Card>
</CardGroup>


# Data Hub Overview
Source: https://docs.dune.com/web-app/overview

The Dune Data Hub is your central workspace for querying, visualizing, and sharing blockchain data insights.

The Data Hub is Dune's web-based workspace where you query blockchain data with SQL, build visualizations, assemble dashboards, and share insights with your team or the public. It is one of several ways to work with Dune's data -- alongside the [Data API](/api-reference/api-overview), [dbt integration](/api-reference/connectors/dbt/overview), [BI tool connectors](/api-reference/connectors/trino/overview), and [Datashare](/datashare/datashare).

<img alt="Data transformations on Dune" />

## Prerequisites

* **Dune Account:** [Sign up here](https://dune.com/auth/register) if you do not already have one.
* **Basic SQL Knowledge:** Dune uses DuneSQL, a SQL dialect compatible with TrinoSQL. If you are new to SQL, [start here](https://www.w3schools.com/sql/).

## What You Can Do

<CardGroup>
  <Card title="Write and Run Queries" icon="code" href="/web-app/query-editor">
    Use the Query Editor to write SQL against blockchain data, add parameters, and schedule automated runs.
  </Card>

  <Card title="Visualize and Present Results" icon="chart-bar" href="/web-app/visualizations/charts-graphs">
    Turn query results into charts, counters, tables, and interactive dashboards.
  </Card>

  <Card title="Automate and Monitor" icon="clock" href="/web-app/query-editor/query-scheduler">
    Schedule queries and dashboards to refresh automatically. Set up alerts for email or webhook notifications.
  </Card>

  <Card title="Share and Embed" icon="share-nodes" href="/web-app/share">
    Share dashboards by URL, embed live visualizations on any website, or export data via CSV and API.
  </Card>

  <Card title="Import and Export Data" icon="arrow-right-arrow-left" href="/web-app/upload-data">
    Upload your own CSV datasets to join with blockchain data. Export query results in CSV or JSON.
  </Card>

  <Card title="Decode Smart Contracts" icon="file-code" href="/web-app/decoding/decoding-contracts">
    Submit contracts for decoding to create structured, queryable tables from raw transaction bytecode.
  </Card>

  <Card title="Manage Your Team" icon="users" href="/web-app/teams">
    Create team workspaces, assign roles, share credits, and configure SSO for your team.
  </Card>

  <Card title="Organizations" icon="building" href="/web-app/organizations">
    Enterprise: multiple teams under one subscription, shared usage, and centralized security and billing.
  </Card>

  <Card title="Search and Discover" icon="magnifying-glass" href="/web-app/search">
    Find dashboards, queries, and analysts across Dune using search, discovery, and advanced filters.
  </Card>
</CardGroup>

## Quick Start

Get from zero to a published dashboard in five minutes:

1. **Create a query** -- Open the [Query Editor](https://dune.com/queries) and write SQL. For example, daily Ethereum active addresses:

```sql theme={null}
SELECT
  date_trunc('day', block_time) AS time,
  COUNT(DISTINCT "from") AS active_senders
FROM ethereum.transactions
WHERE block_time > DATE '2024-01-01'
GROUP BY 1
ORDER BY 1
```

2. **Run and save** -- Click **Run** to execute, then **Save** to persist your query.

3. **Add a visualization** -- Click **New Visualization**, choose a chart type, and configure your axes.

4. **Build a dashboard** -- Go to **Create > New Dashboard**, name it, then add your visualization as a widget.

5. **Share it** -- Copy the dashboard URL or use the **Share** button to embed it externally.

For a detailed walkthrough, see [Create Your First Query](/learning/how-tos/create-your-first-query) and [Create Your First Visualization](/learning/how-tos/create-your-first-visualization).

## Next Steps

* **[Query Templates](/learning/how-tos/query-templates):** Pre-built queries you can customize immediately.
* **[Data Catalog](/data-catalog/overview):** Explore all available blockchain data tables.
* **[Video Tutorials](/resources/learning/video-tutorials):** Visual walkthroughs of every Data Hub feature.


# Find Data Tables with the Data Explorer
Source: https://docs.dune.com/web-app/query-editor/data-explorer

Use the Data Explorer in Dune's query editor to browse, search, and inspect blockchain data tables for your analysis.

The Data Explorer is the left-side panel of the [query editor](/web-app/query-editor). It gives you direct access to Dune's full [Data Catalog](/data-catalog/overview) — so you can search for tables, inspect schemas, and add columns to your query without leaving the editor.

## Searching for Data

The search bar at the top of the Data Explorer supports a wide range of inputs. You can search by dataset name, contract address, table name, or any relevant keyword. If you already know what you are looking for, this is the fastest way to find it.

<div>
  <iframe title="Search for a Contract and Explore Its Event Data" />
</div>

## Data Explorer Sections

The Data Explorer organizes Dune's data into the following sections, from top to bottom:

1. Click on one of the categories in the left sidebar to see the tables available in that category.
2. Filter the tables through the dropdowns in the top right corner.
3. Check out the table preview to see what data is available in that table.
4. Click on the arrow next to the table name to include it in your query.

<div>
  <iframe title="Query Ethereum Blockchain Log Data" />
</div>

### Curated Data

Curated tables are pre-built, analytics-ready datasets that standardize on-chain activity across hundreds of blockchains. Examples include `dex.trades`, `nft.trades`, `tokens.transfers`, and `prices.usd`. These tables are designed to let you start querying immediately without needing to understand raw blockchain structures.

For a full overview of available curated datasets, see the [Curated Data Overview](/data-catalog/curated/overview).

### My Data

The My Data section surfaces data that is specific to your account and workspace:

* **Favorites** — Tables you have starred for quick access.
* **Connected Data** — External data sources you have connected to your workspace.
* **Materialized Views** — Query results that you have saved as reusable tables.
* **Uploaded Data** — CSV files you have [uploaded](/web-app/upload-data) to Dune.
* **This Query** — Tables referenced in the query you currently have open.

### Partner Data

Partner datasets are off-chain and specialized data provided by third-party data partners. These include datasets from providers such as Farcaster, Hyperliquid, Reservoir, Snapshot, and others. For the full list, see the [Data Catalog](/data-catalog/overview#community-data).

### Decoded Projects

Decoded tables contain smart contract activity that has been translated from raw bytecode into human-readable tables using contract ABIs. You can filter decoded projects by chain, event name, or function name.

<Tip>
  Tables are only shown for functions and events that have been called on-chain. If you do not see a table you expect, confirm the function or event has been triggered. You can check using [this query](https://dune.com/queries/5261232) by entering your chain and contract address.
</Tip>

### Raw Blockchain Data

Raw tables contain transaction-level data as ingested directly from each blockchain — including blocks, transactions, logs, and traces. Dune supports hundreds of blockchains, spanning EVM-compatible chains, Solana, Bitcoin, TRON, and many more. For the full list, see the [Data Catalog](/data-catalog/overview).

## Inspecting Tables and Columns

Once you locate a table in the Data Explorer, you can interact with it in several ways:

* **View table overview** — Click on a table name to expand it and see its columns, data types, and a short description.
* **Click a column** — Clicking on a specific column name will automatically insert it into your query in the central editor, saving you from typing it manually.
* **Three-dot menu** — Click the three-dot icon (⋯) next to any table name to access additional options:
  * **Preview table** — View a sample of the table's data directly in the editor.
  * **Add to favorites** — Star the table so it appears under My Data for easy access later.
  * **Find queries** — Discover existing queries on Dune that reference this table — useful for seeing practical examples.
  * **Copy as markdown** — Copy the full table schema as markdown for use in documentation or prompts.
  * **Open table page** — Navigate to the table's dedicated page, where you can find more in-depth information including the full schema, column descriptions, and a data preview.


# Query Editor Overview
Source: https://docs.dune.com/web-app/query-editor/index

Navigate and use the Dune Query Editor to write, run, and manage SQL queries against blockchain data.

The Query Editor is where you spend most of your time on Dune. It consists of three main areas:

## Left Sidebar

The left sidebar gives you quick access to data discovery and query management tools. The most important panel here is the **[Data Explorer](/web-app/query-editor/data-explorer)**, which connects you directly to Dune's full [Data Catalog](/data-catalog/overview) — letting you search for tables, inspect schemas, and insert columns into your query without leaving the editor.

* **Data Explorer** — Browse and search across curated datasets, decoded contracts, raw blockchain tables, partner data, and your own uploaded data. You can search by table name, contract address, or keyword. See [Find Data Tables](/web-app/query-editor/data-explorer) for a full guide.
* **Query Explorer** — Search for and locate existing queries relevant to your analysis.
* **[Version History](/web-app/query-editor/version-history)** — Review past edits to your query and revert to any previous version.
* **Settings** — Configure query-level settings such as ownership and privacy.

<Tip>
  Double-click any sidebar icon to collapse or expand it.
</Tip>

## Central Editor

The central editor is your main workspace for writing and running SQL. It includes a full-featured code editor with autocomplete, syntax highlighting, and inline error messages, along with a results panel where you can view output, sort columns, and build visualizations.

See [Writing Queries](/web-app/query-editor/query-window) for a detailed guide on editor features, autocomplete, keyboard shortcuts, and running queries.

## Right Sidebar

The right sidebar contains tools for automating and exporting your work once a query is ready:

* **[Query Scheduler](/web-app/query-editor/query-scheduler)** — Set queries to run automatically on a recurring schedule so your dashboards and data stay up to date.
* **[Materialized Views](/query-engine/materialized-views)** — Save query results as reusable tables that other queries can reference directly.
* **Export as CSV** — Download your query results for use in external tools or reports.
* **[Alerts](/web-app/alerts)** — Configure notifications that trigger when your query results meet specific conditions.

## Features at a Glance

<CardGroup>
  <Card title="Writing Queries" icon="pen" href="/web-app/query-editor/query-window">
    Write and execute SQL using autocomplete, run selection, and keyboard shortcuts.
  </Card>

  <Card title="Finding Tables" icon="table" href="/web-app/query-editor/data-explorer">
    Browse and search Dune's data catalog directly from the query editor sidebar.
  </Card>

  <Card title="Parameters" icon="sliders" href="/web-app/query-editor/parameters">
    Add variables to your queries for dynamic, reusable analysis.
  </Card>

  <Card title="Query Lineage" icon="sitemap" href="/web-app/query-editor/query-lineage">
    Visualize all tables, views, and nested query dependencies.
  </Card>
</CardGroup>


# Using Parameters
Source: https://docs.dune.com/web-app/query-editor/parameters

Parameters allow you to implement variables in certain parts of your Query. This is useful if you want to create a Query that you can reuse with different parameters.

Parameters allow you to implement variables in certain parts of your Query. This is useful if you want to create a Query that you can reuse with different parameters.

Parameters in Dune are versatile and can be used in many different ways. You can use them to:

* filter on a specific token
* filter on a specific token pair
* filter on a specific address
* filter on a specific date range
* filter on a specific category
* etc.

Parameters can be a **single value** or a **list of values** and you can choose **one** or **multiple** values from a pre-defined list of values. This list can be manually defined or populated from a different query.

**To use parameters:**

1. choose the spot in your Query where you want to implement a parameter
2. click on the add parameter button or type `{{example_parameter_name}}`
3. open the parameter options
4. configure your parameter's name, type, and default value

Parameters can be text, numbers, a date, a manual list of values or a list of values from a different query.

<div>
  <iframe title="Add a query parameter to filter results without editing SQL" />
</div>

### Parameters in Query Views

Parameters can also be used in [Query Views](/query-engine/query-a-query), allowing you to pass parameters several levels deep into nested queries. This powerful feature enables you to create complex, reusable query architectures where parameters flow through multiple layers of queries.

For example, you can create a base query with parameters, then use that query as a view in another query while passing different parameter values. This allows for modular query design and enables sophisticated dashboard architectures. See the [Query Views documentation](/query-engine/query-a-query) for detailed examples and syntax.

```sql theme={null}
-- Base query (query_123) with parameters
SELECT 
    project,
    sum(amount_usd) as volume
FROM dex.trades 
WHERE blockchain = '{{blockchain_param}}'
  AND block_time >= cast('{{start_date}}' as timestamp)
GROUP BY project
```

```sql theme={null}
-- Query that uses the base query as a view with parameters
SELECT 
    project,
    volume,
    volume * 0.003 as estimated_fees
FROM "query_123(blockchain_param='ethereum', start_date='2024-01-01')"
WHERE volume > 1000000
ORDER BY volume DESC
```

### Freeform parameters

Freeform parameters are useful if you want your users to be able to input any text, number or date value. An example of this would be a parameter that allows users to input an address, a token, or a date.\
The system will automatically detect the type of the value and insert it into the query as the correct type. You can also manually adjust the type within the query by using the `cast` function.

<img alt="freeform parameter" />

For example:

```sql theme={null}
-- freeform varbinary parameter
Select * from ethereum.transactions
where "from" = {{address_parameter}}
```

```sql theme={null}
-- freeform number parameter
Select * from dex.trades
where amount_usd > {{usd_amount_parameter}}
```

```sql theme={null}
-- freeform date parameter
Select * from dex.trades
where evt_block_time between cast('{{start_date_parameter}}' as timestamp) and cast('{{end_date_parameter}}' as timestamp)
```

### List parameters

List parameters are useful if you want your users to be able to choose **one** or **multiple values** from a pre-defined list of values. This list can be manually defined or populated from a different query.
Examples of this include parameters that allows users to choose from a list of tokens or a list of token pairs.

<img alt="list parameter" />

```sql theme={null}
--- list parameter allowing single value
Select * from dex.trades
where token_pair = ({{token_pair_parameter}})
```

or

```sql theme={null}
--- list parameter allowing with multiple values
Select * from dex.trades
where token in (Select token from unnest(split('{{token_list_parameter}}',',')) as c(token))
```

If you want to allow multiple values, you need to adjust your query for this. Use the `unnest` and `split` functions to turn the columns into useable values.
By default, the values will be inserted into the query as individual columns.
**Example**:\
A list of 3 selected values in a parameter called `example_parameter_name` will be inserted into the query like this:

```sql theme={null}
Select {{example_parameter_name}} 

/* returns 
| column1   | column2   | column3   |
| --------- | --------- | --------- |
| WETH-USDC | WBTC-USDC | DAI-USDC  |
*/
```

Most of the time, you'll want to use the values in a `where in` clause. To do this, you need to use the `unnest` and `split` functions to turn the columns into useable values.
For example:

```sql theme={null}
Select * from dex.trades
where token_pair in (Select pair from unnest(split('{{example_parameter_name}}',',')) as c(pair))
```

#### Manual list

When you manually define a list of values, the list can be text values, numbers, dates or even varbinary values. The system attempts to detect the type of the list values, but sometimes you might have to manually adjust the type within the query by using the `cast` function.

A very common example of using a manual list is setting the "time granularity" of a dashboard/query.

```sql theme={null}
Select 
    date_trunc('{{time_granularity_parameter}}', evt_block_time) as time, 
    sum(amount_usd) as amount_usd
from dex.trades
group by 1
/* parameter options:
    - default value: day
    - list values: day, week, month
*/
```

#### List from query results

You can use the results of a query as the list of values for a parameter. Doing this allows you to build dynamic dashboards that allow users to choose from a list of values that is populated by a different query. You can choose any query by its query\_id and any column by its name. The column data type will be transferred to the parameter.

<img alt="parameter from query results" />

<Note>
  **Query results**

  The query that you use to populate the list of values does not update automatically. You need to trigger a refresh of the query results to update the list of values. This can happen by either manually refreshing the query results or by setting up a [query schedule](web-app/query-editor/query-scheduler).
</Note>

This feature can be used in all kinds of ways, but here are a few examples:

* to choose from a list of tokens
* to choose from a list of token pairs
* to choose from a list of addresses or labels
* to single out specific products or categories

All of these examples could be solved with a manual list, but using a query to populate the list of values allows you to build dynamic dashboards that update automatically. It also can simply make it easier to manage a list of values that is shared between multiple queries.

**Example 1:**

You can use a distinct query on dex.trades to populate a list of all projects currently in dex.trades. This list can then be used in multiple queries.

```sql theme={null}
Select distinct project from dex.trades
```

[link to dashboard](https://dune.com/dune/query-result-parameter-showcase)

**Example 2:**

Filter on all available perpeptual futures available on synthetix. The master query for this is query\_3256054. We can use this query to populate a list of all available perps:

```sql theme={null}
--query 3256054 constructs the daily open interest for all synthetix perps
Select 
    distinct perp_name 
from query_3256054 
order by perp_name
```

We can then use this list of perps in query\_3256054 to make filtering on a specific perp possible:

```sql theme={null}
...
and perp_name in (Select perp_name from unnest(split('{{perp_name}}',',')) as b(perp_name))
```

[link to query](https://dune.com/queries/3256054/)

### Parameters in query descriptions

You can use parameters in the description of a query. This feature is useful to effortlessly report on the current value of a parameter. For example, you can use this to report on the current value of a parameter that is used in a dashboard.

<Note>
  You must first [create the parameter in your query](/web-app/query-editor/parameters#using-parameters) before you can reference it in the query description.
</Note>

<div>
  <iframe title="Edit the Description of a Dune Analytics Query" />
</div>

To use a parameter in a query description:

1. open your query settings
2. add the parameter to the query description by using the `{{example_parameter_name}}` syntax
3. save your query settings
4. your query description will now show the current value of the parameter

### Parameters in dashboards

If you want to use the same parameter between different queries on a dashboard, make sure to use exactly the same settings for the parameter in each query. The parameter will then be shared between the queries and only turn up once in the dashboard's parameter menu. Exactly the same settings means:

* the parameter name is the same
* the parameter type is the same
* the parameter default value is the same
* the parameter list of values is the same
* the query id and column name for a list of values from a query is the same


# Query Lineage
Source: https://docs.dune.com/web-app/query-editor/query-lineage

Visualize and trace all tables, views, and nested query dependencies within a query to understand data relationships efficiently.

### Overview

The Query Lineage section provides an organized, directed graph view of the tables, views, and [nested queries](../../query-engine/query-a-query) involved in your query.
This graph, displayed below the query editor, shows all tables, views, and other queries your query directly references.
When [a query references another query](../../query-engine/query-a-query), all levels of dependencies within those queries are shown.
For views, lineage stops at the first-level reference, offering a streamlined view without tracing further nested dependencies.

<img alt="query-lineage" />

This graph allows for an intuitive exploration of data relationships, as you can click on any referenced queries, tables, or views to jump directly to their definitions.

### Key Features

* **Interactive Graph Navigation:** Click through queries, tables, and views directly from the lineage graph to explore definitions.
* **Comprehensive Query Lineage:** Trace all levels of referenced queries to see the full path of data dependencies.
* **Simplified View Lineage:** Limit view lineage to the first level, reducing complexity in multi-layered dependencies.

### How Query Lineage Works

* **Full Query Lineage:** For each query, Query Lineage displays all tables, views, and queries it references. If a referenced query itself references additional queries or tables, those are also shown, providing the complete chain of dependencies.
* **Limited View Lineage:** For views, Query Lineage includes only the first-level reference. If a view references another view or table, further dependencies within those views are not displayed, offering a concise overview.

### Accessing Query Lineage

To view a query’s lineage:

1. Open a query in Dune’s Web App.
2. Navigate to the **Query Lineage** section below the query editor and next to the visualizations.
3. A directed graph of the query’s lineage will appear, with clickable links for each referenced query, table, or view.

To view the lineage graph in full-screen mode, click the expand icon in the top-right corner of the graph.

Different kinds of objects in the graph are displayed with distinct colors to help you quickly identify them: Dune-defined tables and views are shown in orange, Referenced queries appear in blue and Materialized views are displayed in green.


# Schedule Queries and Dashboards
Source: https://docs.dune.com/web-app/query-editor/query-scheduler

Schedule queries and dashboards to run automatically at defined intervals to keep your data fresh.

**Query Scheduling allows you to schedule a query to run at a specific time and frequency.**

Queries on Dune usually execute when a user triggers an automatic or interactive execution. This means that if you have a dashboard that is not frequently viewed, the data displayed on the dashboard may be outdated and execution of the queries will only be triggered once a user views the dashboard. Especially for dashboards that contain resource-intensive queries, this can lead to long loading times for the viewer.

To keep your dashboard up-to-date and to ensure that your queries are executed reliably and in a timely manner, you can schedule them to run at a specific time and frequency. Scheduled queries can be run on medium and large query engines, which will require credits. Credits are consumed based on actual compute resources used for each scheduled query execution.

### How to Schedule a Query

<div>
  <iframe title="Schedule automatic refreshes for a Dune query" />
</div>

1. Start by clicking the scheduler (clock) icon located at the bottom of the query editor, to the left of the "Run" button
2. A dialog will prompt you to set a refresh schedule and an execution tier. Please note that scheduled queries can only be run on medium and large query engines, which will require credits.
3. The dialog will display an estimated monthly credit consumption for this query scheduling, along with a monthly quota. These values will adjust based on the frequency and execution tier you select.
4. Save the schedule
5. Your query will execute once to start the schedule, and then will execute according to the schedule you set.

#### Query Scheduling Limitations

* Query scheduling is currently not available for queries with parameters.
* The query schedule is removed when the queries are archived or when the ownership changes (e.g., when a query is migrated).
* There are no notifications available for scheduled query failures as of now. Rest assured, these failures do not result in any charges to your account.

#### Adjusting or Cancelling a Query Schedule

To modify or cancel a query schedule, click the scheduler (clock) icon again to reopen the scheduling dialog. From there you can adjust the frequency, time, or execution tier. To stop the schedule entirely, scroll to the bottom of the dialog and click the **Stop** button.

<img alt="" />

### Scheduling entire dashboards

Instead of scheduling individual queries, you can also schedule entire dashboards. Learn more about scheduling dashboards [here](/web-app/dashboards#sharing-your-dashboard).


# Writing Queries
Source: https://docs.dune.com/web-app/query-editor/query-window

Write and execute SQL queries against blockchain data using Dune's query editor.

The query editor is where your team writes, tests, and iterates on SQL against Dune's blockchain datasets. Whether you're building production dashboards, validating on-chain metrics, or exploring data for the first time, the editor provides the tools to move from question to answer without leaving the browser.

<img alt="Query editor" />

<Note>
  The query editor uses **DuneSQL**, a Trino-based engine optimized for blockchain data. For syntax details, supported functions, and data types, see the [SQL Query Engine](/query-engine/overview) documentation.
</Note>

## Toolbar

The toolbar sits above the code editor and provides quick access to common actions.

| Tool                     | Description                                                                                                                                                             |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Edit SQL with prompt** | Type a natural language instruction to generate or modify SQL using AI. See [Dune AI](/web-app/dune-ai) for details.                                                    |
| **Add parameter** `{}`   | Insert a dynamic parameter into your query. Parameters let dashboard viewers filter data without editing SQL. See [Using Parameters](/web-app/query-editor/parameters). |
| **Format query**         | Auto-format your SQL with standard indentation and spacing for readability.                                                                                             |
| **Explain query**        | Generate an AI-powered plain-English summary of what your query does. Useful for onboarding teammates or documenting query logic.                                       |
| **Hide/Show SQL**        | Collapse the code editor to maximize screen space for results and visualizations. Click again to restore it.                                                            |

## Editor settings

Click the **Settings** (gear icon) in the top-right corner of the editor panel to customize your coding environment.

| Setting                 | Description                                                      |
| ----------------------- | ---------------------------------------------------------------- |
| **Fullscreen mode**     | Expand the editor to fill the entire screen.                     |
| **Syntax style**        | Change the color theme and syntax highlighting of your SQL code. |
| **Tab size**            | Set the indentation width (e.g., 2 or 4 spaces).                 |
| **Diff view**           | Choose how code changes are displayed (e.g., split view).        |
| **Enable autocomplete** | Toggle intelligent code completion on or off.                    |

## Writing and executing queries

### Autocomplete

The editor provides context-aware autocomplete for DuneSQL keywords, table names, and column aliases already referenced in your query. To manually trigger the autocomplete menu at any time, press `Ctrl/Cmd + Space`.

### Running queries

Click the **Run** button (or press `Ctrl + Enter`) to execute your query. Results appear in the results panel below the editor.

The **Try API** button next to Run generates an API endpoint for your query results, making it easy to integrate Dune data into external applications. See the [API documentation](/api-reference/overview/introduction) for more.

### Run selection

You can execute a specific portion of a query instead of the full statement. This is useful for testing subqueries, debugging intermediate results, or validating individual CTEs.

Highlight the portion of the query you want to run. The **Run** button updates to **Run selection**, and only the highlighted SQL is executed.

<img alt="Run selection" />

### Error handling

When a query fails, a red error banner appears at the top of the editor with details about the failure. Error messages include:

* **Error type** — e.g., `COLUMN_NOT_FOUND`, `SYNTAX_ERROR`
* **Line and character position** — the exact location of the issue in your SQL
* **Description** — a human-readable explanation of the problem

This inline feedback allows you to identify and fix issues without leaving the editor.

### Keyboard shortcuts

| Shortcut      | Action                    |
| ------------- | ------------------------- |
| Ctrl + Enter  | Execute the query         |
| Ctrl + # or / | Comment out selected code |
| Ctrl + Space  | Open autocomplete menu    |
| Ctrl + Z      | Undo last change          |
| Ctrl + Y      | Redo last change          |
| Ctrl + F      | Find text                 |
| Ctrl + H      | Find and replace text     |

*Shortcuts are based on US/UK keyboard layouts and may vary depending on your device's language settings.*

## Query results

Query results appear in a table below the editor after execution.

* **Sort** by clicking any column header. Click once for ascending order, click again for descending.
* **Paginate** through results using the page controls. Each page displays 25 rows.
* **Search** across all result rows using the search bar below the results table.

<img alt="Query results" />

### Column formatting

Each column in the results table can be individually configured without modifying your SQL:

| Option                      | Description                                                                 |
| --------------------------- | --------------------------------------------------------------------------- |
| **Title**                   | Rename the display header (e.g., change `transfer_volume_usd` to "Volume"). |
| **Align**                   | Set column alignment to left or right.                                      |
| **Format**                  | Apply number or currency formatting (e.g., `0.00`, `$0.0a`).                |
| **Hide column**             | Toggle column visibility to focus on relevant data.                         |
| **Colored negative values** | Automatically highlight negative numbers in red for easier trend analysis.  |

For full details on table formatting options, including progress bars and advanced number formats, see the [Formatting Tables](/web-app/visualizations/tables) documentation.


# Version History
Source: https://docs.dune.com/web-app/query-editor/version-history

Queries have a version history, where you can compare and revert to previous query versions.

All queries come with version history, where you can compare and revert to previous query versions seamlessly. **You can access version history from the query editor toolbar.**

<div>
  <iframe title="View Version History of a Query" />
</div>

<Note>
  **History Length**

  Everyone gets 30 days by default, you can upgrade your plan for longer history access.
</Note>

### Saving and Managing Versions

A new version is created each time you save or run your query. The first time you save a query — whether it is forked or freshly created — an initial version is committed to the history. If you've forked a query, the version history starts fresh; you won't have access to the original query's edit history.

Each subsequent run saves a new version automatically. If you leave the page without saving or running, any unsaved changes will be lost. You can also edit the metadata of any saved version — such as adding a title or description — to make it easier to identify later.

<div>
  <iframe title="Edit Metadata for a Saved Query Version" />
</div>

### Comparing and Reverting Versions

You can compare diffs between any two versions to see exactly what changed, and revert to a previous version if needed. **The reverted query is saved as a new version in the history**, so you never lose your current work.

<div>
  <iframe title="Compare Changes Between Query Versions" />
</div>


# Search and Discover Content
Source: https://docs.dune.com/web-app/search

Find dashboards, queries, analysts, and data across Dune using search, discovery, and your library.

Dune has over 100K dashboards and 700K saved queries. This guide covers every way to find the content you need.

## Global Search Bar

Click the search bar at the top of the page (or use `Cmd/Ctrl + P`) to search across all content types. Results display matching dashboards, queries, analysts, and teams. Click into a category (e.g., "Dashboards") to see an extended results list with sorting options.

<img alt="View more results" />

## Discover Page

Navigate to the Discover page to browse content by category: dashboards, queries, analysts, and teams. For dashboards and queries, you can sort by:

* **Favorites:** Most starred within a time period.
* **Trending:** Most popular within a selected period.
* **New:** Recently created content.

By default, the Discover page shows trending dashboards from the past 4 hours -- a useful way to spot emerging topics in crypto.

## Your Library

Visit your Library to find content you have personally created. You can organize your dashboards and queries into folders, and search, filter, and sort them. The Library is context-sensitive: when viewing a team profile, it shows that team's creations.

<Tip>When evaluating a dashboard from search results, check the number of stars it has and review the underlying query source code to verify its logic.</Tip>

## Advanced Search Filters

You can apply advanced filters in any of Dune's search fields (top bar or Discover sidebar).

Example: `nft tags:nft,opensea author:hildobby,denze` or `tags:usdc,usdt,dai -tags:ust`

| **Filter**       | **Description**                                             | **Example**                           |
| ---------------- | ----------------------------------------------------------- | ------------------------------------- |
| `title`          | Search by title. Wrap in double quotes if input has spaces. | `title:usdc` or `title:"dex tracker"` |
| `tags`           | Search by tag or tags.                                      | `tags:usdc`                           |
| `author`         | Search by author.                                           | `author:dune`                         |
| `description`    | Queries only. Find matches in the description.              | `description:usdc`                    |
| `code`           | Queries only. Find matches in the SQL code.                 | `code:"from dex.trades"`              |
| `created_before` | Only include matches created before a given date.           | `created_before:2023-01-30`           |
| `created_after`  | Only include matches created after a given date.            | `created_after:2023-01-30`            |
| `updated_before` | Only include matches updated before a given date.           | `updated_before:2023-01-30`           |
| `updated_after`  | Only include matches updated after a given date.            | `updated_after:2023-01-30`            |

* Combine multiple filters with free text: `stablecoins tags:usdc,usdt`
* Use double quotes for multi-word terms: `title:"layer zero"`
* Exclude results with a minus prefix: `-tags:ethereum`

<Note>Advanced search filters are currently supported for Dashboards and Queries only.</Note>


# Share and Embed
Source: https://docs.dune.com/web-app/share

Share your Dune queries, dashboards, and visualizations via links, social media, or embedded iframes.

Dune makes it easy to share your work with the world. Whether you want to send a link to a colleague, post a chart on social media, or embed a live visualization on your website, there are several ways to get your queries and dashboards in front of the right audience.

<img alt="Share panel" />

## Sharing a Query or Dashboard

To share, click the **Share** button located next to the title of any query or dashboard. This opens a share modal with the following options:

### Query URL

Copy the direct link to the query page. You can paste this anywhere — in a message, email, or document — to give someone a direct link to your work.

<Note>
  Private dashboards can also be shared by providing their URLs to users who have access.
</Note>

### Chart Link

Copy a link to a specific visualization. Use the dropdown in the share modal to select which chart output you want to share.

### Embed iframe

Copy the **Embed iframe** code to add live, auto-updating visualizations to any website:

```html theme={null}
<iframe src="https://dune.com/embeds/[query-id]/[visualization-id]" height="500" width="500"></iframe>
```

Instead of sharing static screenshots, embedded visualizations stay up to date as the underlying query re-runs. Simply paste the iframe snippet into your website's HTML.

<Tip>Enable **Share in dark mode** in the share modal for dark-themed embeds.</Tip>

### Social Sharing

Use the social icons in the share modal to share directly to LinkedIn, Telegram, X, or Threads.

## Embeds with Parameters

Embed links support [parameterized queries](/web-app/query-editor/parameters). The generated embed URL does not include parameters by default — you can append them manually to the URL:

```
https://dune.com/embeds/118220/238460/aa002dd3-f9e2-4d63-86c8-b765569306c6NFT?address=0xff9c1b15b16263c61d017ee9f65c50e4ae0113d7&rolling_n_trades=500
```

This lets viewers interact with different parameter values directly from the embedded chart on your site.

## Collaborate via Teams

For ongoing collaboration, [create a team](/web-app/teams) and invite colleagues as viewers or editors. Team members can share credits and work on shared queries and dashboards together.


# Teams and Roles
Source: https://docs.dune.com/web-app/teams

Create and manage team workspaces, invite members, assign roles, and collaborate on shared queries and dashboards.

Team accounts on Dune provide a shared workspace for collaboration. Teams can be created without a paid plan, but [Plus and Enterprise subscription features](https://dune.com/pricing) are available only to teams, not individual accounts.

<Info>
  **Enterprise organizations** — Companies with multiple Enterprise teams can use an **organization**: one subscription and administrative layer for many teams. Billing, consolidated usage, and some security settings are managed at the organization level; teams still own queries, dashboards, and API keys. See [Organizations](/web-app/organizations).
</Info>

**Key benefits:**

* **Collaborate on shared content.** Multiple team members work on the same queries and dashboards.
* **Shared credits and paid features.** All team members can spend credits and access private content.
* **Team profile.** Showcase all of your team's work in one place.
* **Role-based access.** Assign viewers, editors, or admins to control permissions.

## Create a Team

1. Navigate to the **global context switcher** at the top of the page.
2. Select **"Create new team"** from the dropdown.
3. Complete the team creation process.

<Note>Every team must have a unique name that has not been used before.</Note>

<div>
  <iframe title="Create a team" />
</div>

## Invite Members and Assign Roles

After creating your team, invite members and assign roles:

* **Admin:** Full control over settings, memberships, and content.
* **Editor:** Can create and edit queries and dashboards under the team.
* **Viewer:** Can view team content and spend credits.

Click **"Invite People"** in the team settings or share a direct invitation URL.

<div>
  <iframe title="Invite member after team creation" />
</div>

<Info>When you invite a user, they receive an email with a link to join. They can also go to [Settings > Teams](https://dune.com/settings/teams) to accept the invite.</Info>

## Team Content

Team queries and dashboards are created the same way as individual content. The **context** you are in (personal or team) determines who owns the content you create. You can change ownership of any query or dashboard in its Settings page.

<img alt="Team content" />

<Warning>Once you transfer content to a team, only an Admin can transfer it back out. If you accidentally transfer content, ask a team Admin to transfer it back.</Warning>

## Switch Between Contexts

Use the global context switcher to toggle between your personal account and team accounts. The context determines:

* Which content appears in "My Creations"
* Which credit balance is used for query execution
* Who owns newly created content

<img alt="" />

You can spend team credits on any content regardless of ownership, and edit team content from either context. Version History edits are always attributed to your personal account.

<div>
  <iframe title="Switch context" />
</div>

## Manage Subscriptions

<Note>
  Teams that belong to an **organization** do not have their own plan tab. Subscription, invoices, and organization-wide usage limits (including optional per-team credit caps) are managed in **organization settings**. See [Organizations](/web-app/organizations).
</Note>

Navigate to the team account settings page to:

* **Modify your plan:** Change subscription plan or switch to annual billing.
* **View usage statistics:** Check credits, CSV uploads, and private content quotas. You can also [export detailed credit usage data](https://docs.dune.com/learning/how-tos/credit-system-on-dune#export-credit-usage-data).
* **Manage additional credits:** Set a maximum dollar amount for pay-as-you-go credits in the "Limit extra credits" field (default is \$0).

<div>
  <iframe title="Credit usage in settings" />
</div>

## Transfer Ownership

You can transfer ownership of queries and dashboards between team members, teams, or your personal account.

### Transfer a Query

1. Click the cogwheel button to open query settings.
2. In the "Owner" dropdown, select the new owner — you can transfer to a team member or to a team.

<img alt="Transfer query ownership between a user and a team" />

### Transfer a Dashboard

1. Click **Edit**, then **Settings** to open the modal.
2. Select the new owner in the "Owner" dropdown.

<div>
  <iframe title="Change Dashboard Settings and Privacy" />
</div>

You can view ownership changes in the [Version History](/web-app/query-editor/version-history).

## FAQ

<Accordion title="Can I have private content?">
  Private dashboards and queries are available for the team or personal account they belong to.
</Accordion>

<Accordion title="How do I change my role?">
  Ask one of your team admins. Every team must always have at least one admin.
</Accordion>

<Accordion title="Can I remove people from my team?">
  Yes, in the People section of your team's Settings page.
</Accordion>

<Accordion title="Can I transfer content to another team?">
  Yes, in the Settings page of the query or dashboard you want to transfer.
</Accordion>

<Accordion title="Can I transfer content to another user?">
  Yes, but the target user must be a member of your team. If they are not, invite them first.
</Accordion>

<Accordion title="Can I transfer content to my personal account?">
  Yes, in the Settings page of the query or dashboard you want to transfer.
</Accordion>


# Upload Data
Source: https://docs.dune.com/web-app/upload-data

Upload your own data to Dune

**Easily upload your own data to Dune**

This feature allows you to upload any csv file to Dune and query it like any other table in Dune. Currently, we only support uploading CSV files with a maximum size of 200 MB. The app will return an error if the file size exceeds this limit.\
Additionally, column names in the table can't start with a special character or digits.

The files you upload will be queryable via the schema `dune.team_name.dataset_name`. For example, if you upload a file called `energy_data.csv` to the team `dune` and name the dataset `energy_data`, you will be able to query the data via `dune.dune.energy_data`.

You'll be able to query for your data in any query.

```sql theme={null}
Select * from dune.dune.dataset_energy_data
```

<Note>
  All data uploaded is public and can be accessed by anyone.\
  Private data uploads are available only on **Enterprise plans.**
</Note>

<Tip>
  You can also upload data via the API. Check out the [API documentation](/api-reference/tables/endpoint/upload) for more information.
</Tip>

<div>
  <iframe title="Upload a CSV dataset to Dune" />
</div>

1. Click on the "Upload Data" button in the menu of the Dune UI.
2. Select the csv file you want to upload.
3. Name your table and add a description.
4. Click on save to finish the upload.

## Querying for the data in Dune

Once the data has been uploaded, you can explore it in the my data section in the data explorer:

<div>
  <iframe title="Find and open an uploaded dataset in your Library" />
</div>

You can query for your data in any query.

```sql theme={null}
Select * from dune.dune.dataset_energy_data
```

To check whether the datatypes are correctly inferred, you can check the table details in the [data explorer](/web-app/query-editor/data-explorer).

## Updating data

Updating data is only possible via the [API](/api-reference/tables/endpoint/uploads-insert). In the UI you can only replace the data with a new (updated) file that carries the same name.

<Note>
  You can also use the [our SDKs](/api-reference/quickstart/tables-eg) to manage table uploads programmatically.
</Note>

However, you can use the "query a query" feature to query multiple .csv files at once.

**For example:**

```sql theme={null}
--query_2441513

Select * from dune.dune.dataset_energy_data_1

UNION ALL

Select * from dune.dune.dataset_energy_data_2

-- add more as it becomes relevant
```

In your main query, you could then simply refer to this query.

```sql theme={null}
Select * from ethereum.transactions t
left join query_2441513 q on q.address = t."from"
```

## Private data

If you don't want to share your data with the world, you can also upload private data. Private data is only visible to you and your team members.

To upload private data, **you need to be on an Enterprise plan**. If you are on an Enterprise plan, you can upload private data by toggling the "make table private" switch in the upload data modal.

You can also change the privacy settings of a dataset after it has been uploaded. To do so, go to settings -> data page and click on the three dots next to the dataset you want to change the privacy settings for. Then click on "make table private" to make the table private or "make table public" to make it public.

## Deleting data

You can delete your uploaded datasets from your Library.

<div>
  <iframe title="Delete an uploaded dataset from your Dune Library" />
</div>

1. Click on "Library" in the sidebar.
2. Click on "Data" in the next sidebar.
3. Search for your uploaded dataset or find it in the list.
4. Click on the three dots to open the options for the dataset.
5. Click on "Delete".

## Large Amounts of Data

If you want to share valuable off-chain data on Dune with your community, we are happy to discuss custom arrangements. Please reach indicate your interest via this [form](https://bit.ly/dune-data-integration).

This is only applicable for datasets with positive externalities for the Dune community. Examples include:

* [Farcaster](/data-catalog/community/farcaster/overview)
* [Reservoir](/data-catalog/community/reservoir/overview)
* [Flashbots](/data-catalog/community/flashbots/overview)


# Measuring User Activity
Source: https://docs.dune.com/web-app/user-activity

Explains how Dune tracks contributions across queries and dashboards.

# How Activity is Measured

<img alt="Activity heatmap showing user contributions over time" />

Activity on Dune is measured by combining different types of contributions:

### Query Activity

* Creating new queries (including temp queries)
* Updating existing queries
* Deleting queries

### Dashboard Activity

* Creating new dashboards

### Contract Activity

* Submitting new contracts

## Contributions Calculation

Each action counts as one contribution for that day. For example, if you:

* Create 2 queries
* Update 1 query
* Create 1 dashboard
* Submit 1 contract

Your total activity for that day would be 5 contribution.

The activity heatmap shows your daily activity over time, helping you track your contributions to the Dune ecosystem.


# Charts and Graphs
Source: https://docs.dune.com/web-app/visualizations/charts-graphs

Create bar charts, line charts, area charts, scatter charts, pie charts, and mixed visualizations from query results.

Visualizations make your data come to life. You can create a visualization from any query result to surface trends, compare metrics, and share insights visually.

<Tip>
  Watch our [visualization tutorial video](/resources/learning/video-tutorials#creating-graphs--charts) to see how to create charts step-by-step.
</Tip>

## Chart Types

Dune supports the following chart types. You can mix multiple types in a single visualization — for example, combining bars and lines — as long as your base chart is not a pie chart. Expand each type below to see an example.

<AccordionGroup>
  <Accordion title="Bar Charts" icon="chart-bar">
    <img alt="bar chart example" />
  </Accordion>

  <Accordion title="Area Charts" icon="chart-area">
    <img alt="area chart example" />
  </Accordion>

  <Accordion title="Scatter Charts" icon="chart-scatter">
    <img alt="scatter chart example" />
  </Accordion>

  <Accordion title="Line Charts" icon="chart-line">
    <img alt="line chart example" />
  </Accordion>

  <Accordion title="Pie Charts" icon="chart-pie">
    <img alt="pie chart example" />
  </Accordion>

  <Accordion title="Mixed Graphs" icon="chart-column">
    <img alt="mixed graph example" />
  </Accordion>
</AccordionGroup>

## Visualization Configuration Options

All chart types share a common set of configuration options. Use the tabs below to learn how to customize each aspect of your visualization.

<img alt="all visualization configuration options" />

<Tabs>
  <Tab title="Chart options">
    This section allows you to define how to display your data.

    <img alt="see explanations below" />

    **Title**

    * The title will appear in all instances of this graph prominently at the top.
    * The graph will always keep the name of the Query, even if you edit this.

    **Show chart legend**

    * Ticking this box will enable or disable the legend for the chart.

    **Enable stacking**

    * If applicable, ticking this box will stack the chart values on top of each other based on the x-axis values.
    * If this is not turned on, the values will be plotted individually on the y-axis.
    * The calculation underpinning this will always group the value corresponding to one value on the x-axis. Make sure your data is clean in able for this to work (avoid gaps in your data).

    **Normalize to percentage data**

    * This will normalize the chart to display percentage values of the chosen data table.
    * The calculation underpinning this will always group the value corresponding to one value on the x-axis. Make sure your data is clean in able for this to work (avoid gaps in your data).

    **Show data labels**

    * Ticking this box leads to the display of the individual datapoints inside of the graph.
    * This only makes sense in cases where you have few datapoints that are spread out far enough from each other to not overlap.
  </Tab>

  <Tab title="Result data">
    Here you can pick the data points that are to be displayed.

    <img alt="see explanations below" />

    You can choose one **x-axis** and multiple **y-axis.**

    Alternatively, you can also choose one data series on the y-axis and choose to group it by a different column of your table (as shown in the example above).
  </Tab>

  <Tab title="X-axis options">
    Using these options you can influence how your x-axis data gets displayed.

    <img alt="see explanations below" />

    **Axis title**

    * This field allows you to specify a title for your x-axis.

    **Sort Values**

    * by ticking this box you can specify if you want the values in your chart to be ordered.
    * If your x-axis is a time series, this will automatically happen.

    **Reverse value**

    * Ticking this box will reverse the order of the values on the x-axis.

    **Logarithmic**

    * Ticking this box will make your x-axis values display \_\_ logarithmically.
  </Tab>

  <Tab title="Y-axis options">
    With these options you can influence how your y-axis data gets displayed.

    <img alt="see explanations below" />

    **Axis title**

    * This field allows you to specify a title for your y-axis.

    **Logarithmic**

    * Ticking this box will make your y-axis values display logarithmically.

    **Enable right y-axis**

    * Ticking this box will enable an additional y-axis that you can plot values on.
    * You can choose in the [chart series section](web-app/visualizations/charts-graphs#ordering-your-series) what you want to be displayed on the left and right axis.
  </Tab>

  <Tab title="Series options">
    <img alt="" />

    In this section of the Visualization editor you can finalize your graph.

    * You can rename the "series" by simply clicking into the field.
    * You can change the chart type by clicking into the dropdown.
    * You can change the colors by clicking into the color box.
    * Finally you can also change the order of the series.

    **Picking Colors**

    You can pick colors with your browser native color selector.

    This might look slightly different for you depending on which browser you use.

    <img alt="Choose any color you want!" />
  </Tab>

  <Tab title="Pie options">
    <img alt="pie options" />

    **Label format**

    * This field allows you to define the [tick format](#xy-axis-tick-and-label-formats) of the data labels in your pie chart.
  </Tab>
</Tabs>

### X/Y-axis Tick and Label formats

<img alt="image" />

Tick formats change how numeric values and axis labels in your graphs are displayed.

Here's how to format them:

| Starting Value | Tick/Label format | Output          | Description                                                                                                                                                         |
| -------------- | ----------------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1256784.3745   | `[blank]`         | 1256784.3745000 | Displays the number 7 decimal precision.                                                                                                                            |
| 1256784.3745   | `0`               | 1256784         | Displays only the integer.                                                                                                                                          |
| 1256784.3745   | `0,0`             | 1,256,784       | Only displays the integer with comma separation.                                                                                                                    |
| 1256784.3745   | `0,0.00`          | 1,256,784.38    | Displays the number with `[x]` decimal precision, where `[x]` is the number of `0` you add after the decimal point.                                                 |
| 1256784.3745   | `0.0a`            | 1.2M            | Displays the number with `[x]` precision and a letter based on the number's `1e[y]` power (eg "m" for million, "b" for billion)                                     |
| 1256784.3745   | `$0.0a`           | \$1.2M          | Adds a "\$" to the number. Works with all formats above though use of the `a` suffix is recommended. Currently the only "\$" is the only supported currency symbol. |


# Counters
Source: https://docs.dune.com/web-app/visualizations/counters

Display a single key metric prominently using counter visualizations.

## Counters

Counters are a great way to provide your audience with immediate "on a glance" stats.

<img alt="&#x22;on a glance&#x22; stats" />

### Configuring your Counter

<img alt="Counter configuration" />

#### Counter options

In this section you can define what kind of data the counter should display:

<Accordion title="Display Title" icon="title">
  * The Title will appear in all instances of this graph prominently at the top.
  * If left blank, the Query name will be the only thing that is left standing.
</Accordion>

<Accordion title="Column Selection" icon="column">
  * In this field, you can define which column the counter should show.
</Accordion>

<Accordion title="Row Selection" icon="row">
  * This field can be used to define which row of the underlying data table you want displayed, e.g., row 1.
  * Usually, this requires you to sort or limit your Query results in order for row 1 to show the wanted results.
</Accordion>

#### Formatting

This section is where you can adjust how your numerical data is displayed.

<Accordion title="Prefix Setting" icon="prefix">
  * This field allows you to define a prefix for your counter value.
  * e.g.: `$`, `€`, `Ξ`, `฿`
</Accordion>

<Accordion title="Suffix Setting" icon="suffix">
  * This field allows you to define a suffix for your counter value.
</Accordion>

<Accordion title="Label Setting" icon="label">
  * This field allows you to define a label for your counter value.
  * The label will appear beneath the counter value as text.
</Accordion>

<Accordion title="Decimal Setting" icon="decimal">
  * In this field, you can choose how many decimals you want displayed for your counter.
</Accordion>

<img alt="label" />


# Tables
Source: https://docs.dune.com/web-app/visualizations/tables

Format and customize table visualizations including column alignment, number formatting, and progress bars.

**Tables are the default Visualization whenever you create and run a Query.**

<img alt="query results table example" />

You can also make more Tables to display your data differently using the <span>New visualization</span> button and drop down menu:

<img alt="new table visualization" />

### Configuring your Table

<img alt="table configuration options" />

#### Table options

**Title**

The Title appears at the top of your Table.

Leaving default value (`Table`) or making this blank makes your Table title the same as your Query's title/name.

Adding any other value to this field will add that value first, followed by your Query Name:

<img alt="table title example" />

Note: the default value for "Query Results" is treated like an added value.

#### "Column `[x]`:" options

You can configure the following options for each column in your Table

<Tabs>
  <Tab title="Title">
    The Title appears at the top of your Table.

    Leaving this blank makes your column title the same as its Dune database name.
  </Tab>

  <Tab title="Align">
    This changes the text alignment for the column data and title.
  </Tab>

  <Tab title="Format">
    Allows you to adjust the numerical format of your data following the [X/Y-axis Tick and Label formats here](/web-app/visualizations/charts-graphs).
  </Tab>

  <Tab title="Hide Column">
    Hides this column from your table.
  </Tab>
</Tabs>

#### Numerical Column options

Columns that return numerical data have these additional options:

<Tabs>
  <Tab title="Type">
    * `Normal` simply displays the column's numerical data.
    * `Progress bar` shows the column's numerical data with a progress bar visual that is "full" for the column's highest value and "nearly empty" for the column's lowest value, with the rest of the data ranging in between:

      <img alt="progress bar example" />
  </Tab>

  <Tab title="Colored Values">
    <img alt="colored values example" />
  </Tab>
</Tabs>