📰 2024-01-05: Weekly Prophet!

[andrewhong5297]

This is your weekly summary of 27 PRs merged from 10 wizards. Great job everyone! 🎉
We had 48 added models 🟢 and 83 modified models 🟠 for 7 Sectors.

Sector	🔧 # PRs	🟢 # Added	🟠 # Modified	🧙 # Authors
dex	1	0	1	1
tokens	2	0	2	2
prices	3	0	3	2
oneinch	3	20	37	2
_sector	16	27	34	2
unidex	1	1	0	1
tokenlon	2	0	6	1

SECTOR: dex

toggle to see all model updates

MODEL: dex_aggregator_trades.sql

🟠 Modified by:

🔧 PR: #5040, Added Optimism Unidex Dex
🧙 Author: @ARDev097 on 2024-01-03
📝 Summary: The reference models that were added or removed in the given diff are:
unidex_optimism_trades

SECTOR: tokens

toggle to see all model updates

MODEL: tokens_ethereum_erc20.sql

🟠 Modified by:

🔧 PR: #5083, [EASY] Add missing erc20 tokens
🧙 Author: @harisang on 2024-01-02
📝 Summary: [changes too large] The model tokens_ethereum_erc20.sql was modified.

MODEL: tokens_avalanche_c_erc20.sql

🟠 Modified by:

🔧 PR: #5076, Adding KIMBO and COQ to tokens_avalanche_c_erc20.sql
🧙 Author: @discochuck on 2024-01-02
📝 Summary: The token symbols that were added or removed are: Added: KIMBO, COQ

SECTOR: prices

toggle to see all model updates

MODEL: prices_native_tokens.sql

🟠 Modified by:

🔧 PR: #5051, Fixed ICP name in prices_native_tokens spell
🧙 Author: @cryptokoryo on 2024-01-04
📝 Summary: The token symbols that were added or removed are: ICP

🔧 PR: #5051, Added 10 new L1 and L2 native tokens to prices_native_tokens.sql
🧙 Author: @cryptokoryo on 2024-01-02
📝 Summary: The token symbols that were added or removed are: APT, ICP, KAVA, KUJI, MNT, OSMO, SEI,
SUI,TAO,TIA

MODEL: prices_avalanche_c_tokens.sql

🟠 Modified by:

🔧 PR: #5063, Added FLD to prices_avalanche_c_tokens.sql
🧙 Author: @IAmAGithubSir on 2024-01-02
📝 Summary: The token symbols that were added or removed are: OATH, FLD

SECTOR: oneinch

toggle to see all model updates

MODEL: oneinch_blockchains.sql

🟠 Modified by:

🔧 PR: #5050, add back 1inch: lineage refactoring part 4 (#5050)
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: In this SQL model, a loop is used to iterate over a list of blockchains. The oneinch_blockchain_macro is called for each blockchain. A change was made to add spacing around the 'union all' keyword in the if statement. Some commented out code and a line with dashes were removed at the end of the model.

🔧 PR: #5050, Revert '1inch: lineage refactoring part 4 (#5050)'
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: In this SQL model, the main logic that was added is a section for CI (Continuous Integration) purposes. It includes a commented out select statement with various columns selected from table 't'. The purpose of this section is to retrieve specific information related to blockchains such as blockchain name, chain ID, native token symbol, wrapped native token address, explorer link and the date of first deployment.

🔧 PR: #5050, 1inch: lineage refactoring part 4
🧙 Author: @max-morrow on 2024-01-04
📝 Summary: In this SQL model, a loop is used to iterate over a list of blockchains. The oneinch_blockchain_macro is called for each blockchain. A change was made to add spacing around the 'union all' keyword in the if statement. Some commented out code and a line with dashes were removed at the end of the model.

MODEL: oneinch_exchange_contracts.sql

🟠 Modified by:

🔧 PR: #5050, add back 1inch: lineage refactoring part 4 (#5050)
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: The diff shows that the model has been modified to include two new CTEs: 'evms_creation_traces' and 'evms_contracts'. The 'descriptions' CTE has also been updated. In the main query, the columns related to creation traces have been replaced with new columns for last created date, last creator, and last creation transaction hash. The final result is ordered by project and last created date.

🔧 PR: #5050, Revert '1inch: lineage refactoring part 4 (#5050)'
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: The diff shows that the 'evms_creation_traces' and 'evms_contracts' CTEs were removed. Instead, references to these CTEs were added in the 'descriptions' and 'creations' CTEs respectively. The logic of joining tables, grouping by certain columns, and selecting specific columns remains unchanged. The final result is ordered by project and created_at column.

🔧 PR: #5050, 1inch: lineage refactoring part 4
🧙 Author: @max-morrow on 2024-01-04
📝 Summary: The diff shows that the model has been modified to include two new CTEs: 'evms_creation_traces' and 'evms_contracts'. The 'descriptions' CTE has also been updated. In the main query, the columns related to creation traces have been replaced with new columns for last created date, last creator, and last creation transaction hash. The final result is ordered by project and last created date.

MODEL: oneinch_fusion_accounts.sql

🟢 Added by:

🔧 PR: #5050, add back 1inch: lineage refactoring part 4 (#5050)
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: This SQL model creates a dataset that enables data analysts to retrieve information about blockchain transactions and their associated resolvers. It includes details such as the blockchain, resolver EOA (externally owned account) address, resolver address, and resolver name. This dataset can be used for analysis and reporting purposes related to blockchain transactions involving resolvers.

🔧 PR: #5050, 1inch: lineage refactoring part 4
🧙 Author: @max-morrow on 2024-01-04
📝 Summary: This SQL model creates a dataset that enables data analysts to retrieve information about blockchain transactions related to resolver addresses and their corresponding resolvers. It includes details such as the blockchain, resolver EOA (externally owned account) address, resolver address, and resolver name. This dataset can be used for analysis and reporting purposes in understanding the activity of resolvers in different blockchains.

