Why Dune Cross-Chain Aggregation Misses Data: How to Fix Chain Coverage and Token Mapping

Dune cross-chain aggregation misses data usually for two reasons: either the target chain is not covered by Dune's data, or the token mapping key (token_id) in cross-chain tables is misaligned, treating the same asset on different chains as different things. The fix is to first check the coverage scope, then standardize the mapping.

1. First, Confirm: Does Dune Cover the Chain You're Querying?

Dune's cross-chain view currently covers 100+ blockchains, but coverage depth is not uniform. Some chains have historical data gaps—Sei, for example, once suffered a long-lasting gap of over 70,000 blocks despite its scale.

Step 1: Check if the target chain is in the supported coverage list

• What to do: Consult the "Blockchain Coverage" table in Dune's official data catalog, confirming whether the chain is listed and its data tier (Raw, Decoded, Curated).

• How to do it:

  • Case A (the chain is not in the official table): The answer is a clear "not covered." Cross-chain queries will inherently miss data and cannot be fixed by tuning. You can only analyze within the covered chains.

  • Case B (the chain is in the coverage list but specific historical blocks are missing): Go to Dune's Status Page or Incident History to check recent data issue records for that chain. For instance, Sei had missing blocks multiple times during 2024-2025 due to RPC issues, and Stellar also experienced data quality problems.

• When is this done: You have confirmed the target chain's coverage status and any known data gaps.

Prerequisite: You have a cross-chain query idea and have determined the list of chains to cover.

2. Second Step: Check if Token Mapping "Matches"

Different chains identify the same asset differently: EVM uses contract address, Solana uses Mint Address, Aptos uses Asset Type. Dune's cross-chain tables use the composite key (blockchain, token_id) for unified mapping. A common cause of missing data is using this key incorrectly when aggregating across chains.

Step 2: Ensure JOIN or filter conditions use token_id, not chain-native identifier fields

• What to do: Check your cross-chain query (e.g., querying RWA, stablecoin, or cross-chain bridge tables) to confirm that token filter conditions use the token_id field.

• How to do it: Take the RWA table rwa_multichain.transfers as an example. This table unifies data from EVM, Solana, Aptos, Sui, XRP L, and Stellar into one schema:

  • Wrong approach: WHERE contract_address = '0xA0b...'. contract_address only has values on EVM chains; it is NULL on non-EVM chains, thus filtering out all non-EVM data.

  • Correct approach: JOIN the rwa_multichain.tokens table using (blockchain, token_id) as the key, then filter by token_symbol or token_id. token_id is the standardized cross-chain unique identifier.

• When is this done: Your query output includes data from the multiple chains you expected, not just EVM chains.

Step 3: Check if the transfer_type field on non-EVM chains is causing you to miss data

• What to do: If you are directly using SUM(amount) or filtering transfer_type = 'transfer', verify whether mint/burn events on non-EVM chains are being incorrectly counted or dropped.

• How to do it: In the rwa_multichain.transfers table, the transfer_type field is always NULL on EVM chains and only has values on Solana, Stellar, Sui, XRPL, and Aptos. A frequent mistake is WHERE transfer_type = 'transfer'—this drops all EVM chain data because their transfer_type is NULL, not 'transfer'.

• When is this done: Your query can include transaction data from both EVM and non-EVM chains simultaneously, without losing entire groups of chains due to transfer_type filtering.

3. Third Step: "Missing Data" Caused by Query Performance (Indirect Reason)

Sometimes the data does exist, but the query fails to complete due to performance issues, making the output appear to have missing data. Some Dune tables (e.g., tokens_.balances) are explicitly labeled "currently extremely low performance, the only efficient way to query is using the template" or require mandatory partition filters (blockchain, block_date).

Step 4: Check if your cross-chain query includes the necessary partition filters

• What to do: Ensure that the WHERE clause contains blockchain and block_date (or a block_time range).

• How to do it: Dune's official documentation repeatedly emphasizes on tables like tokens_multichain.transfers: Always include blockchain and block_date in filter conditions to push down query pressure to partitions. Without them, the risk of timeout or truncated results is high, and the "missing data" you see is just an incomplete query result.

• When is this done: Your query executes successfully in Dune and returns complete results, rather than timing out or erroring mid-way.

Risk note: Dune has automatic quality verification for cross-chain queries, but multi-chain views may update with a lag behind single-chain data. If you need extremely up-to-date and sensitive data, consider querying single-chain raw tables first and then UNION ALL—though more cumbersome, the data will be more timely.

After completing the above checks, how to confirm you've fixed the missing data?

Run a query against Dune's official cross-chain tables like tokens_multichain.transfers or rwa_multichain.transfers and verify that the output includes data from both EVM and non-EVM chains (e.g., seeing both Ethereum and Solana records). Then use COUNT(DISTINCT blockchain) to confirm the number of chains covered matches your expectations. If a specific chain was missing before and now its transfer records appear, the fix is successful. For long-term cross-chain monitoring, turn the blockchain and block_date filters into a fixed template to avoid future query timeouts.