Add Flashloans to NFT Wash Filter

[hildobby]

Brief comments on the purpose of your changes:

For Dune Engine V2

I've checked that:

General checks:

• I tested the query on dune.com after compiling the model with dbt compile (compiled queries are written to the target directory)
• I used "refs" to reference other models in this repo and "sources" to reference raw or decoded tables
• if adding a new model, I added a test
• the filename is unique and ends with .sql
• each sql file is a select statement and has only one view, table or function defined
• column names are lowercase_snake_cased
• if adding a new model, I edited the dbt project YAML file with new directory path for both models and seeds (if applicable)
• if wanting to expose a model in the UI (Dune data explorer), I added a post-hook in the JINJA config to add metadata (blockchains, sector/project, name and contributor Dune usernames)

Pricing checks:

• coin_id represents the ID of the coin on coinpaprika.com
• all the coins are active on coinpaprika.com (please remove inactive ones)

Join logic:

• if joining to base table (i.e. ethereum transactions or traces), I looked to make it an inner join if possible

Incremental logic:

• I used is_incremental & not is_incremental jinja block filters on both base tables and decoded tables
  • where block_time >= date_trunc("day", now() - interval '1 week')
• if joining to base table (i.e. ethereum transactions or traces), I applied join condition where block_time >= date_trunc("day", now() - interval '1 week')
• if joining to prices view, I applied join condition where minute >= date_trunc("day", now() - interval '1 week')

[0xRobin]

@hildobby ✔️ this looks good.

side note:
would you be interested in having these models implemented in a macro?
(1 macro that's then used for all the different chains, so you'd only need to change the logic in 1 place)
Or do you see the logic diverging a bit between different chains? In that case we'd need to keep the implementation chain specific.

[hildobby]

you be interested in having these models implemented in a macro?
(1 macro that's then used for all the different chains, so you'd only need to change the logic in 1 place)
Or do you see the logic diverging a bit between different chains? In that case we'd need to keep the implementation chain specific.

I excluded Solana when making it crosschain since a lot of the fields were missing there for Solana trades and the filter thus didn't work (it was all is_wash_trade=true since buyer and seller were both NULLs and thus equal for example). I'm guessing that decoded Solana data changes things though, once Solana marketplaces have their own spell and necessary fileds are not NULL, the implementation should be the same afaik, but my Solana knowledge is limited. I would maybe keep it as is for now unless you view the change as necessary.

What do you think about keeping current structure and adding is_wash_trade in nft.trades? And have it be NULL for now for non-EVM chains. Imo many would find it practical, and we could also keep nft.wash_trades to keep the other per filter columns there for those who want to dig further (and also not overcrowd nft.trades with too many new columns)