MODEL: oneinch_fusion_executors.sql

🟢 Added by:

🔧 PR: #5050, add back 1inch: lineage refactoring part 4 (#5050)
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: This SQL model creates a table called 'executors' that combines data from two sources, 'FusionWhitelistRegistryV1_evt_Promotion' and 'FusionWhitelistRegistryV2_evt_Promotion'. It groups the data by resolver address, resolver executor, and chain ID while also calculating the first and last promoted dates. The final output selects specific columns from the 'executors' table and performs a left join with another reference table called 'oneinch_blockchains'. This model enables data analysts to analyze information about executors in different blockchains.

🔧 PR: #5050, Revert '1inch: lineage refactoring part 4 (#5050)'
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: This SQL model creates a dataset that provides information about executors and their promotions in the Ethereum blockchain. It retrieves data from the 'traces' table in the 'ethereum' source, filters it based on certain conditions, and groups it by resolver address, executor, and chain ID. The model then joins this data with another dataset called 'oneinch_fusion_resolvers' to retrieve additional information about resolvers. Finally, it orders the results by resolver name and executor. This model enables data analysts to analyze executor promotions within specific resolvers on different blockchains.

🔧 PR: #5050, 1inch: lineage refactoring part 4
🧙 Author: @max-morrow on 2024-01-04
📝 Summary: This SQL model creates a table called 'executors' that combines data from two sources, 'FusionWhitelistRegistryV1_evt_Promotion' and 'FusionWhitelistRegistryV2_evt_Promotion'. It groups the data by resolver address, resolver executor, and chain ID while also calculating the first and last promoted dates. The final output selects specific columns from the 'executors' table and performs a left join with another reference table called 'oneinch_blockchains'. This model enables data analysts to analyze information about executors in different blockchains.

MODEL: oneinch_fusion_farms.sql

🟠 Modified by:

🔧 PR: #5050, add back 1inch: lineage refactoring part 4 (#5050)
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: The main logic added in this SQL model is a conditional statement that checks if the query is incremental or not. If it's incremental, it adds an additional condition using the incremental_predicate function for filtering based on block_time. Otherwise, it uses the original condition of filtering by block_time >= project_start_date. This logic is applied to three different sections of the model: delegates as registrations, delegates as ownerships, and delegates as farm_created.

🔧 PR: #5050, Revert '1inch: lineage refactoring part 4 (#5050)'
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: The main logic added in this SQL model is the removal of conditional statements that check if the query is incremental or not. Instead, it directly filters the data based on a condition: block_time >= {{ project_start_date }}. This condition is applied to three different sections of the model: registrations, ownerships, and delegates. The removed lines were checking for incremental updates but are no longer necessary.

🔧 PR: #5050, 1inch: lineage refactoring part 4
🧙 Author: @max-morrow on 2024-01-04
📝 Summary: The main logic added in this SQL model is a conditional statement that checks if the query is incremental or not. If it's incremental, it adds an additional condition using the incremental_predicate function for filtering based on block_time. Otherwise, it uses the original condition of filtering by block_time >= {{ project_start_date }}. This logic is applied to multiple sections of the model where there are conditions involving block_time.

MODEL: oneinch_fusion_resolvers.sql

🟠 Modified by:

🔧 PR: #5050, add back 1inch: lineage refactoring part 4 (#5050)
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: The main logic added in this SQL model is the creation of a table called 'fusion_resolvers' with a unique key on the 'address' column. The previous file format and unique key on columns 'address' and 'last_changed_at' were removed. Additionally, there is new logic to retrieve data from different sources and create a derived table called 'registrations'. Finally, there is an output query that selects columns from the derived table.

🔧 PR: #5050, Revert '1inch: lineage refactoring part 4 (#5050)'
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: In this SQL model, the file format of the table is changed to 'delta'. The unique key is modified to include both 'address' and 'last_changed_at' columns. A new variable called 'project_start_date' is set with a value of 'timestamp '2022-12-25''. The logic for retrieving data from the source tables has been updated using different conditions and transformations. Finally, in the output section, there are changes made to how the address column is displayed along with some minor modifications in column names.

🔧 PR: #5050, 1inch: lineage refactoring part 4
🧙 Author: @max-morrow on 2024-01-04
📝 Summary: The main logic added in this SQL model is the creation of a table called 'fusion_resolvers' with a unique key on the 'address' column. The previous file format and unique key on columns 'address' and 'last_changed_at' were removed. Additionally, there is a new query that creates a table called 'registrations', which selects data from different sources and calculates the maximum status and last changed date for each address. Finally, there is an output query that selects columns from the registrations table along with some additional transformations.

MODEL: oneinch_ar.sql

🟠 Modified by:

🔧 PR: #5050, add back 1inch: lineage refactoring part 4 (#5050)
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: The added logic in this SQL model is a loop that iterates over a list of blockchains and selects specific columns from each blockchain's table. The selected columns include information about the blockchain, block number, transaction details, call details, token amounts, and other related fields. The result of each select statement is then combined using union all to create a single output table.

🔧 PR: #5050, Revert '1inch: lineage refactoring part 4 (#5050)'
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: The main logic added in this SQL model is a loop that iterates over a list of blockchains. For each blockchain, it selects specific columns from the table oneinch_{blockchain}_ar. Some columns are renamed using aliases. The results for each blockchain are combined using union all to create a single result set.

🔧 PR: #5050, 1inch: lineage refactoring part 4
🧙 Author: @max-morrow on 2024-01-04
📝 Summary: The added logic in this SQL model is a loop that iterates over a list of blockchains. For each blockchain, it selects multiple columns from the table oneinch_{blockchain}_ar. The selected columns include information about block number, transaction details, call details, token amounts, and other related data. The results from all the iterations are combined using union all to create a single result set.

