tokens.transfers_from_traces fix duplicates issue in deposit

[max-morrow]

Solving the issue 9122.

The issue due to inconsistency in dune.blockchains & tokens.erc20.

1. The duplicates issue is due to using a null address as a native one in dune.blockchains.
   Some context here

2. tokens.erc20 contains addresses that are not contracts.
   The null address has been added to this table as a synthetic native token.

success run even without the easy dates

cc @jeff-dude

[Copilot]

Pull request overview

This PR fixes a duplicate records issue in tokens.transfers_from_traces for deposit transactions caused by inconsistencies between dune.blockchains and tokens.erc20 tables. The primary issue stems from the null address being used as a native token address in both tables, creating unwanted duplicates when joined.

Key changes:

• Removed prod_exclude tag from hyperevm transfers model
• Added filter condition to exclude cases where contract_address equals to address in deposit transfers

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
tokens_hyperevm_transfers_from_traces.sql	Removed prod_exclude tag to enable production deployment
transfers_from_traces_base_wrapper_deposits_macro.sql	Added deduplication logic to filter out duplicate deposits caused by null address inconsistency

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[cursor]

PR Summary

Exclude wrapper-deposit rows where contract_address equals to to prevent duplicates and remove prod_exclude from hyperevm transfers_from_traces model.

• Transfers from traces (wrapper deposits macro):
  • Add filter contract_address <> "to" while keeping type = 'deposit' to prevent duplicate rows from tokens.erc20 inconsistencies.
• Hyperevm model:
  • Remove prod_exclude tag from tokens_hyperevm_transfers_from_traces.sql to include it in regular runs.

^{Written by Cursor Bugbot for commit 1f0700e. Configure here.}

[jeff-dude]

i hear you on the 0x000.. usage. at this time, that is pretty entrenched in the data and use cases for queries on the app/api/etc so it is difficult to just "switch" to 0xeee... address. this will need to be a bigger org wide discussion. if you wanted to flag that, feel free in the shared slack for support to consider.

as for this change, thank you for quick fix. here is quick validation on ethereum, no results as expected.

with ci as (
    select *
    from test_schema.git_dunesql_094b851_tokens_ethereum_transfers_from_traces_base_wrapper_deposits
)
, prod as (
    select *
    from tokens_ethereum.transfers_from_traces_base
)
, unioned as (
    select * from ci
    union all
    select * from prod
)
select block_date, unique_key, count(1)
from unioned
group by block_date, unique_key
having count(1) > 1

it makes sense that full history ran here, as it's scoped down to just the wrapper models rather than entire lineage.

[jeff-dude]

wait, prior to merge (which will likely be early next week), can you also push a commit to remove this workaround?

[jeff-dude]

canceled CI, as it will now likely fail and we don't need to waste the compute for that.