1. Pending
2. Approved/Rejected*

• Querying Synthetix’s PerpsTracking Event
• Querying USDT’s AddedBlackList Event

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

4. Contact Dune support via Slack (For Enterprise Customers), Telegram (Paid Customers), Discord, or email (support@dune.com) to remove the duplicate namespace

• Check existing decoded contracts before submitting
• Use consistent naming conventions across your team
• Document which contracts are already decoded

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, or email (support@dune.com) to remove the old namespace

• 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

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)

1. Find a transaction that calls the missing function/event
2. Check if it appears in ethereum.traces or ethereum.logs raw tables

-- Check if tx hash exists in traces
SELECT 
    'traces' as table_name,
    COUNT(*) as record_count
FROM ethereum.traces
WHERE tx_hash = 0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef;

-- Check if tx hash exists in logs  
SELECT 
    'logs' as table_name,
    COUNT(*) as record_count
FROM ethereum.logs
WHERE tx_hash = 0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef;

• 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

-- Check if other instances are detected
SELECT DISTINCT contract_address 
FROM namespace.contractname_evt_YourEvent

• Other contracts have 100% identical bytecode
• You enabled “bytecode matching” during submission
• Contracts aren’t variations (even slight differences prevent matching)

1. Query the decoded tables for multiple contract addresses
2. Can use dune.com/agent:

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

• Submit them separately
• Don’t enable bytecode matching
• Manually submit each address

• Submit the main contract with bytecode matching
• Create a view filtering only desired addresses:

CREATE VIEW my_filtered_events AS
SELECT * FROM namespace.contract_evt_Event
WHERE contract_address IN (
    '0xAddress1',
    '0xAddress2'
)

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

• 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

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

• 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

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

• 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 all chains at once
SELECT * FROM namespace.contract_evt_Event
WHERE chain IN ('ethereum', 'polygon', 'arbitrum')

• 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

• 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

Sometimes you need to resubmit a contract because the name is originally submitted wrong, or you need to update the ABI.

• 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

• 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

• Don’t submit multiple versions of the same contract as separate submissions
• Don’t submit implementation contract addresses directly (for proxy patterns)

• Same bytecode (if bytecode matching enabled)
• Same factory deployer (if factory pattern enabled)

1. Identical ABIs across chains
2. Same project namespace and contract name
3. Contracts submitted on multiple chains

• Solidity versions
• Optimizer settings
• Constructor parameters embedded in bytecode

• Different contract address
• New version with different address
• Different contract type in protocol
• Adding missed chains

• Updating ABI for the same contract
• Fixing naming errors
• Request contract deletion
• Submitting for another reason