MODEL: oneinch_ar_trades.sql

🟠 Modified by:

🔧 PR: #5050, add back 1inch: lineage refactoring part 4 (#5050)
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: The main logic added in this SQL model is the calculation of token amounts and USD values for 1inch trades. It joins multiple tables to get information about tokens, prices, and calls. The 'trades' CTE calculates the token amounts bought and sold, as well as their corresponding USD values. The final select statement retrieves relevant columns from the 'trades' CTE and filters for trades with a specific protocol version ('AR') from a table called 'oneinch_swaps'.

🔧 PR: #5050, Revert '1inch: lineage refactoring part 4 (#5050)'
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: The main logic added in this SQL model is to calculate the trades made on the 1inch protocol. It retrieves data from various tables and joins them together to get information about token pairs, amounts bought and sold, addresses of tokens, and user details. The calculated amount in USD is also included. The removed logic includes a filter for a specific protocol ('AR') which is no longer needed.

🔧 PR: #5050, 1inch: lineage refactoring part 4
🧙 Author: @max-morrow on 2024-01-04
📝 Summary: The main logic added in this SQL model is the calculation of token amounts and USD values for 1inch trades. It joins multiple tables to get information about tokens, prices, and calls. The 'trades' CTE calculates the token amounts bought and sold, as well as their corresponding USD values. The final select statement retrieves relevant columns from the 'trades' CTE and filters for trades with a specific protocol version ('AR') from a table called 'oneinch_swaps'.

MODEL: oneinch_call_transfers.sql

🟠 Modified by:

🔧 PR: #5050, add back 1inch: lineage refactoring part 4 (#5050)
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: In this SQL model, the unique key for the 'call_transfers' view is defined as a combination of four columns: 'blockchain', 'tx_hash', 'call_trace_address', and 'transfer_trace_address'.

🔧 PR: #5050, Revert '1inch: lineage refactoring part 4 (#5050)'
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: A new SQL view called 'call_transfers' was added. It has a unique key consisting of four columns: 'blockchain', 'tx_hash', 'call_trace_address', and 'transfer_trace_address'.

🔧 PR: #5050, 1inch: lineage refactoring part 4
🧙 Author: @max-morrow on 2024-01-04
📝 Summary: In this SQL model, the unique key for the 'call_transfers' view is defined as a combination of four columns: 'blockchain', 'tx_hash', 'call_trace_address', and 'transfer_trace_address'.

MODEL: oneinch_contract_addresses.sql

🟢 Added by:

🔧 PR: #5050, Revert '1inch: lineage refactoring part 4 (#5050)'
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: [changes too large] The model oneinch_contract_addresses.sql was added.

🟠 Modified by:

🔧 PR: #5050, add back 1inch: lineage refactoring part 4 (#5050)
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: [changes too large] The model oneinch_contract_addresses.sql was removed.

🔧 PR: #5050, 1inch: lineage refactoring part 4
🧙 Author: @max-morrow on 2024-01-04
📝 Summary: [changes too large] The model oneinch_contract_addresses.sql was removed.

MODEL: oneinch_lop.sql

🟠 Modified by:

🔧 PR: #5050, add back 1inch: lineage refactoring part 4 (#5050)
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: The added logic in this SQL model is a loop that iterates over a list of blockchains and selects specific columns from each table. The tables are referenced using the ref() function with the blockchain name concatenated to it. The result is a union of all selected rows from each table, with an additional check to exclude the 'union all' keyword after the last iteration of the loop.

🔧 PR: #5050, Revert '1inch: lineage refactoring part 4 (#5050)'
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: The main logic added in this SQL model is a loop that iterates over a list of blockchains. For each blockchain, it selects multiple columns from the table oneinch_{blockchain}_lop. The selected columns include information about the blockchain, block number, transaction details, call details, maker and receiver information, asset details, order hash and more. The results from all iterations are combined using union all to create a single result set.

🔧 PR: #5050, 1inch: lineage refactoring part 4
🧙 Author: @max-morrow on 2024-01-04
📝 Summary: The added logic in this SQL model is a loop that iterates over a list of blockchains. For each blockchain, it selects multiple columns from the table oneinch_{blockchain}_lop. The result of each select statement is then combined using the union all operator. The function oneinch_exposed_blockchains_list() returns the list of blockchains to iterate over.

MODEL: oneinch_lop_own_trades.sql

🟠 Modified by:

🔧 PR: #5050, add back 1inch: lineage refactoring part 4 (#5050)
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: The main logic added in this SQL model is to select specific columns from the 'oneinch_swaps' table and apply some transformations. The selected columns include blockchain, project, version, block_date, block_month, block_time, token_bought_symbol (coalesced), token_sold_symbol (coalesced), token_pair (an array joined and sorted), token_bought_amount (calculated by dividing dst_token_amount by pow(10,dst_token_decimals)), token_sold_amount (calculated by dividing src_token_amount by pow(10,dst_token_decimals)), amount_usd calculated based on either src or dst amounts depending on which one is available. Other columns like taker/maker addresses are also included along with row_number() over partitioned by tx_hash ordered by call_trace_address. Finally there are some filters applied to the data before selecting it such as protocol = 'LOP', not fusion and not second_side.

🔧 PR: #5050, Revert '1inch: lineage refactoring part 4 (#5050)'
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: The main logic added in this SQL model is the creation of several CTEs (Common Table Expressions) to join and manipulate data from different sources. These CTEs include 'orders' which selects specific columns from the 'oneinch_lop' table, filters out certain rows based on conditions, and performs a left join with another table called 'oneinch_fusion_settlements'. Other CTEs like 'prices_src', 'prices_dst', 'tokens_src', and 'tokens_dst' select columns from different tables or sources. Finally, the query selects all columns from a CTE called 'additions'.

