Skip to main content
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.
Multichain contract submissions require a paid team plan. See pricing for details.
Multichain tables have the same data freshness and latency as single-chain decoded tables. See data freshness for SLA details.

Prerequisites

Before submitting a multichain contract, ensure the following: 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. 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.

Querying Multichain Tables

Naming Convention

Multichain decoded tables follow the naming pattern:
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.).

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. 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.