Create airdrop.claims with 38 airdrops

[hildobby]

Brief comments on the purpose of your changes:

Here I created a new sector airdrop since without standardisation, things are starting to get messy in spellbook. The goal is to have 3 main tables at the end (airdrop.claims, airdrop.eligible, airdrop.total_stats):

• airdrop.claims is what this PR creates, its onchain claims of airdrops
• airdrop.eligible would have the eligible address lists and since the breakdown is different per airdrop, this would only contain the address and total its eligible for with the breakdown still in the sub models.
• airdrop.total_stats would have 1 line per airdrop and consist of total claimable, % claimed, etc

All those depend on their blockchain dependant sub-abstractions (ie airdrop.claims depends on airdrop_ethereum.claims and airdrop_optimism.claims) in this PR. And those depend on the protocol specific tables (ie looksrare_ethereum.airdrop_claims).

This PR creates airdrop.claims with those airdrops included so far:

• Ampleforth (FORTH)
• ApeCoin (APE)
• BendDAO (BEND)
• Blur (BLUR airdrop 1)
• Cow Protocol (COW)
• DappRadar (RADAR)
• dYdX (DYDX)
• ENS (ENS)
• Forta Network (FORT)
• Galxe (GAL)
• Gas DAO (GAS)
• Gitcoin (GTC)
• Hop Protocol (HOP)
• LooksRare (LOOKS)
• 1inch (1INCH)
• Paladin (PAL)
• Paraswap (PSP)
• Ribbon (RBN)
• Safe (SAFE)
• Sudoswap (SUDO)
• Tornado Cash (TORN)
• Uniswap (UNI)
• X2Y2 (X2Y2)
• Optimism (OP airdrop 1)
• Velodrome (VELO)

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

[Hosuke]

Since this is a new sector, maybe @augustog can take a look.

[MSilb7]

do we need to cast any of these as double for dunesql future-proofing? Many had decimal amounts (i.e. 778.79)

[hildobby]

Good call! All of the quantity rows were replaced by (amount_raw, amount_original and amount_usd) to be consistent with other spells, those are respectively cast as decimal(38, 0), double and double as they should be to not cause any issues with DuneSQL

[jeff-dude]

sorry, more merge conflicts to resolve 😅 also -- looks like some models are maybe missing in schema file, hence the error on pre-commit hooks test?

[jeff-dude]

need to resolve some issues on why the ci test is timing out, then get a successful run as expected, then we can proceed 🙏

[jeff-dude]

looks like it timed out on dunesql check, that should be fine. i'll let it run this last time on latest merge and then we should be good

edit: trying again without other PRs at same time

[jeff-dude]

looks like we're finally all good 🤞