🔧 PR: #5050, 1inch: lineage refactoring part 4
🧙 Author: @max-morrow on 2024-01-04
📝 Summary: The main logic added in this SQL model is to select specific columns from the 'oneinch_swaps' table and apply some transformations. The selected columns include blockchain, project, version, block_date, block_month, block_time, token_bought_symbol (coalesced), token_sold_symbol (coalesced), token_pair (an array joined and sorted), token_bought_amount (calculated by dividing dst_token_amount by pow(10,dst_token_decimals)), token_sold_amount (calculated by dividing src_token_amount by pow(10,dst_token_decimals)), amount_usd calculated based on conditions using src_price and dst_price. Other columns like taker/maker addresses are also included along with row_number() over partitioned by tx_hash ordered call_trace_address.

MODEL: oneinch_protocols.sql

🟢 Added by:

🔧 PR: #5050, Revert '1inch: lineage refactoring part 4 (#5050)'
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: [changes too large] The model oneinch_protocols.sql was added.

🟠 Modified by:

🔧 PR: #5050, add back 1inch: lineage refactoring part 4 (#5050)
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: [changes too large] The model oneinch_protocols.sql was removed.

🔧 PR: #5050, 1inch: lineage refactoring part 4
🧙 Author: @max-morrow on 2024-01-04
📝 Summary: [changes too large] The model oneinch_protocols.sql was removed.

MODEL: oneinch_schema.yml

🟠 Modified by:

🔧 PR: #5050, add back 1inch: lineage refactoring part 4 (#5050)
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: [changes too large] The model oneinch_schema.yml was modified.

🔧 PR: #5050, Revert '1inch: lineage refactoring part 4 (#5050)'
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: [changes too large] The model oneinch_schema.yml was modified.

🔧 PR: #5050, 1inch: lineage refactoring part 4
🧙 Author: @max-morrow on 2024-01-04
📝 Summary: [changes too large] The model oneinch_schema.yml was modified.

MODEL: oneinch_swaps.sql

🟠 Modified by:

🔧 PR: #5050, add back 1inch: lineage refactoring part 4 (#5050)
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: [changes too large] The model oneinch_swaps.sql was modified.

🔧 PR: #5050, Revert '1inch: lineage refactoring part 4 (#5050)'
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: [changes too large] The model oneinch_swaps.sql was modified.

🔧 PR: #5050, 1inch: lineage refactoring part 4
🧙 Author: @max-morrow on 2024-01-04
📝 Summary: [changes too large] The model oneinch_swaps.sql was modified.

MODEL: oneinch_arbitrum_calls_transfers.sql

🟢 Added by:

🔧 PR: #5098, Revert '1inch: lineage refactoring part 4 (#5050)'
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: This SQL model creates and enables a macro called 'oneinch_calls_transfers_macro'. It takes in parameters for the blockchain (set as 'arbitrum') and the project start date (set as '2021-09-14'). The macro likely performs calculations or transformations related to oneinch calls transfers data on the specified blockchain starting from the given project start date.

MODEL: oneinch_avalanche_c_calls_transfers.sql

🟢 Added by:

🔧 PR: #5098, Revert '1inch: lineage refactoring part 4 (#5050)'
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: This SQL model creates and enables the use of a macro called 'oneinch_calls_transfers_macro'. It takes in parameters for the blockchain and project start date, allowing data analysts to retrieve information related to oneinch calls transfers.

MODEL: oneinch_base_calls_transfers.sql

🟢 Added by:

🔧 PR: #5098, Revert '1inch: lineage refactoring part 4 (#5050)'
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: This SQL model creates and enables the execution of a macro called 'oneinch_calls_transfers_macro'. The macro takes in parameters for the blockchain and project start date, allowing data analysts to retrieve information related to oneinch calls transfers.

MODEL: oneinch_bnb_calls_transfers.sql

🟢 Added by:

🔧 PR: #5098, Revert '1inch: lineage refactoring part 4 (#5050)'
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: This SQL model creates and enables the execution of a macro called 'oneinch_calls_transfers_macro'. It takes two parameters, 'blockchain' and 'project_start_date_str', which are used to filter data. The purpose of this macro is not specified in the given code.

MODEL: oneinch_ethereum_calls_transfers.sql

🟢 Added by:

🔧 PR: #5098, Revert '1inch: lineage refactoring part 4 (#5050)'
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: This SQL model creates and enables a macro called 'oneinch_calls_transfers_macro'. It takes in parameters for the blockchain (set as 'ethereum') and the project start date (set as '2019-06-03'). The macro likely performs some calculations or transformations related to oneinch calls transfers data.

MODEL: oneinch_fantom_calls_transfers.sql

🟢 Added by:

🔧 PR: #5098, Revert '1inch: lineage refactoring part 4 (#5050)'
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: This SQL model creates and enables a macro called 'oneinch_calls_transfers_macro'. It takes in parameters for the blockchain (set as 'fantom') and the project start date (set as '2021-12-24'). The macro likely performs calculations or transformations related to oneinch calls transfers on the specified blockchain starting from the given project start date.

MODEL: oneinch_gnosis_calls_transfers.sql

🟢 Added by:

🔧 PR: #5098, Revert '1inch: lineage refactoring part 4 (#5050)'
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: This SQL model creates and enables a macro called 'oneinch_calls_transfers_macro'. It takes in parameters for the blockchain (set as 'gnosis') and the project start date (set as '2022-01-14'). The macro likely performs calculations or transformations related to oneinch calls transfers data.

MODEL: oneinch_calls_transfers_amounts.sql

🟢 Added by:

🔧 PR: #5098, Revert '1inch: lineage refactoring part 4 (#5050)'
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: This SQL model creates a union of data from multiple blockchains, including Arbitrum, Avalanche C-Chain, BNB, Ethereum, Fantom, Gnosis, Optimism,Polygon and Zksync. It selects various columns related to blockchain transactions such as block time,tansaction hash,sender and receiver addresses,and success status.It also includes information about calls made within the transaction like call trace address,called function selector,and call output.The model enables data analysts to analyze and compare transactional data across different blockchains.

MODEL: oneinch_fusion_settlements.sql

🟢 Added by:

🔧 PR: #5098, Revert '1inch: lineage refactoring part 4 (#5050)'
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: This SQL model creates a table called 'settlements' with columns for contract_address and blockchain. It populates the table with values for different contract addresses and their corresponding blockchains, such as Ethereum, Binance Smart Chain, Polygon, Arbitrum, Avalanche C-Chain, Optimism, Fantom Opera Chain Gnosis Safe Multisig Wallets. This model enables data analysts to query and analyze settlement information based on contract addresses and blockchains.

MODEL: oneinch_methods.sql

🟢 Added by:

🔧 PR: #5098, Revert '1inch: lineage refactoring part 4 (#5050)'
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: This SQL model creates a query that retrieves information about contracts and methods. It joins the 'oneinch_exchange_contracts' table with the 'methods' CTE to get details such as contract address, contract ID, contract name, blockchain, creator, method selector and protocol. It also includes the signature of each method if available. The results are ordered by the creation date of the contracts and then by method name. This model enables data analysts to analyze and understand various methods used in different contracts on a blockchain platform.

MODEL: oneinch_optimism_calls_transfers.sql

🟢 Added by:

🔧 PR: #5098, Revert '1inch: lineage refactoring part 4 (#5050)'
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: This SQL model creates and enables the use of a macro called 'oneinch_calls_transfers_macro'. It takes in parameters for the blockchain (set as 'optimism') and project start date (set as '2021-11-13'). The macro likely performs calculations or transformations related to oneinch calls transfers data.

MODEL: oneinch_polygon_calls_transfers.sql

🟢 Added by:

🔧 PR: #5098, Revert '1inch: lineage refactoring part 4 (#5050)'
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: This SQL model creates and enables the use of a macro called 'oneinch_calls_transfers_macro'. It takes in parameters for the blockchain (set as 'polygon') and project start date (set as '2021-04-14'). The macro likely performs calculations or transformations related to oneinch calls transfers data on the specified blockchain starting from the given project start date.

MODEL: oneinch_zksync_calls_transfers.sql

🟢 Added by:

🔧 PR: #5098, Revert '1inch: lineage refactoring part 4 (#5050)'
🧙 Author: @jeff-dude on 2024-01-04
📝 Summary: This SQL model creates and enables data analysts to use the 'oneinch_calls_transfers_macro' function. This function takes in parameters for the blockchain (set as 'zksync') and project start date (set as '2023-04-12'). It likely retrieves data related to transfers made through the OneInch protocol on the specified blockchain, starting from the given project start date.

SECTOR: _sector

toggle to see all model updates

MODEL: contracts_celo_base_iterated_creators.sql

🟢 Added by:

🔧 PR: #5069, Add Celo to contracts
🧙 Author: @tomfutago on 2024-01-04
📝 Summary: This SQL model creates a new table called 'contracts_base_iterated_creators' that is dependent on the 'contracts_deterministic_contract_creators' table. It enables data analysts to analyze and query contract creators in the Celo blockchain.

MODEL: contracts_celo_base_starting_level.sql

🟢 Added by:

🔧 PR: #5069, Add Celo to contracts
🧙 Author: @tomfutago on 2024-01-04
📝 Summary: This SQL model creates a table called 'contracts_base_starting_level' that is specific to the Celo blockchain. It enables data analysts to analyze and track the starting level of contracts on the Celo blockchain.

MODEL: contracts_celo_contract_mapping.sql

🟢 Added by:

🔧 PR: #5069, Add Celo to contracts
🧙 Author: @tomfutago on 2024-01-04
📝 Summary: This SQL model creates a table called 'contracts_contract_mapping' that enables data analysts to map contracts to the Celo blockchain.

MODEL: contracts_celo_find_self_destruct_contracts.sql

🟢 Added by:

🔧 PR: #5069, Add Celo to contracts
🧙 Author: @tomfutago on 2024-01-04
📝 Summary: This SQL model creates a query called 'find_self_destruct_contracts' that enables data analysts to search for self-destruct contracts on the Celo blockchain.

MODEL: dex_arbitrum_base_trades.sql

🟠 Modified by:

🔧 PR: #5057, Add clipper to dex.trades_beta
🧙 Author: @tomfutago on 2024-01-03
📝 Summary: In this diff, a reference to the model 'clipper_arbitrum_base_trades' was added. This reference is included in a list of other models that are being referenced.

🔧 PR: #5057, Add dodo to dex.trades_beta
🧙 Author: @tomfutago on 2024-01-02
📝 Summary: In the given diff of the dbt SQL model, a reference to 'dodo_arbitrum_base_trades' was added.

🔧 PR: #5057, Add gmx to dex.trades_beta
🧙 Author: @tomfutago on 2024-01-02
📝 Summary: In the given diff of the dbt SQL model, a reference to 'gmx_arbitrum_base_trades' was added. This means that the model now includes a reference to this specific table in addition to other existing references.

🔧 PR: #5057, Add integral to dex.trades_beta
🧙 Author: @tomfutago on 2024-01-02
📝 Summary: The model added a reference to 'integral_arbitrum_base_trades' in addition to the existing references to 'pancakeswap_v2_arbitrum_base_trades', 'pancakeswap_v3_arbitrum_base_trades', and 'balancer_v2_arbitrum_base_trades'.

MODEL: dex_ethereum_base_trades.sql

🟠 Modified by:

🔧 PR: #5074, Add clipper to dex.trades_beta
🧙 Author: @tomfutago on 2024-01-03
📝 Summary: In this diff, a reference to the model 'clipper_ethereum_base_trades' was added.

🔧 PR: #5074, Add mstable to dex.trades_beta
🧙 Author: @tomfutago on 2024-01-03
📝 Summary: In this diff, a reference to the model 'mstable_ethereum_base_trades' was added. This reference is included in a list of other models that are being referenced.

🔧 PR: #5074, Add swapr to dex.trades_beta
🧙 Author: @tomfutago on 2024-01-02
📝 Summary: In this diff, a reference to the model 'swapr_ethereum_base_trades' was added.

🔧 PR: #5074, Add mauve to dex.trades_beta
🧙 Author: @tomfutago on 2024-01-02
📝 Summary: In the given diff of the dbt SQL model, a reference to a table named 'mauve_ethereum_base_trades' was added. This reference is included along with other existing references to different tables related to Ethereum base trades.

🔧 PR: #5074, Add dfx to dex.trades_beta
🧙 Author: @tomfutago on 2024-01-02
📝 Summary: The model added a reference to 'dfx_ethereum_base_trades'.

🔧 PR: #5074, Add dodo to dex.trades_beta
🧙 Author: @tomfutago on 2024-01-02
📝 Summary: In this diff, a reference to the 'dodo_ethereum_base_trades' table was added to the list of tables being referenced in the SQL model.

🔧 PR: #5074, Add integral to dex.trades_beta
🧙 Author: @tomfutago on 2024-01-02
📝 Summary: The line ref('integral_ethereum_base_trades') was added to the SQL model.

🔧 PR: #5074, Add maverick to dex.trades_beta
🧙 Author: @tomfutago on 2024-01-02
📝 Summary: The model added a reference to 'maverick_ethereum_base_trades' in addition to the existing references.

MODEL: dex_optimism_base_trades.sql

🟠 Modified by:

🔧 PR: #5049, Add clipper to dex.trades_beta
🧙 Author: @tomfutago on 2024-01-03
📝 Summary: The model added a reference to 'clipper_optimism_base_trades' in addition to the existing references to 'balancer_v2_optimism_base_trades', 'wardenswap_optimism_base_trades', and 'dodo_optimism_base_trades'.

🔧 PR: #5049, Add dodo to dex.trades_beta
🧙 Author: @tomfutago on 2024-01-02
📝 Summary: The model added a reference to 'dodo_optimism_base_trades' in addition to the existing references to 'zipswap_optimism_base_trades', 'balancer_v2_optimism_base_trades', and 'wardenswap_optimism_base_trades'.

MODEL: dex_polygon_base_trades.sql

🟠 Modified by:

🔧 PR: #5049, Add clipper to dex.trades_beta
🧙 Author: @tomfutago on 2024-01-03
📝 Summary: The model added a reference to 'clipper_polygon_base_trades' in addition to the existing references to 'balancer_v2_polygon_base_trades', 'fraxswap_polygon_base_trades', and 'dodo_polygon_base_trades'.

🔧 PR: #5049, Add dodo to dex.trades_beta
🧙 Author: @tomfutago on 2024-01-02
📝 Summary: The model added a reference to 'dodo_polygon_base_trades' in addition to the existing references to 'quickswap_v3_polygon_base_trades', 'balancer_v2_polygon_base_trades', and 'fraxswap_polygon_base_trades'.

MODEL: mstable_ethereum_base_trades.sql

🟢 Added by:

🔧 PR: #5075, Add mstable to dex.trades_beta
🧙 Author: @tomfutago on 2024-01-03
📝 Summary: This SQL model creates a table that combines data from two different sources ('masset' and 'feederpool') related to swapping tokens on the Ethereum blockchain. It includes information such as block number, block time, token amounts bought and sold, addresses of the tokens involved in the swap, participants (taker and maker), project contract address, transaction hash, and event index. This model enables data analysts to analyze token swaps within the mStable project on Ethereum.

MODEL: nft_old_base_trades.sql

🟠 Modified by:

🔧 PR: #5036, polygon NFT trades refactor
🧙 Author: @0xRobin on 2024-01-03
📝 Summary: In this SQL model, several marketplace models are being refactored. The aavegotchi_polygon_events and fractal_polygon_events models were removed from the list, while the element_bnb_events, element_avalanche_c_events, liquidifty_bnb_events, etc. models were added to the list of NFT models. Some other marketplace models like 'rarible_polygon_event' and 'decentraland_polygon_event' were also removed from the list.

MODEL: nft_polygon_base_trades.sql

🟠 Modified by:

🔧 PR: #5036, polygon NFT trades refactor
🧙 Author: @0xRobin on 2024-01-03
📝 Summary: In this SQL model, several references to different base trades models were added. The aavegotchi_polygon_base_trades, decentraland_polygon_base_trades, element_polygon_base_trades, fractal_polygon_base_trades, rarible_polygon_base_trades,tofu_polygon_base_trades and magiceden_polygondexbase_trades models were all included in the list of NFT models. Additionally, the columns for block_date and block_month were added to the SELECT statement.

MODEL: aavegotchi_polygon_base_trades.sql

🟢 Added by:

🔧 PR: #5036, polygon NFT trades refactor
🧙 Author: @0xRobin on 2024-01-03
📝 Summary: This SQL model creates a table called 'base_trades' that combines data from two different sources ('aavegotchi_diamond_evt_ERC721ExecutedListing' and 'aavegotchi_diamond_evt_ERC1155ExecutedListing') to track trades of non-fungible tokens (NFTs) on the Polygon blockchain. The table includes information such as trade category, block time, block number, transaction hash, buyer/seller addresses, NFT contract address and token ID, price in GHST currency (Polygon's native token), and various other details related to the trade. This model enables data analysts to analyze trading activity for NFTs on Polygon's Aavegotchi project.

MODEL: aurem_polygon_base_trades.sql

🟠 Modified by:

🔧 PR: #5036, polygon NFT trades refactor
🧙 Author: @0xRobin on 2024-01-03
📝 Summary: In this SQL model, the main logic that was added includes:

• The use of incremental predicates for filtering data based on a specific time range.
• Additional columns such as block_date and block_month derived from the block_time column.
• Joining with another table called 'payment_detail' using certain conditions.
• A subquery named 'base_trades' that selects various columns from different tables and performs joins.

MODEL: decentraland_polygon_base_trades.sql

🟢 Added by:

🔧 PR: #5036, polygon NFT trades refactor
🧙 Author: @0xRobin on 2024-01-03
📝 Summary: This SQL model creates a table called 'base_trades' that contains enriched data about successful orders in the Decentraland marketplace on the Polygon blockchain. It includes information such as block time, block number, price, buyer and seller details, token ID, contract addresses, trade type (secondary), transaction hash, platform fee amount and more. This model enables data analysts to analyze and gain insights into trading activities in the Decentraland marketplace on Polygon.

MODEL: dew_polygon_base_trades.sql

🟠 Modified by:

🔧 PR: #5036, polygon NFT trades refactor
🧙 Author: @0xRobin on 2024-01-03
📝 Summary: In this SQL model, the following changes were made:

MODEL: element_polygon_base_trades.sql

🟢 Added by:

🔧 PR: #5036, polygon NFT trades refactor
🧙 Author: @0xRobin on 2024-01-03
📝 Summary: This SQL model creates a table called 'base_trades' that combines data from different sources related to trades of NFTs on the Polygon blockchain. It includes information such as the blockchain, project, version, block time, trade type (sell or buy), amount of NFTs traded, trade category (sell or buy), seller and buyer addresses, price in raw format and currency contract address. This model enables data analysts to analyze and gain insights into NFT trading activities on the Polygon blockchain.

MODEL: fractal_polygon_base_trades.sql

🟢 Added by:

🔧 PR: #5036, polygon NFT trades refactor
🧙 Author: @0xRobin on 2024-01-03
📝 Summary: This SQL model creates a view called 'base_trades' that combines data from the 'Marketplace_evt_NewSale' and 'listing_detail' tables. It includes information about NFT sales on the Polygon blockchain, such as trade category, trade type, block time and date, transaction hash, buyer and seller addresses, NFT contract address and token ID. It also calculates price-related fields like raw price amount and platform fee amount. Additionally, it adds transaction data using a helper function until tx_from and tx_to are available in the base event tables.

MODEL: magiceden_polygon_base_trades.sql

🟠 Modified by:

🔧 PR: #5036, polygon NFT trades refactor
🧙 Author: @0xRobin on 2024-01-03
📝 Summary: In this SQL model, several changes were made. 1. The column names erc721TokenId and uint256 '1' were renamed to nft_token_id and nft_amount, respectively.
2. The column name erc1155TokenId was renamed to nft_token_id.
3. A new column named 'project_version' with the value 'v1' was added.
4. Several columns related to trade details such as amount, currency symbol, trade type, number of items, etc., were removed or modified.
5. Columns related to fees like platform fee amount and royalty fee amount were modified. Additionally:

• Some join conditions involving token IDs (token_id) in the tables erc721_fees and erc1155_fees have been changed to use the new token ID (nft_token_id) instead.
• A temporary table called 'base_trades' is created using a CTE (Common Table Expression) that selects specific columns from another table called 'trades'.

MODEL: rarible_polygon_base_trades.sql

🟠 Modified by:

🔧 PR: #5036, polygon NFT trades refactor
🧙 Author: @0xRobin on 2024-01-03
📝 Summary: The main logic added in this SQL model is the transformation of trade data from different sources into a unified format. The model includes multiple CTEs that extract and transform various fields such as trade type, buyer, seller, NFT contract address, token ID, NFT amount/number of items, token standard (ERC721 or ERC1155), currency contract address (MATIC or ERC20), and price. These fields are then used to create a final table called 'base_trades' which contains standardized trade information for further analysis.

MODEL: tofu_polygon_base_trades.sql

🟠 Modified by:

🔧 PR: #5036, polygon NFT trades refactor
🧙 Author: @0xRobin on 2024-01-03
📝 Summary: The main logic that was added in this SQL model is the creation of a new table called 'tofu_v1_base_trades'. This table is specific to the Polygon blockchain and includes data from different sources such as 'MarketNG_call_run' and 'MarketNG_evt_EvInventoryUpdate'. The previous source called 'raw_transactions' has been removed. Other parameters like project start date, native ERC20 replacement, and native symbol replacement have also been specified.

MODEL: swapr_ethereum_base_trades.sql

🟢 Added by:

🔧 PR: #5086, Add swapr to dex.trades_beta
🧙 Author: @tomfutago on 2024-01-02
📝 Summary: This dbt SQL model creates a table called 'uniswap_compatible_v2_trades' that enables data analysts to analyze and query trade events from the Swapr project on the Ethereum blockchain. It sources data from two tables: 'Pair_evt_Swap' and 'Factory_evt_PairCreated'.

MODEL: mauve_ethereum_base_trades.sql

🟢 Added by:

🔧 PR: #5073, Add mauve to dex.trades_beta
🧙 Author: @tomfutago on 2024-01-02
📝 Summary: This dbt SQL model creates a table called 'uniswap_compatible_v3_trades' that enables data analysts to analyze and query trade events from the Uniswap decentralized exchange on the Ethereum blockchain. It uses two sources, 'MauvePool_evt_Swap' and 'MauveFactory_evt_PoolCreated', to gather relevant data for analysis.

MODEL: dfx_ethereum_base_trades.sql

🟢 Added by:

🔧 PR: #5044, Add dfx to dex.trades_beta
🧙 Author: @tomfutago on 2024-01-02
📝 Summary: This SQL model creates a table that extracts data from the 'Curve_evt_Trade' table in the 'dfx_finance_ethereum' source. It selects specific columns and renames them accordingly. The model then generates a new table with additional columns such as blockchain, project, version, block_month, block_date, and others. This enables data analysts to analyze trade events on the Ethereum blockchain using DFX project data at different levels of granularity (month/day).

MODEL: dex_base_base_trades.sql

🟠 Modified by:

🔧 PR: #5074, Add dodo to dex.trades_beta
🧙 Author: @tomfutago on 2024-01-02
📝 Summary: In this diff, a reference to the 'dodo_base_base_trades' table was added to the list of tables being referenced in the SQL model.

🔧 PR: #5074, Add maverick to dex.trades_beta
🧙 Author: @tomfutago on 2024-01-02
📝 Summary: In this diff, a reference to the model 'maverick_base_base_trades' was added. This reference is included in a list of other models ('pancakeswap_v2_base_base_trades', 'pancakeswap_v3_base_base_trades', and 'balancer_v2_base_base_trades') within curly braces. The rest of the code remains unchanged.

MODEL: dex_bnb_base_trades.sql

🟠 Modified by:

🔧 PR: #5077, Add dodo to dex.trades_beta
🧙 Author: @tomfutago on 2024-01-02
📝 Summary: The model added a reference to the table 'dodo_bnb_base_trades'.

🔧 PR: #5077, Add iziswap to dex.trades_beta
🧙 Author: @tomfutago on 2024-01-02
📝 Summary: The model added a reference to 'iziswap_bnb_base_trades' in the list of referenced tables.

🔧 PR: #5077, Add maverick to dex.trades_beta
🧙 Author: @tomfutago on 2024-01-02
📝 Summary: In this diff, a reference to the model 'maverick_bnb_base_trades' was added.

🔧 PR: #5077, Add nomiswap to dex.trades_beta
🧙 Author: @tomfutago on 2024-01-02
📝 Summary: In this diff, a reference to the model 'nomiswap_bnb_base_trades' was added. This reference is included in a list of other models ('babyswap_bnb_base_trades', 'mdex_bnb_base_trades', and 'wombat_bnb_base_trades') within the curly braces. The WITH statement remains unchanged.

MODEL: dex_fantom_base_trades.sql

🟠 Modified by:

🔧 PR: #5081, Add equalizer to dex.trades_beta
🧙 Author: @tomfutago on 2024-01-02
📝 Summary: The model added a reference to 'equalizer_fantom_base_trades' in addition to the existing references to 'spiritswap_fantom_base_trades', 'spookyswap_fantom_base_trades', and 'wigoswap_fantom_base_trades'.

🔧 PR: #5081, Add spartacus_exchange to dex.trades_beta
🧙 Author: @tomfutago on 2024-01-02
📝 Summary: The model added a reference to 'spartacus_exchange_fantom_base_trades' in addition to the existing references to 'spiritswap_fantom_base_trades', 'spookyswap_fantom_base_trades', and 'wigoswap_fantom_base_trades'.

MODEL: equalizer_fantom_base_trades.sql

🟢 Added by:

🔧 PR: #5052, Add equalizer to dex.trades_beta
🧙 Author: @tomfutago on 2024-01-02
📝 Summary: This SQL model creates a table called 'uniswap_compatible_v2_trades' that enables data analysts to analyze trades on the Fantom blockchain for the Equalizer project. It sources data from two events, 'Pair_evt_Swap' and 'Factory_evt_PairCreated', from the 'equalizer_exchange_fantom' source.

MODEL: dex_avalanche_c_base_trades.sql

🟠 Modified by:

🔧 PR: #5056, Add glacier to dex.trades_beta
🧙 Author: @tomfutago on 2024-01-02
📝 Summary: In the given SQL model, two references to 'glacier_v2_avalanche_c_base_trades' and 'glacier_v3_avalanche_c_base_trades' were added. These references were included along with other existing references in a list.

🔧 PR: #5056, Add gmx to dex.trades_beta
🧙 Author: @tomfutago on 2024-01-02
📝 Summary: The line ref('gmx_avalanche_c_base_trades') was added to the SQL model.

MODEL: glacier_v2_avalanche_c_base_trades.sql

🟢 Added by:

🔧 PR: #5053, Add glacier to dex.trades_beta
🧙 Author: @tomfutago on 2024-01-02
📝 Summary: This dbt SQL model creates a table called 'uniswap_compatible_v2_trades' that enables data analysts to analyze and query Uniswap V2 trades on the Avalanche C blockchain. It uses two sources, 'Pair_evt_Swap' and 'Factory_evt_PairCreated', from the Glacier project in order to populate the table with relevant data.

MODEL: glacier_v3_avalanche_c_base_trades.sql

🟢 Added by:

🔧 PR: #5053, Add glacier to dex.trades_beta
🧙 Author: @tomfutago on 2024-01-02
📝 Summary: This dbt SQL model creates a table called 'uniswap_compatible_v3_trades' that enables data analysts to analyze trades on the Avalanche C blockchain using the Glacier project. It sources data from two tables, 'AlgebraPool_evt_Swap' and 'AlgebraFactory_evt_Pool', and does not include any optional columns.

MODEL: [gmx_arbitrum_base_trades.sql](https://github.com/duneanalytics