📰 2023-04-21: Weekly Prophet! #3215
Replies: 7 comments 1 reply
-
|
phewww, this is cool! crazy to look back at the week and see the amazing contributions from the community |
Beta Was this translation helpful? Give feedback.
-
|
one quick piece of feedback: as of now, we mix sector/project at the same level of directory. i wonder if we revise the label of |
Beta Was this translation helpful? Give feedback.
-
|
yeah that's a good point! I couldn't figure out which were sectors and which were projects tbh, think we will need to document it and then I can make this more clear. |
Beta Was this translation helpful? Give feedback.
-
|
This is really cool, and helpful for catching any changes that I might have missed. |
Beta Was this translation helpful? Give feedback.
-
|
For those that want to be kept up to date on future editions of this, you can watch the repo and customize your notifs to trigger on any future discussions. |
Beta Was this translation helpful? Give feedback.
-
|
good idea |
Beta Was this translation helpful? Give feedback.
-
|
rubicon forever |
Beta Was this translation helpful? Give feedback.
-
|
rubicon forever |
Beta Was this translation helpful? Give feedback.
-
This is your weekly summary of 33 PRs merged from 18 wizards. Great job everyone! 🎉
We had 87 added models 🟢 and 70 modified models 🟠 for 26 Sectors.
SECTOR: dex
MODEL: dex_aggregator_trades.sql
🟠 Modified by:
🔧 PR: #3141, add oneinch to dex aggregator
🧙 Author: @jeff-dude on 2023-04-19
📝 Summary: The SQL model is a list of DEX aggregator models. The
oneinch_ethereum_tradesspell was added to the list, while theodos_tradesspell was removed due to containing duplicates. The other spells in the list includecow_protocol_trades,openocean_trades,paraswap_trades, andlifi_trades. There are also comments indicating that once made compatible with dunesql, the previously excluded spell (oneinch_ethereum_trade) will be added back into this model.🔧 PR: #3141, add bebop trades
🧙 Author: @B1boid on 2023-04-14
📝 Summary: A new reference to 'bebop_trades' has been added to the SQL model. This is in addition to existing references for 'paraswap_trades', 'lifi_trades', and 'yield_yak_avalanche_c_trades'. The comment suggests that these spells will be added once they are compatible with dunesql, which is a tool used for testing dbt models. Finally, there is a SELECT statement that selects all columns from the table(s) referenced in this model.
MODEL: dex_offers.sql
🟠 Modified by:
🔧 PR: #3175, update: dex.offers (specify maker) 🦁
🧙 Author: @denverbaumgartner on 2023-04-19
📝 Summary: In this SQL model, a new column called 'maker' was added to the SELECT statement. The rest of the columns remain unchanged.
MODEL: dex_trades.sql
🟠 Modified by:
🔧 PR: #3150, add verse dex to dex.trades - Ready for review
🧙 Author: @henrystats on 2023-04-18
📝 Summary: One reference model was added: 'verse_dex_ethereum_trades'. No reference models were removed.
🔧 PR: #3150, Add onepunchswap on bnb chain
🧙 Author: @sunopar on 2023-04-17
📝 Summary: The diff of the SQL model shows that 'onepunchswap_bnb_trades' reference model was added. No reference models were removed.
SECTOR: nft
MODEL: nft_ethereum_top_erc721_holders.sql
🟢 Added by:
🔧 PR: #3206, Top holders erc721 - Ready for review
🧙 Author: @henrystats on 2023-04-20
📝 Summary: This SQL model creates two CTEs that calculate the balance of ERC721 tokens held by each wallet address and the total supply of each NFT contract. It then selects the top 50 wallets with the highest token balances for each NFT contract, along with their respective supply share and total supply. This enables data analysts to easily identify which wallets hold a significant portion of an NFT's total supply, allowing them to perform further analysis on ownership distribution or potential market manipulation.
MODEL: nft_ethereum_top_erc1155_holders.sql
🟢 Added by:
🔧 PR: #3205, Top holders erc1155 - Ready for review
🧙 Author: @henrystats on 2023-04-20
📝 Summary: This SQL model creates a view that calculates the balance of each wallet address for a given ERC1155 token contract, and then calculates the total supply of that token. It also determines the share of supply held by each wallet address and ranks them in descending order. The resulting view can be used by data analysts to analyze ownership distribution and concentration for specific ERC1155 tokens on Ethereum blockchain.
MODEL: nft_ethereum_wallet_metrics.sql
🟢 Added by:
🔧 PR: #2946, Smart nft trader model (ROI based) from Dune Competition & intermediate model for future labels
🧙 Author: @nazihkalo on 2023-04-14
📝 Summary: This SQL model creates a table that enables data analysts to calculate aggregated trading statistics for wallets in the NFT market. The model filters out wash trades and adds mints as buys for $0 or gas fees. It then creates a longform version of buys and sells, calculates floor prices from two sources, computes profits and unrealized profits per trade, aggregates wallet trading stats such as unique collections traded, win percentage, loss percentage etc., and outputs them in a final table.
SECTOR: labels
MODEL: labels_nft.sql
🟠 Modified by:
🔧 PR: #2946, Smart nft trader model (ROI based) from Dune Competition & intermediate model for future labels
🧙 Author: @nazihkalo on 2023-04-14
📝 Summary: The added code creates a SQL query that selects all columns from multiple dbt models and unions them together. The list of models to be included is defined in a set at the beginning of the code, and then iterated over using a for loop to create individual SELECT statements for each model. Each SELECT statement includes specific column names, as well as some shared ones like blockchain, address, name etc., which are used to combine all results into one table using UNION ALL operator.
MODEL: labels_nft_smart_trader_roi_eth.sql
🟢 Added by:
🔧 PR: #2946, Smart nft trader model (ROI based) from Dune Competition & intermediate model for future labels
🧙 Author: @nazihkalo on 2023-04-14
📝 Summary: This SQL model creates a table of aggregated trading statistics for Ethereum wallets that have made at least 10 trades, traded in at least 3 unique collections, spent at least 1 ETH and realized a positive ROI. It then ranks these wallets by their realized ROI in descending order and assigns them labels based on their rank percentile (e.g. 'Top 1% Smart NFT Trader'). This enables data analysts to identify top-performing traders on the Ethereum blockchain with specific criteria and track their performance over time.
SECTOR: tokens
MODEL: tokens_ethereum_erc20.sql
🟠 Modified by:
🔧 PR: #3176, add oneinch to dex aggregator
🧙 Author: @jeff-dude on 2023-04-19
📝 Summary: [changes too large] The model tokens_ethereum_erc20.sql was modified.
🔧 PR: #3176, [Erc20] Add 120 missing tokens
🧙 Author: @bh2smith on 2023-04-21
📝 Summary: [changes too large] The model tokens_ethereum_erc20.sql was modified.
🔧 PR: #3176, [Erc20] Add 17 New Tokens
🧙 Author: @bh2smith on 2023-04-17
📝 Summary: The following token symbols were added or removed: APU, PEEPO, XAI, EP, yShori, yvCurve-CTR-ETH-f,TIANA,X-GPT ,ELFI ,MTM ,PEPE ,SHUGGI,CXAI George,GROYP,FYR,SERP.
🔧 PR: #3176, add 13 new erc20 tokens
🧙 Author: @bh2smith on 2023-04-14
📝 Summary: The following token symbols were added: FYFI, EMS, sdAPW, SIMP, vETH, FTX2.0, oDoge , PLSIOU , B-50WBTC-50WETH , agEUREUROC-f , CNCETH-f HAWKER and SERP. The following token symbol was removed: ePhiat
MODEL: tokens_polygon_erc20.sql
🟠 Modified by:
🔧 PR: #3186, token
REVVon Polygon for tokens and prices🧙 Author: @sohwak on 2023-04-18
📝 Summary: The added token symbols are CUSDCLP, SPHERE, TETU and REVV.
SECTOR: prices
MODEL: prices_bnb_tokens.sql
🟠 Modified by:
🔧 PR: #3177, Ad GHNY 0xa045E37a0D1dd3A45fefb8803D22457abc0A728a
🧙 Author: @roflfuso on 2023-04-19
📝 Summary: Two tokens were added: GHNY and LVL.
🔧 PR: #3177, Update LVL to prices.usd table
🧙 Author: @PAULZV on 2023-04-14
📝 Summary: The token symbols that were added are LVL and the token symbol that was removed is AXL.
MODEL: prices_polygon_tokens.sql
🟠 Modified by:
🔧 PR: #3186, Added LCD token
🧙 Author: @raoulpicconi on 2023-04-18
📝 Summary: The token symbol that was added is 'LCD'.
🔧 PR: #3186, token
REVVon Polygon for tokens and prices🧙 Author: @sohwak on 2023-04-18
📝 Summary: The token symbols that were added are REVV and the tokens that were removed is WSTETH.
MODEL: prices_ethereum_tokens.sql
🟠 Modified by:
🔧 PR: #3181, remove CAW from prices - permanently
🧙 Author: @0xRobin on 2023-04-18
📝 Summary: The token symbol 'CAW' was removed from the model.
🔧 PR: #3181, [Prices] Remove SHIH - permanently.
🧙 Author: @bh2smith on 2023-04-17
📝 Summary: The added token symbols are FUND, SWINGBY, PUNK, ODOGE, AVT and RUG. The removed token symbol is SHIH.
MODEL: prices_arbitrum_tokens.sql
🟠 Modified by:
🔧 PR: #3180, remove dupe price
🧙 Author: @jeff-dude on 2023-04-14
📝 Summary: The token symbol 'SWPR' was removed.
Click to toggle to see all other models
SECTOR: oneinch
MODEL: oneinch_unoswap_v5_ethereum_trades.sql
🟠 Modified by:
🔧 PR: #3197, add oneinch to dex aggregator
🧙 Author: @jeff-dude on 2023-04-19
📝 Summary: The diff of the SQL model shows changes made to a CTE called 'unoswap'. The join condition between this CTE and another table called 'traces' was modified for some transactions. Additionally, two new transactions were excluded from the join using a filter. A comment suggests removing this filter if the join is fixed.
SECTOR: sushiswap
MODEL: sushiswap_bnb_trades.sql
🟢 Added by:
🔧 PR: #2960, Add Sushiswap trades on BNB chain and Polygon
🧙 Author: @chrispearcx on 2023-04-20
📝 Summary: This SQL model creates a view of Sushiswap DEX trades on the Binance Smart Chain, including token pairs, amounts bought and sold, USD value of each trade (if available), taker/maker addresses and contract details. It enables data analysts to query this information for analysis or integration with other datasets. The model also includes incremental updates based on block time within the last week or since a specified project start date.
MODEL: sushiswap_polygon_trades.sql
🟢 Added by:
🔧 PR: #2960, Add Sushiswap trades on BNB chain and Polygon
🧙 Author: @chrispearcx on 2023-04-20
📝 Summary: This SQL model creates a view of Sushiswap DEX trades on the Polygon blockchain, including token pairs, amounts bought and sold, USD value (if available), contract addresses involved in the trade and transaction details. It enables data analysts to query this information for analysis or integration with other data sources. The model also includes incremental updates based on block time within the last week or from a specified project start date.
MODEL: sushiswap_trades.sql
🟠 Modified by:
🔧 PR: #2960, Add Sushiswap trades on BNB chain and Polygon
🧙 Author: @chrispearcx on 2023-04-20
📝 Summary: A new reference to the 'sushiswap_polygon_trades' table and a new reference to the 'sushiswap_bnb_trades' table were added in this diff of a dbt SQL model. These tables are now included along with existing references to other trading tables from different blockchains.
MODEL: sushiswap_optimism_pool_incentives_config.sql
🟢 Added by:
🔧 PR: #3071, Init Sushi Masterchef (Optimism)
🧙 Author: @MSilb7 on 2023-04-17
📝 Summary: This SQL model retrieves constructor arguments for each masterchef contract on the Optimism blockchain, including the contract address, reward token, reward per second and masterchef v2 address. This enables data analysts to better understand and analyze rewards distribution on this blockchain.
MODEL: sushiswap_optimism_pool_incentives_mappings.sql
🟢 Added by:
🔧 PR: #3071, Init Sushi Masterchef (Optimism)
🧙 Author: @MSilb7 on 2023-04-17
📝 Summary: This new dbt SQL model maps the pool id (pid) to the underlying pool address for data analysts. It retrieves this information from contract reads and currently only supports the Optimism blockchain. The model selects and groups relevant data from a source table called 'MiniChefV2_evt_LogPoolAddition' in order to create a new table with columns for blockchain, contract address, pid, and lp_address.
MODEL: sushiswap_optimism_pool_incentives_rates.sql
🟢 Added by:
🔧 PR: #3071, Init Sushi Masterchef (Optimism)
🧙 Author: @MSilb7 on 2023-04-17
📝 Summary: This dbt SQL model creates a table that enables data analysts to track the allocation of rewards for liquidity providers in SushiSwap pools on the Optimism network. The table includes information such as block date, blockchain, contract address, rewarder address, pool ID and LP token address. It also calculates the total allocation points and allocates tokens per second based on each pool's share of total allocation points. Additionally, it provides details about reward tokens including symbol and decimals through a join with another reference table.
SECTOR: lido
MODEL: lido_ethereum_accounting.sql
🟢 Added by:
🔧 PR: #3128, Lido ethereum accounting
🧙 Author: @gregshestakovlido on 2023-04-19
📝 Summary: [changes too large] The model lido_ethereum_accounting.sql was added.
🟠 Modified by:
🔧 PR: #3128, labels&fundraising fixes
🧙 Author: @ppclunghe on 2023-04-20
📝 Summary: The diff of the SQL model shows changes made to provisions for slashing insurance set aside. The term 'slashing provision' has replaced 'slashing insurance'. The liability account associated with it is recognized along with an asset account. Changes have been made in primary and secondary labels, accounts, categories, and tokens in different sections of the code.
MODEL: lido_ethereum_accounting_fundraising.sql
🟢 Added by:
🔧 PR: #3128, Lido ethereum accounting
🧙 Author: @gregshestakovlido on 2023-04-19
📝 Summary: This SQL model creates a table that enables data analysts to track fundraising transactions and ETH inflows for specific tokens. The
fundraising_txstable tracks transfers of specified tokens from diversification addresses to multisig wallets managed by Aragon or FinanceOpsMsig on Ethereum, while the second part of the query tracks ETH inflows into those same multisigs from diversification addresses. This information can be used to analyze fundraising trends and monitor token usage within these networks.🟠 Modified by:
🔧 PR: #3128, labels&fundraising fixes
🧙 Author: @ppclunghe on 2023-04-20
📝 Summary: The diff of the dbt SQL model shows that a filter condition was removed from the
fundraising_txstable wherevalue != 0. This means that all rows will be included in the output, regardless of their value. The rest of the code remains unchanged and includes a union with another table to capture ETH inflow.MODEL: lido_ethereum_accounting_dai_referral_payment.sql
🟢 Added by:
🔧 PR: #3128, Lido ethereum accounting
🧙 Author: @gregshestakovlido on 2023-04-19
📝 Summary: This SQL model creates a table that lists the DAI referral payments made by Lido DAO to various addresses. It enables data analysts to track and analyze these payments, including their timing, token type (DAI), contract address, and amount. The model also includes information on relevant Ethereum multisig wallets and intermediate addresses used in cross-chain transactions involving DAI.
MODEL: lido_ethereum_accounting_deposits.sql
🟢 Added by:
🔧 PR: #3128, Lido ethereum accounting
🧙 Author: @gregshestakovlido on 2023-04-19
📝 Summary: This SQL model creates a view that selects the block time, amount staked in ETH, token address and transaction hash from the
staking_ethereum_depositstable where the depositor entity is 'Lido'. This enables data analysts to easily query and analyze Lido's Ethereum deposits.MODEL: lido_ethereum_accounting_ldo_referral_payment.sql
🟢 Added by:
🔧 PR: #3128, Lido ethereum accounting
🧙 Author: @gregshestakovlido on 2023-04-19
📝 Summary: This SQL model creates a table that lists LDO referral payment transactions. It enables data analysts to track the amount of LDO tokens paid out as part of the referral program, including details such as transaction time and token amounts. The model also includes tables for various Ethereum multisig wallets, intermediate addresses used in bridging operations across different blockchains, and a list of addresses eligible for LDO referrals.
MODEL: lido_ethereum_accounting_lego_expenses.sql
🟢 Added by:
🔧 PR: #3128, Lido ethereum accounting
🧙 Author: @gregshestakovlido on 2023-04-19
📝 Summary: This SQL model creates a table that tracks token transactions made by the multisig wallet 'LegoMsig' on Ethereum blockchain. The table includes information such as the block time, token amount, and transaction hash for each transfer. This enables data analysts to analyze expenses made by LegoMsig in terms of different tokens and periods. Additionally, this model filters out transfers to/from certain addresses such as other multisigs or bridges which are not relevant for expense analysis purposes.
MODEL: lido_ethereum_accounting_liquidity_incentives.sql
🟢 Added by:
🔧 PR: #3128, Lido ethereum accounting
🧙 Author: @gregshestakovlido on 2023-04-19
📝 Summary: This SQL model creates a table that tracks liquidity incentives transactions for various tokens across different chains. It enables data analysts to analyze the amount of tokens transferred, their corresponding transaction hashes, and the period in which they were transferred. The model also includes lists of multisigs addresses, diversification addresses and intermediate addresses used in these transactions on Ethereum, Polygon (Matic), Optimism and Arbitrum chains.
MODEL: lido_ethereum_accounting_lox_incentives.sql
🟢 Added by:
🔧 PR: #3128, Lido ethereum accounting
🧙 Author: @gregshestakovlido on 2023-04-19
📝 Summary: This SQL model creates a table that summarizes the transactions related to liquidity incentives for various tokens across different chains. It enables data analysts to track and analyze the amount of tokens transferred, their corresponding contracts, and time periods in which these transfers occurred. The model also includes lists of multisig wallets, diversification addresses, and intermediate addresses used in these transactions.
MODEL: lido_ethereum_accounting_operating_expenses.sql
🟢 Added by:
🔧 PR: #3128, Lido ethereum accounting
🧙 Author: @gregshestakovlido on 2023-04-19
📝 Summary: This SQL model creates a table that tracks operating expenses transactions for specific tokens on Ethereum and Polygon chains. It enables data analysts to monitor the outflow of funds from multisig wallets associated with Lido, Balancer, SushiSwap, 1inch and other DeFi protocols. The table includes information about the token amount transferred in each transaction as well as its timestamp and transaction hash.
MODEL: lido_ethereum_accounting_other_expenses.sql
🟢 Added by:
🔧 PR: #3128, Lido ethereum accounting
🧙 Author: @gregshestakovlido on 2023-04-19
📝 Summary: This SQL model creates a table that tracks the outflow of tokens from specific Ethereum addresses. It enables data analysts to monitor expenses and payments made by various multisig wallets, including those used for liquidity rewards and referral programs. The table includes information on the token type, amount transferred, transaction hash, and time period in which it occurred.
MODEL: lido_ethereum_accounting_other_income.sql
🟢 Added by:
🔧 PR: #3128, Lido ethereum accounting
🧙 Author: @gregshestakovlido on 2023-04-19
📝 Summary: This SQL model creates a table that combines data from various sources to track income transactions for different tokens. It includes Ethereum and Solana blockchain data, as well as lists of token addresses, multisig wallets, diversification addresses and referral payment recipients. The resulting table shows the period (timeframe), token type, amount of tokens received and transaction hash for each income transaction. This enables analysts to better understand the flow of funds within these ecosystems and identify trends or anomalies in income streams over time.
MODEL: lido_ethereum_accounting_revenue.sql
🟢 Added by:
🔧 PR: #3128, Lido ethereum accounting
🧙 Author: @gregshestakovlido on 2023-04-19
📝 Summary: This SQL model creates a table that calculates revenue and fees for depositors, treasury, insurance and operators based on Lido's oracle transactions. It joins three subqueries to extract data from the
LidoOracle_evt_PostTotalShares,steth_evt_FeeSetandsteth_evt_FeeDistributionSettables. The resulting table includes columns such as period (date), token address, total rewards earned by depositors, protocol fee percentage charged by Lido protocol on stETH transactions etc., which enables data analysts to analyze revenue streams of different stakeholders in the system over time.MODEL: lido_ethereum_accounting_trp_expenses.sql
🟢 Added by:
🔧 PR: #3128, Lido ethereum accounting
🧙 Author: @gregshestakovlido on 2023-04-19
📝 Summary: This SQL model creates several CTEs that extract data related to various addresses and tokens. It enables data analysts to query the Ethereum blockchain for information on token transfers, multisig wallets, referral payments, and expenses transactions. The extracted data includes details such as block time, contract address, token amount transferred or spent in a transaction hash. This model can be used by analysts to gain insights into Lido's operations across different chains like Ethereum and Polygon among others.
MODEL: lido_ethereum_accounting_test.sql
🟢 Added by:
🔧 PR: #3128, Lido ethereum accounting
🧙 Author: @gregshestakovlido on 2023-04-19
📝 Summary: This SQL model creates a CTE (Common Table Expression) that runs two tests on the Lido Ethereum accounting deposits and revenue data. The first test checks if the sum of amount staked is equal to a specific value for a given transaction hash, while the second test checks if total revenue matches another specific value for an event transaction hash. This model enables data analysts to easily run these tests and quickly identify any discrepancies in their Lido deposit or revenue data.
SECTOR: looksrare
MODEL: looksrare_ethereum_events.sql
🟠 Modified by:
🔧 PR: #3183, Add LooksRare v2
🧙 Author: @hildobby on 2023-04-20
📝 Summary: The diff of the dbt SQL model shows changes made to a LooksRare trades table. The changes include adding two new NFT models, updating the incremental logic for one of them, and modifying several columns in the final SELECT statement. Additionally, some subqueries were removed while others were added or modified to reflect these updates. Overall, this appears to be an update that expands on existing functionality by incorporating additional data sources and refining certain aspects of data processing.
MODEL: looksrare_v1_ethereum_events.sql
🟢 Added by:
🔧 PR: #3183, Add LooksRare v2
🧙 Author: @hildobby on 2023-04-20
📝 Summary: This SQL model creates a view that enables data analysts to query LooksRareExchange_evt_TakerAsk, LooksRareExchange_evt_TakerBid and LooksRareExchange_evt_RoyaltyPayment tables in the Ethereum blockchain. The view provides information on trades such as trade category, seller, buyer, amount of items traded and platform fees charged. It also includes information on royalties paid for each trade. Data analysts can use this view to analyze trading patterns and royalty payments made by Looksrare Exchange users over time.
MODEL: looksrare_v2_ethereum_events.sql
🟢 Added by:
🔧 PR: #3183, Add LooksRare v2
🧙 Author: @hildobby on 2023-04-20
📝 Summary: This SQL model creates a table of trades for the LooksRare v2 project on Ethereum, including information such as trade category, amount in raw and original currency values, token standard, collection name and aggregator details. It also calculates platform fees and royalty fees in both raw and USD values. The model enables data analysts to analyze LooksRare v2 trading activity on Ethereum with detailed fee breakdowns.
SECTOR: magiceden
MODEL: magiceden_polygon_events.sql
🟠 Modified by:
🔧 PR: #3182, Fix multiple currency payment in a single tx
🧙 Author: @springzh on 2023-04-20
📝 Summary: The SQL model added a new section to calculate the total payment for each token using native MATIC as currency. The 'order_amount_percentage' is found and used to calculate the total amount_raw, platform_fee_amount_raw, and royalty_fee_amount_raw. Max platform fee percentage is set at 2%, while max royalty fee percentage is set at 0.5%. There are also returned amounts that need excluding when calculating the transaction amount for ERC1155 orders. Finally, there's an update on how trade amounts are calculated in erc20_trade_amount_detail by excluding transfers to contracts which are temporary transfers.
MODEL: magiceden_polygon_sample_trades.csv
🟢 Added by:
🔧 PR: #3182, Fix multiple currency payment in a single tx
🧙 Author: @springzh on 2023-04-20
📝 Summary: [changes too large] The model magiceden_polygon_sample_trades.csv was added.
SECTOR: rubicon
MODEL: rubicon_optimism_offers.sql
🟠 Modified by:
🔧 PR: #3175, update: dex.offers (specify maker) 🦁
🧙 Author: @denverbaumgartner on 2023-04-19
📝 Summary: In this SQL model, a new column called 'maker' was added to the SELECT statement. The rest of the code remains unchanged and continues to select columns such as block_number, tx_index, evt_index, sell_token_symbol and buy_token_symbol from different tables.
MODEL: rubicon_offers.sql
🟠 Modified by:
🔧 PR: #3175, update: dex.offers (specify maker) 🦁
🧙 Author: @denverbaumgartner on 2023-04-19
📝 Summary: In this SQL model, a new column called 'maker' was added to the existing columns block_number, tx_index, evt_index, sell_token_symbol, buy_token_symbol and sell_token_address. No other changes were made in this diff.
MODEL: rubicon_optimism_offers_test.sql
🟠 Modified by:
🔧 PR: #3175, update: dex.offers (specify maker) 🦁
🧙 Author: @denverbaumgartner on 2023-04-19
📝 Summary: The SQL model includes a unit test that checks the correctness of certain fields in a table. The added code tests whether the 'maker' field is correct by comparing it to another table's 'maker' field, and returns TRUE if they match. If any of these tests fail (including the new maker_test), then those rows are filtered out from being included in the final output.
SECTOR: tigris
MODEL: tigris_v1_arbitrum_events_add_margin.sql
🟠 Modified by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: The changes made to the SQL model involve updating the version numbers for each subquery in a union. The previous versions were replaced with new ones, where each subquery is now labeled as v1.x instead of vx. Additionally, an empty add_margin_v5 table was added to the beginning of the query and included in the union with its own updated version number.
MODEL: tigris_v1_arbitrum_events_close_position.sql
🟠 Modified by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: The SQL model 'close_position_v5' was modified to include a SELECT statement that selects all columns from four different versions of the same table ('close_position_v2', 'close_position_v3', 'close_position_v4', and itself) and appends a new column called 'version' with values '1.2', '1.3', '1.4', and '1.5' respectively for each version selected, using UNION ALL to combine them into one result set.
MODEL: tigris_v1_arbitrum_events_limit_order.sql
🟠 Modified by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: The SQL model adds a prefix 'v1.' to the version column and selects data from limit order trading event tables. It also extracts the date, time, and index of each event block.
MODEL: tigris_v1_arbitrum_events_liquidate_position.sql
🟠 Modified by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: The changes made to the SQL model involve updating the version numbers of each subquery and combining them using UNION ALL. The original SELECT statement for each subquery is preserved, with only a new column 'version' added to indicate which version it belongs to.
MODEL: tigris_v1_arbitrum_events_modify_margin.sql
🟠 Modified by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: The changes made to the SQL model involve modifying the version numbers of each subquery. The original version numbers (v2, v3, v4 and v5) were replaced with new ones (v1.2, v1.3, v1.4 and v1.5). Additionally, a SELECT statement was added to each subquery that includes the new version number as a column in the output table.The overall structure of UNION ALL statements remains unchanged from before these modifications were made.
MODEL: tigris_v1_arbitrum_events_open_position.sql
🟠 Modified by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: The diff shows changes made to a SQL model named 'open_positions_v5'. The SELECT statement has been modified to include a new column called 'version' with updated values for each subquery. The previous version numbers (v2, v3, v4 and v5) have been replaced with new ones (v1.2, v1.3, v1.4 and v1.5).
MODEL: tigris_v2_arbitrum_events_add_margin.sql
🟢 Added by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: This SQL model creates a view that combines two tables of trading events from the Tigris protocol on Arbitrum. Specifically, it selects data related to adding margin to positions and calculates the change in margin, new margin, price and trader for each event. The resulting view includes columns for date, transaction hash, index within block time of event occurrence as well as position ID and version number (either v2.1 or v2.2). This enables analysts to track changes in margins over time across different versions of the protocol on Arbitrum network using a single query outputting all relevant information together.
MODEL: tigris_v2_arbitrum_events_close_position.sql
🟢 Added by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: This SQL model creates a view that combines two tables of closed trading positions from the tigristrade_v2_arbitrum database. The resulting view includes columns for the date, transaction hash, index, block time, position ID, price at closing time (in ETH), payout amount (in ETH), percentage of position closed and trader's address. This enables data analysts to easily query and analyze historical data on closed trading positions across different versions of the Trading contract in Tigristrade V2 Arbitrum database.
MODEL: tigris_v2_arbitrum_events_limit_order.sql
🟢 Added by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: This SQL model creates a view that combines data from multiple trading event tables and an asset table to provide information on limit orders executed in the Tigristrade V2 Arbitrum platform. The resulting view includes details such as version, date, block time, transaction hash, position ID, price and volume of the order executed along with other relevant fields. This enables data analysts to analyze trading activity on the platform by querying this view.
MODEL: tigris_v2_arbitrum_events_liquidate_position.sql
🟢 Added by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: This SQL model creates a view that combines two tables of liquidated trading positions from different versions of the Tigris protocol on Arbitrum. The resulting view includes columns for the date, transaction hash, index, block time, position ID and trader for each liquidation event. This enables data analysts to easily query and analyze all liquidations across both versions of the protocol in one place. The model also adds a version column to distinguish between events from each table.
MODEL: tigris_v2_arbitrum_events_modify_margin.sql
🟢 Added by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: This SQL model creates a view that combines data from two different sources related to margin modifications in trading. It includes information such as the date, transaction hash, position ID, type of modification (add or remove), amount of margin change and new leverage. The view is designed to be incremental and versioned with each row indicating which version it belongs to (v2.1 or v2.2). This enables data analysts to easily analyze changes in margins over time across multiple versions of the trading system on Arbitrum blockchain network using dbt SQL tools.
MODEL: tigris_v2_arbitrum_events_open_position.sql
🟢 Added by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: This SQL model creates a view that combines data from two different sources of open trading positions,
open_positions_v1andopen_positions_v2, into one table. It includes information such as the date, time, transaction hash, position ID, price and volume in USD for each trade. The view also provides details on the asset being traded (including its pair), direction of trade (long or short), margin asset used to open the position and referral source if applicable. This enables analysts to easily access all relevant information about current trading positions across multiple versions of Tigris Trade's platform on Arbitrum network.MODEL: tigris_v1_arbitrum_positions_close.sql
🟢 Added by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: This SQL model creates a view called 'latest_leverage' that calculates the latest leverage for each position in an arbitrage trading system. It joins two tables, 'tigris_v1_arbitrum_events_close_position' and 'tigris_v1_arbitrum_positions_leverage', to calculate the payout, margin, and other relevant information for each position. This view enables data analysts to easily access and analyze the latest leverage data for positions in this trading system.
MODEL: tigris_v1_arbitrum_positions_leverage.sql
🟢 Added by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: This SQL model creates a view called 'leverage' that combines data from three different tables related to open positions, margin modifications, and limit orders. The view includes the timestamp of each event, the position ID associated with it, and the leverage used in each case. This enables data analysts to easily query and analyze leverage usage across these different types of events in their analysis.
MODEL: tigris_v1_arbitrum_positions_liquidation.sql
🟢 Added by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: This SQL model creates a view that enables data analysts to retrieve the latest margin and leverage values for each liquidated position in a database. The view uses two subqueries to find the most recent margin and leverage values for each position, then joins them with a table of liquidated positions based on their shared position ID. This allows analysts to easily analyze trends in margin and leverage leading up to positions being liquidated.
MODEL: tigris_v1_arbitrum_positions_margin.sql
🟢 Added by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: This SQL model creates a view called 'margin' that combines data from multiple tables related to margin changes and limit orders in the Tigris Arbitrum system. This enables analysts to easily query and analyze all relevant margin data in one place, potentially leading to insights into trading behavior or risk management strategies.
MODEL: tigris_v2_arbitrum_positions_close.sql
🟢 Added by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: This SQL model creates a view called 'latest_leverage' that calculates the latest leverage for each position in an arbitrage trading system. It does this by joining two tables, one containing information about closed positions and another containing information about position leverage. The resulting view enables data analysts to easily access the latest leverage for each position, which can be used to analyze trading performance and risk management strategies.
MODEL: tigris_v2_arbitrum_positions_leverage.sql
🟢 Added by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: This SQL model creates a view called 'leverage' that combines data from three different tables related to open positions, modified margins, and limit orders. The view includes the event block time, position ID, and leverage for each record. This enables data analysts to easily query and analyze leverage information across these different types of events in one consolidated table.
MODEL: tigris_v2_arbitrum_positions_liquidation.sql
🟢 Added by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: This SQL model creates a view that enables data analysts to retrieve the latest margin and leverage values for each position at the time of liquidation events. The view joins three tables:
tigris_v2_arbitrum_events_liquidate_position,tigris_v2_arbitrum_positions_margin, andtigris_v2_arbitrum_positions_leverage. By using subqueries, it selects only the most recent margin and leverage values for each position based on their respective timestamps. This allows analysts to better understand how positions were performing leading up to their liquidation events.MODEL: tigris_v2_arbitrum_positions_margin.sql
🟢 Added by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: This SQL model creates a common table expression (CTE) called 'margin' that combines data from multiple tables related to margin changes and open positions in the Tigris arbitrum events database. The CTE includes columns for event block time, position ID, and margin amount. This enables data analysts to easily query and analyze all relevant margin information in one place.
MODEL: tigris_arbitrum_trades.sql
🟠 Modified by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: This SQL model combines data from multiple tables related to trading positions and orders in the Tigris protocol on Arbitrum. It creates several subqueries for different types of trades, including open positions, limit orders, closed positions due to liquidation or user action (close_position), adding margin to existing trades (add_margin), and modifying margin on existing trades (modify_margin). The final query selects all columns from each subquery across multiple models using a union all statement.
MODEL: tigris_v1_arbitrum_trades.sql
🟢 Added by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: This SQL model creates a view that combines data from multiple tables related to trading positions on the Arbitrum blockchain. The resulting view includes information about open positions, limit orders, closed positions, liquidated positions and margin modifications. This enables data analysts to analyze trading activity on the platform and gain insights into trader behavior over time.
MODEL: tigris_v2_arbitrum_trades.sql
🟢 Added by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: This SQL model creates a view that combines data from multiple tables related to trading positions on the Arbitrum blockchain. The resulting view includes information about open positions, limit orders, closed positions, liquidated positions and margin modifications. This enables data analysts to analyze trading activity on the Arbitrum blockchain and gain insights into trader behavior over time.
MODEL: tigris_v1_polygon_events_add_margin.sql
🟠 Modified by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: The changes made to the SQL model involve updating the version numbers for each subquery and adding a new subquery called 'add_margin_v8'. The SELECT statement remains unchanged, with all columns being selected from each of the four subqueries. The only addition is a column called 'version' which specifies the version number for each row based on its source table.
MODEL: tigris_v1_polygon_events_close_position.sql
🟠 Modified by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: The diff shows changes made to a SQL model that creates eight different versions of a closed position table. The main change is the replacement of
tigris_polygon_events_open_positionwithtigris_v1_polygon_events_open_position. Additionally, each version has been assigned a new version number and one condition has been added to close_position_v8.MODEL: tigris_v1_polygon_events_limit_order.sql
🟠 Modified by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: The SQL model adds a version number to the
limit_orderstable and renames it asv1. It also selects the date, block time, and index of each trading event for limit orders.MODEL: tigris_v1_polygon_events_liquidate_position.sql
🟠 Modified by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: The diff shows changes made to a SQL model that creates multiple views of liquidated positions from different versions. The main change is the renaming of the reference table
tigris_polygon_events_open_positiontotigris_v1_polygon_events_open_position. Additionally, new views were added for each version and assigned a unique version number. Finally, all views are combined using UNION ALL and assigned their respective version numbers as an additional column in the output.MODEL: tigris_v1_polygon_events_modify_margin.sql
🟠 Modified by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: The diff shows changes made to a SQL model named
modify_margin. The WHERE clause was modified to exclude specific values ofevt_tx_hash. Additionally, four SELECT statements were added with different versions and aliases. Each SELECT statement selects all columns from its respective version table and adds a new column called 'version' with the corresponding version number as its value. Finally, these four SELECT statements are combined using UNION ALL operator into one result set.MODEL: tigris_v1_polygon_events_open_position.sql
🟠 Modified by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: The diff shows changes made to a SQL model that creates a view called
open_positions_v8. The logic of the change is to add a new column called 'version' to the output of each subquery, with values ranging from v1.1 through v1.8 for each respective subquery (v1-v7) and v8 being the current one. This allows tracking which version contributed which rows in case there are any discrepancies or issues later on when analyzing data from this view.MODEL: tigris_v2_polygon_events_add_margin.sql
🟢 Added by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: This SQL model creates a view that combines two tables of trading events,
Trading_evt_AddToPositionandTradingV2_evt_AddToPosition, into one table. The resulting table includes columns for the date of the event, transaction hash, index within the block, time of block creation, position ID number, margin change amount (converted to ETH), new margin amount (converted to ETH), price (converted to ETH), trader address and version number. This enables data analysts to analyze trading activity across both versions in a single query.MODEL: tigris_v2_polygon_events_close_position.sql
🟢 Added by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: This SQL model creates a view that combines two tables of closed trading positions from the Tigris protocol on Polygon. The resulting view includes data such as the date, transaction hash, position ID, closing price and payout amount in ETH, percentage of position closed and trader address. This enables analysts to easily query and analyze historical data on closed positions across different versions of the Tigris protocol.
MODEL: tigris_v2_polygon_events_limit_order.sql
🟢 Added by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: This SQL model creates a view that combines data from multiple trading event tables and pairs them with asset information. The resulting view includes fields such as version, day, evt_block_time, position_id, price and volume_usd. This enables analysts to easily query and analyze limit order trading data across different versions of the platform in one place.
MODEL: tigris_v2_polygon_events_liquidate_position.sql
🟢 Added by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: This SQL model creates a view that combines two tables of liquidated trading positions from different versions of the Tigristrade platform. The resulting view includes columns for the date, transaction hash, index, block time, position ID and trader. This enables data analysts to easily query and analyze all liquidated positions across both versions of the platform in one place. The model also includes an optional filter for incremental updates within the past week.
MODEL: tigris_v2_polygon_events_modify_margin.sql
🟢 Added by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: This SQL model creates two temporary tables that join margin modification events with add and remove margin calls. It calculates the change in margin, new leverage, and trader for each event. The model is designed to be incremental and includes a version column indicating which table the data came from (v2.1 or v2.2). This enables data analysts to track changes in margins over time across different versions of trading protocols on Tigristrade_v2_polygon source database.
MODEL: tigris_v2_polygon_events_open_position.sql
🟢 Added by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: This SQL model creates a view that combines data from two different sources of open trading positions,
open_positions_v1andopen_positions_v2, into one table. It includes information such as the date, time, transaction hash, position ID, price and volume in USD for each trade. The view also includes metadata about the version of the source data used to create it. This enables analysts to easily query all open trading positions across both versions of the source data in a single table for analysis purposes.MODEL: tigris_v1_polygon_positions_close.sql
🟠 Modified by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: The diff shows changes made to a SQL model that calculates the latest leverage of positions in a trading system. The changes involve updating references to two tables,
tigris_polygon_events_close_positionandtigris_polygon_positions_leverage, with their corresponding versions (tigris_v1_polygon_events_close_positionandtigris_v1_polygon_positions_leverage). Additionally, there is an alteration where one line of code has been commented out for testing purposes.MODEL: tigris_v1_polygon_positions_leverage.sql
🟠 Modified by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: The diff shows that the SQL model 'leverage' was modified by changing the references to three different models: tigris_polygon_events_open_position, tigris_polygon_events_modify_margin and tigris_polygon_events_limit_order. The old references were replaced with new ones (tigris_v1_...). No other changes were made in this model.
MODEL: tigris_v1_polygon_positions_liquidation.sql
🟠 Modified by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: The diff shows changes made to a SQL model that involves two subqueries,
last_marginandlast_leverage. The changes involve replacing references to the old table names with new ones. Specifically, all instances oftigris_polygon_positions_margin,tigris_polygon_positions_leverage, andtigris_polygon_events_liquidate_positionwere replaced with their updated versions:tigris_v1_polygon_positions_margin,tigris_v1_polygon_positions_leverage, andtigris_v1_polygon_events_liquidate_position.MODEL: tigris_v1_polygon_positions_margin.sql
🟠 Modified by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: This diff of a dbt SQL model shows that the references to certain tables have been updated. Specifically, the references to
tigris_polygon_events_add_margin,tigris_polygon_events_modify_margin,tigris_polygon_events_open_position, andtigris_polygon_positions_closehave all been changed to their corresponding versions with prefix 'v1'. Additionally, a new reference has been added for tabletigris_v1_polygon_events_limit_order. The rest of the code remains unchanged.MODEL: tigris_v2_polygon_positions_close.sql
🟠 Modified by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: The SQL model is calculating the previous and new margin for a given position by joining two tables on their respective IDs and block times. The diff shows that the table names have been changed from 'tigris_arbitrum' to 'tigris_v2_polygon'.
MODEL: tigris_v2_polygon_positions_leverage.sql
🟠 Modified by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: The SQL model is modifying the source of three
leveragetables by changing the reference fromtigris_arbitrum_events_*totigris_v2_polygon_events_*. The modified tables are then unioned together. Each table contains two columns:position_idandleverage.MODEL: tigris_v2_polygon_positions_liquidation.sql
🟠 Modified by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: The SQL model has been updated to reference a new table for margin and leverage data. The previous tables have been replaced with the new ones in two different sections of the code. The SELECT statement remains unchanged, but now references a different liquidation events table that is joined with the last_margin subquery on position_id.
MODEL: tigris_v2_polygon_positions_margin.sql
🟠 Modified by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: The diff shows changes made to a SQL model that calculates margin for different events. The changes involve replacing references to tables in the
tigris_arbitrumschema with corresponding tables in thetigris_v2_polygonschema. Specifically, five different types of events are considered: adding margin, modifying margin, opening positions, closing positions and limit orders. For each event type except closing positions (where a new_margin column is added), two columns - position_id and margin - are selected from the relevant table and combined using UNION ALL into a single output table called 'margin'.MODEL: tigris_polygon_trades.sql
🟠 Modified by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: This diff adds a set of subqueries to the SQL model that query different tables and join them together. The resulting table is a union of all these subqueries, which include open positions, limit orders, closed positions due to liquidation or normal closure, adding margin events and modifying margin events. Each row in the final table has information about one trade including its type (open position/limit order/closed position etc.), blockchain name ('polygon'), day it occurred on and various other details such as trader ID, pair traded etc.
MODEL: tigris_v1_polygon_trades.sql
🟢 Added by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: This SQL model creates a view that combines data from multiple tables related to trading positions on the Polygon blockchain. It enables analysts to track open and closed positions, limit orders, liquidations, margin modifications and additions across different pairs of assets. The view includes information such as price, leverage used in trades and volume traded in USD for each event type.
MODEL: tigris_v2_polygon_trades.sql
🟢 Added by:
🔧 PR: #2987, add tigris v2 - ready for review
🧙 Author: @henrystats on 2023-04-19
📝 Summary: This SQL model creates a view that combines data from multiple tables related to trading positions on the Polygon blockchain. It includes information about open positions, limit orders, closed positions, liquidated positions and margin modifications. The view enables analysts to analyze trading activity on the Polygon blockchain by aggregating all relevant data into one table for easy querying and analysis.
SECTOR: opensea
MODEL: opensea_polygon_events.sql
🟠 Modified by:
🔧 PR: #3188, Work on
opensea.tradeson Polygon🧙 Author: @sohwak on 2023-04-19
📝 Summary: The SQL model has been modified to include a UNION ALL of three OpenSea Polygon events tables. The new table includes additional columns such as
currency_decimals,platform_fee_receive_address, and multiple royalty fee receive addresses. The original logic for extracting trade data from the ZeroExFeeWrapper_call_matchOrders function remains unchanged, but some filters have been added to exclude trades before a certain date or within the last week depending on whether it is an incremental run or not.MODEL: opensea_polygon_fees.sql
🟠 Modified by:
🔧 PR: #3188, Work on
opensea.tradeson Polygon🧙 Author: @sohwak on 2023-04-19
📝 Summary: The diff of the SQL model was not provided, so it is impossible to summarize what was added or removed. Please provide the diff in order for me to assist you.
MODEL: opensea_v2_polygon_events.sql
🟢 Added by:
🔧 PR: #3188, Work on
opensea.tradeson Polygon🧙 Author: @sohwak on 2023-04-19
📝 Summary: This SQL model creates a table that summarizes trade data from the OpenSea marketplace on Polygon blockchain. It includes information such as trade type, buyer and seller addresses, token ID and contract address, currency symbol and amount for each transaction. Additionally, it calculates platform fees and royalty fees associated with each transaction based on the fee structure of OpenSea's smart contracts. This model enables data analysts to analyze trading activity on OpenSea in order to gain insights into market trends or individual user behavior.
MODEL: opensea_v3_polygon_events.sql
🟢 Added by:
🔧 PR: #3188, Work on
opensea.tradeson Polygon🧙 Author: @sohwak on 2023-04-19
📝 Summary: This SQL model creates a view that merges data from the
seaport_polygon_tradestable with additional columns to identify trades recognized by OpenSea. The view includes information on blockchain, project, version, trade details such as buyer and seller addresses, token ID and contract address. It also calculates platform fee percentage and royalty fee percentage for each trade. This model enables data analysts to easily access merged trade data between Seaport and OpenSea in one place for analysis purposes without having to manually merge the two tables themselves.MODEL: opensea_v4_polygon_events.sql
🟢 Added by:
🔧 PR: #3188, Work on
opensea.tradeson Polygon🧙 Author: @sohwak on 2023-04-19
📝 Summary: [changes too large] The model opensea_v4_polygon_events.sql was added.
SECTOR: stealcam
MODEL: stealcam_arbitrum_events.sql
🟠 Modified by:
🔧 PR: #3198, Stealcam model fix
🧙 Author: @0xRobin on 2023-04-19
📝 Summary: The diff of the dbt SQL model shows that a new CTE named 'stealcam' was added to calculate surplus value. The platform fee and royalty fee calculation logic were updated using this surplus value. A few columns were removed from the SELECT statement, while some new ones were added. Two LEFT JOINs with traces table for calculating royalty fees and not_fee values have been removed as they are no longer needed after updating the calculation logic based on surplus_value.Certain WHERE conditions have also been modified accordingly.
SECTOR: verse_dex
MODEL: verse_dex_ethereum_trades.sql
🟢 Added by:
🔧 PR: #3127, add verse dex to dex.trades - Ready for review
🧙 Author: @henrystats on 2023-04-18
📝 Summary: This SQL model creates a view that enables data analysts to query and analyze transaction data from the Verse DEX on Ethereum. The view includes information such as blockchain, project, version, block date and time, token symbols and amounts bought/sold in raw form or converted with decimals. It also calculates the USD value of each transaction based on available price data at the time of execution. Additionally it provides details about taker/maker addresses involved in transactions along with their respective contract addresses for tokens being traded.
SECTOR: airdrop
MODEL: airdrop_claims.sql
🟢 Added by:
🔧 PR: #3147, Airdrop sector creation
🧙 Author: @hildobby on 2023-04-18
📝 Summary: This SQL model creates a view that combines data from multiple airdrop claims tables across different blockchains. This enables data analysts to easily query and analyze all airdrop claims in one place, regardless of the blockchain they were made on. The view includes information such as recipient address, token amount, and USD value at the time of the claim. If used incrementally, it only selects records from the past week for faster processing times.
MODEL: airdrop_arbitrum_claims.sql
🟢 Added by:
🔧 PR: #3147, Airdrop sector creation
🧙 Author: @hildobby on 2023-04-18
📝 Summary: This SQL model creates a view that combines data from the 'arbitrum_arbitrum_airdrop_claims' table. The view includes columns such as blockchain, block time, project, recipient address and token information. This enables data analysts to easily query and analyze airdrop claims data across multiple sources in one place.
MODEL: airdrop_avalanche_c_claims.sql
🟢 Added by:
🔧 PR: #3147, Airdrop sector creation
🧙 Author: @hildobby on 2023-04-18
📝 Summary: This SQL model creates a view that combines data from the 'pangolin_avalanche_c_airdrop_claims' table. The resulting view includes columns such as blockchain, block time, project, recipient and token symbol among others. This enables data analysts to easily query and analyze airdrop claims data across multiple sources in one place.
MODEL: airdrop_bnb_claims.sql
🟢 Added by:
🔧 PR: #3147, Airdrop sector creation
🧙 Author: @hildobby on 2023-04-18
📝 Summary: This SQL model creates a view that combines data from the
ellipsis_finance_bnb_airdrop_claimstable. The view includes columns such as blockchain, block time, project, recipient address and token information. This enables analysts to easily query and analyze airdrop claims data across multiple sources in one place.MODEL: airdrop_ethereum_claims.sql
🟢 Added by:
🔧 PR: #3147, Airdrop sector creation
🧙 Author: @hildobby on 2023-04-18
📝 Summary: This SQL model creates a view that combines data from the 'ampleforth_ethereum_airdrop_claims' table. The resulting view includes columns such as blockchain, block time, project, recipient and amount in various formats (raw/original/USD). This enables data analysts to easily query and analyze a consolidated dataset of Ethereum airdrop claims for Ampleforth protocol.
MODEL: airdrop_gnosis_claims.sql
🟢 Added by:
🔧 PR: #3147, Airdrop sector creation
🧙 Author: @hildobby on 2023-04-18
📝 Summary: This SQL model creates a view that combines data from the 'giveth_gnosis_airdrop_claims' table. The resulting view includes information about blockchain transactions related to airdrop claims, such as block time and number, project name, recipient address, transaction hash and token details. This enables data analysts to easily query and analyze all relevant airdrop claim data in one place.
MODEL: airdrop_optimism_claims.sql
🟢 Added by:
🔧 PR: #3147, Airdrop sector creation
🧙 Author: @hildobby on 2023-04-18
📝 Summary: This SQL model creates a view that combines data from the 'velodrome_optimism_airdrop_claims' table and any other tables specified in the 'airdrop_claims_models' list. The resulting view includes columns for blockchain, block time, project, recipient address, transaction hash and various amounts related to tokens. This enables analysts to easily query and analyze data across multiple airdrop claim tables without having to manually merge them together.
SECTOR: ampleforth
MODEL: ampleforth_ethereum_airdrop_claims.sql
🟢 Added by:
🔧 PR: #3147, Airdrop sector creation
🧙 Author: @hildobby on 2023-04-18
📝 Summary: This SQL model creates a table that enables data analysts to track Ampleforth Forth Airdrop transactions on the Ethereum blockchain. The table includes information such as block time, block number, recipient address, transaction hash, amount of tokens transferred (in raw and original values), USD value of the transfer at the time it occurred (using historical price data), token address and symbol. This allows for analysis of trends in airdrop activity over time and can be used to inform investment decisions or other strategic planning related to Ampleforth's FORTH token.
SECTOR: arbitrum
MODEL: arbitrum_arbitrum_airdrop_claims.sql
🟢 Added by:
🔧 PR: #3147, Airdrop sector creation
🧙 Author: @hildobby on 2023-04-18
📝 Summary: This SQL model creates a view that enables data analysts to query and analyze the Arbitrum Airdrop event data. The view includes information such as blockchain, block time, project name, recipient address, transaction hash and token details. It also calculates the amount of tokens in USD based on their value at the time of distribution using price data from an external source. This model can be used for reporting or further analysis related to this specific airdrop event on Arbitrum blockchain.
SECTOR: ellipsis_finance
MODEL: ellipsis_finance_bnb_airdrop_claims.sql
🟢 Added by:
🔧 PR: #3147, Airdrop sector creation
🧙 Author: @hildobby on 2023-04-18
📝 Summary: This SQL model creates a table that enables data analysts to track Ellipsis Finance Airdrop transactions on the Binance Smart Chain. The table includes information such as blockchain, block time and number, project name, recipient address, transaction hash, token symbol and amount in both raw and original formats. Additionally it calculates the USD value of each transaction based on historical prices of EPS token at the time of transaction or earliest available price if before then.
SECTOR: giveth
MODEL: giveth_gnosis_airdrop_claims.sql
🟢 Added by:
🔧 PR: #3147, Airdrop sector creation
🧙 Author: @hildobby on 2023-04-18
📝 Summary: This SQL model creates a table that enables data analysts to track Giveth Airdrop transactions on the Gnosis blockchain. The table includes information such as the recipient's account, transaction hash, amount of tokens received in both raw and original values, and USD value at the time of transaction. It also joins with a reference table for price information and filters transactions within a specific date range.
SECTOR: pangolin
MODEL: pangolin_avalanche_c_airdrop_claims.sql
🟢 Added by:
🔧 PR: #3147, Airdrop sector creation
🧙 Author: @hildobby on 2023-04-18
📝 Summary: This SQL model creates a table that enables data analysts to track the Pangolin Airdrop on the Avalanche C blockchain. The table includes information such as block time, block number, recipient address, transaction hash and token symbol. It also calculates the amount of tokens claimed in both raw and original values as well as their USD value at the time of claiming using an early price reference point or current market prices depending on when they were claimed.
SECTOR: velodrome
MODEL: velodrome_optimism_airdrop_claims.sql
🟢 Added by:
🔧 PR: #3147, Airdrop sector creation
🧙 Author: @hildobby on 2023-04-18
📝 Summary: This SQL model creates a view that calculates the USD value of VELO tokens transferred during Velodrome Airdrop on Optimism blockchain. It uses data from two sources: MerkleClaim_evt_Claim and dex_prices tables, and joins them based on the token address. The resulting view includes information about recipient addresses, transaction hashes, block numbers and times, as well as original token amounts in both raw format and converted to USD using median price bounds for the time period when transactions occurred. This enables data analysts to analyze VELO token transfers during Velodrome Airdrop in terms of their dollar value.
SECTOR: tornado_cash
MODEL: tornado_cash_arbitrum_deposits.sql
🟢 Added by:
🔧 PR: #3017, Split
tornado_cash.depositsandtornado_cash.withdrawalsinto chain-specific models🧙 Author: @hildobby on 2023-04-14
📝 Summary: This dbt SQL model creates a table that extracts deposit events data from the ETHTornado_evt_Deposit table in the Tornado Cash Arbitrum database. It joins this with transaction data from the transactions table in the Arbitrum blockchain database to provide additional information such as depositor address, contract address, amount deposited and transaction hash. The model also includes conditional statements for incremental updates and sets default values for currency_contract, currency_symbol, blockchain and tornado_version columns. This enables analysts to easily query deposit event data on Tornado Cash's privacy-preserving smart contracts running on Ethereum's Layer 2 scaling solution - Arbitrum.
🟠 Modified by:
🔧 PR: #3017, Change tornado tokens to the right ones
🧙 Author: @hildobby on 2023-04-18
📝 Summary: The SQL model sets a variable for the start date and selects data from a table. It changes the currency contract address from '0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2' to '0x82af49447d8a07e3bd95bd0d56f35241523fbab1'. The selected columns include block time, currency symbol, blockchain name and tornado version.
MODEL: tornado_cash_arbitrum_withdrawals.sql
🟢 Added by:
🔧 PR: #3017, Split
tornado_cash.depositsandtornado_cash.withdrawalsinto chain-specific models🧙 Author: @hildobby on 2023-04-14
📝 Summary: This SQL model creates a table that extracts data from the ETHTornado_evt_Withdrawal and transactions tables in the Tornado Cash Arbitrum database. It includes information such as block time, currency contract, blockchain type, transaction sender and recipient addresses, nullifier hash value, fee amount paid by sender to relayer for processing transaction on blockchain network etc. This model enables data analysts to analyze withdrawal activities of users on Tornado Cash platform using Ethereum cryptocurrency on Arbitrum network version 'classic'.
🟠 Modified by:
🔧 PR: #3017, Change tornado tokens to the right ones
🧙 Author: @hildobby on 2023-04-18
📝 Summary: The SQL model changes the currency_contract value from '0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2' to '0x82af49447d8a07e3bd95bd0d56f35241523fbab1'. The rest of the SELECT statement remains unchanged.
MODEL: tornado_cash_avalanche_c_deposits.sql
🟢 Added by:
🔧 PR: #3017, Split
tornado_cash.depositsandtornado_cash.withdrawalsinto chain-specific models🧙 Author: @hildobby on 2023-04-14
📝 Summary: This SQL model creates a table that extracts deposit events from the Avalanche C chain of Tornado Cash, a decentralized privacy-preserving protocol. The table includes information such as block time, currency contract address and symbol, blockchain name and version, depositor's address, amount deposited in different contracts' addresses (10/100/500), transaction hash and leaf index. This enables data analysts to analyze deposits made on the Avalanche C chain of Tornado Cash for various purposes such as tracking user behavior or monitoring network activity.
🟠 Modified by:
🔧 PR: #3017, Change tornado tokens to the right ones
🧙 Author: @hildobby on 2023-04-18
📝 Summary: The SQL model changes the currency_contract from '0x85f138bfee4ef8e540890cfb48f620571d67eda3' to '0xb31f66aa3c1e785363f0875a1b74e27b85fd66c7'. The rest of the SELECT statement remains unchanged.
MODEL: tornado_cash_avalanche_c_withdrawals.sql
🟢 Added by:
🔧 PR: #3017, Split
tornado_cash.depositsandtornado_cash.withdrawalsinto chain-specific models🧙 Author: @hildobby on 2023-04-14
📝 Summary: This dbt SQL model creates a table that extracts data from the Tornado Cash Avalanche C blockchain and joins it with transaction data. The resulting table includes information on block time, currency contract, blockchain type, tornado version, sender and recipient addresses, nullifier hash value for privacy purposes, fee amount paid by the sender in AVAX cryptocurrency units (with decimals), relayer address if applicable to the transaction type (otherwise NULL), contract address of withdrawal requestor's wallet or smart contract used to initiate withdrawal request along with corresponding amounts withdrawn. This model enables analysts to perform further analysis on Tornado Cash transactions made on Avalanche C network.
🟠 Modified by:
🔧 PR: #3017, Change tornado tokens to the right ones
🧙 Author: @hildobby on 2023-04-18
📝 Summary: The SQL model changes the currency_contract from '0x85f138bfee4ef8e540890cfb48f620571d67eda3' to '0xb31f66aa3c1e785363f0875a1b74e27b85fd66c7'. The rest of the SELECT statement remains unchanged.
MODEL: tornado_cash_bnb_deposits.sql
🟢 Added by:
🔧 PR: #3017, Split
tornado_cash.depositsandtornado_cash.withdrawalsinto chain-specific models🧙 Author: @hildobby on 2023-04-14
📝 Summary: This SQL model creates a table that extracts deposit events from the Tornado Cash BNB smart contract on the Ethereum blockchain. It includes information such as block time, currency contract, depositor address, amount deposited and transaction hash. This enables data analysts to analyze deposits made into Tornado Cash BNB and gain insights into user behavior on this platform. The model also allows for incremental updates to be made based on a specified time interval.
🟠 Modified by:
🔧 PR: #3017, Change tornado tokens to the right ones
🧙 Author: @hildobby on 2023-04-18
📝 Summary: In this SQL model, the currency contract address is being updated from '0xb8c77482e45f1f44de1745f52c74426c631bdd52' to '0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c'. The rest of the SELECT statement remains unchanged.
MODEL: tornado_cash_bnb_withdrawals.sql
🟢 Added by:
🔧 PR: #3017, Split
tornado_cash.depositsandtornado_cash.withdrawalsinto chain-specific models🧙 Author: @hildobby on 2023-04-14
📝 Summary: This SQL model creates a table that extracts data from the TornadoCashBNB_evt_Withdrawal and transactions tables to provide information on Binance Smart Chain (BNB) withdrawals made through Tornado Cash. The table includes details such as block time, currency contract, blockchain type, transaction sender and recipient addresses, withdrawal amount and fee paid. This enables data analysts to analyze the usage of Tornado Cash for privacy-preserving BNB transactions on the Binance Smart Chain network.
🟠 Modified by:
🔧 PR: #3017, Change tornado tokens to the right ones
🧙 Author: @hildobby on 2023-04-18
📝 Summary: In this SQL model, the currency contract address is being updated from '0xb8c77482e45f1f44de1745f52c74426c631bdd52' to '0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c'. The rest of the SELECT statement remains unchanged.
MODEL: tornado_cash_gnosis_deposits.sql
🟢 Added by:
🔧 PR: #3017, Split
tornado_cash.depositsandtornado_cash.withdrawalsinto chain-specific models🧙 Author: @hildobby on 2023-04-14
📝 Summary: This SQL model creates a table that extracts deposit data from the Tornado Cash Gnosis smart contract on the xDAI blockchain. The table includes information such as block time, currency contract, depositor address, amount deposited and transaction hash. This enables data analysts to analyze deposits made into Tornado Cash Gnosis smart contracts on the xDAI blockchain for various use cases such as tracking user behavior or monitoring network activity.
🟠 Modified by:
🔧 PR: #3017, Change tornado tokens to the right ones
🧙 Author: @hildobby on 2023-04-18
📝 Summary: In this SQL model, the currency contract address is being updated from '0x6b175474e89094c44da98b954eedeac495271d0f' to '0xe91d153e0b41518a2ce8dd3d7944fa863463a97d'. The rest of the SELECT statement remains unchanged.
MODEL: tornado_cash_gnosis_withdrawals.sql
🟢 Added by:
🔧 PR: #3017, Split
tornado_cash.depositsandtornado_cash.withdrawalsinto chain-specific models🧙 Author: @hildobby on 2023-04-14
📝 Summary: This dbt SQL model creates a table that extracts data from the Tornado Cash Gnosis smart contract and joins it with transaction data from the Gnosis blockchain. The resulting table includes information on block time, currency contract, currency symbol, blockchain type (Gnosis), tornado version (classic), sender address, nullifier hash value, fee amount in ETH units, relayer address and recipient address. Additionally it calculates an amount based on the contract_address field and provides transaction details such as tx_hash and evt_index. This model enables analysts to perform analysis of Tornado Cash transactions using Gnosis blockchain data for further insights into user behavior or network activity.
🟠 Modified by:
🔧 PR: #3017, Change tornado tokens to the right ones
🧙 Author: @hildobby on 2023-04-18
📝 Summary: In this SQL model, the currency contract address is being updated from '0x6b175474e89094c44da98b954eedeac495271d0f' to '0xe91d153e0b41518a2ce8dd3d7944fa863463a97d'. The other columns remain unchanged.
MODEL: tornado_cash_optimism_deposits.sql
🟢 Added by:
🔧 PR: #3017, Split
tornado_cash.depositsandtornado_cash.withdrawalsinto chain-specific models🧙 Author: @hildobby on 2023-04-14
📝 Summary: This dbt SQL model creates a table that extracts deposit data from the ETHTornado_evt_Deposit table in the Tornado Cash Optimism database. It includes information such as block time, currency contract, blockchain type, depositor address and transaction hash. The amount deposited is also included based on the contract address used for each deposit. This model enables data analysts to easily query and analyze Tornado Cash deposits made on Optimism blockchain using dbt's powerful features like incremental processing and source management.
🟠 Modified by:
🔧 PR: #3017, Change tornado tokens to the right ones
🧙 Author: @hildobby on 2023-04-18
📝 Summary: The SQL model changes the currency_contract value from '0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2' to '0x420000000000000000000000...'. The rest of the SELECT statement remains unchanged.
MODEL: tornado_cash_optimism_withdrawals.sql
🟢 Added by:
🔧 PR: #3017, Split
tornado_cash.depositsandtornado_cash.withdrawalsinto chain-specific models🧙 Author: @hildobby on 2023-04-14
📝 Summary: This SQL model creates a table that extracts data from the ETHTornado_evt_Withdrawal and transactions tables in the Tornado Cash Optimism database. It includes information such as block time, currency contract, blockchain type, transaction sender and recipient addresses, nullifier hash value, fee amount paid by sender to relayer for processing transaction on blockchain network etc. This model enables data analysts to analyze withdrawal transactions made through Tornado Cash protocol on Optimism L2 network using dbt (data build tool) framework.
🟠 Modified by:
🔧 PR: #3017, Change tornado tokens to the right ones
🧙 Author: @hildobby on 2023-04-18
📝 Summary: The SQL model changes the currency_contract value from '0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2' to '0x420000000000000000000000...'. The rest of the SELECT statement remains unchanged.
MODEL: tornado_cash_polygon_deposits.sql
🟢 Added by:
🔧 PR: #3185, Add Tornado Cash on Polygon
🧙 Author: @hildobby on 2023-04-17
📝 Summary: This dbt SQL model creates a table that extracts deposit events from the TornadoCashMatic_evt_Deposit table on Polygon blockchain. It includes information such as block time, currency contract, currency symbol, blockchain type and version of tornado protocol used. Additionally it provides depositor address, contract address and amount deposited in wei units along with transaction hash and leaf index for each deposit event. The model also filters data based on incremental or full refreshes using polygon_start_date parameter to ensure only relevant data is extracted for analysis by data analysts.
🟠 Modified by:
🔧 PR: #3185, Change tornado tokens to the right ones
🧙 Author: @hildobby on 2023-04-18
📝 Summary: The SQL model changes the currency_contract value from '0x7d1afa7b718fb893db30a3abc0cfc608aacfebb0' to '0x00000000000000000000000000...1010'. The other columns remain unchanged.
MODEL: tornado_cash_polygon_withdrawals.sql
🟢 Added by:
🔧 PR: #3185, Add Tornado Cash on Polygon
🧙 Author: @hildobby on 2023-04-17
📝 Summary: This dbt SQL model creates a table that extracts data from the TornadoCashMatic_evt_Withdrawal and transactions tables in the polygon database. It includes information such as block time, currency contract, blockchain, tornado version, transaction sender and recipient addresses, nullifier hash value for privacy purposes of users' withdrawal requests on Tornado Cash protocol. Additionally it calculates fees paid by users to relayers for their services rendered during withdrawals. The model also filters data based on incremental or full refreshes using specific dates to ensure only relevant data is extracted each time.
🟠 Modified by:
🔧 PR: #3185, Change tornado tokens to the right ones
🧙 Author: @hildobby on 2023-04-18
📝 Summary: The SQL model changes the currency_contract value from '0x7d1afa7b718fb893db30a3abc0cfc608aacfebb0' to '0x000000000000000000000000 1010'. The other columns remain unchanged.
MODEL: tornado_cash_deposits.sql
🟠 Modified by:
🔧 PR: #3017, Add Tornado Cash on Polygon
🧙 Author: @hildobby on 2023-04-17
📝 Summary: A new reference to a table named 'tornado_cash_polygon_deposits' was added to the SQL model. The SELECT statement at the end of the model remains unchanged and will return all columns from all referenced tables.
🔧 PR: #3017, Split
tornado_cash.depositsandtornado_cash.withdrawalsinto chain-specific models🧙 Author: @hildobby on 2023-04-14
📝 Summary: [changes too large] The model tornado_cash_deposits.sql was modified.
MODEL: tornado_cash_withdrawals.sql
🟠 Modified by:
🔧 PR: #3017, Add Tornado Cash on Polygon
🧙 Author: @hildobby on 2023-04-17
📝 Summary: A reference to a new table called 'tornado_cash_polygon_withdrawals' was added to an existing SQL model that selects all columns from several withdrawal tables. No other changes were made.
🔧 PR: #3017, add amount column to tornado cash withdrawals
🧙 Author: @jeff-dude on 2023-04-14
📝 Summary: The diff of the SQL model shows that a new column called 'amount' was added to the SELECT statement. The rest of the columns remain unchanged.
🔧 PR: #3017, Split
tornado_cash.depositsandtornado_cash.withdrawalsinto chain-specific models🧙 Author: @hildobby on 2023-04-14
📝 Summary: [changes too large] The model tornado_cash_withdrawals.sql was modified.
MODEL: tornado_cash_ethereum_deposits.sql
🟢 Added by:
🔧 PR: #3017, Split
tornado_cash.depositsandtornado_cash.withdrawalsinto chain-specific models🧙 Author: @hildobby on 2023-04-14
📝 Summary: [changes too large] The model tornado_cash_ethereum_deposits.sql was added.
MODEL: tornado_cash_ethereum_withdrawals.sql
🟢 Added by:
🔧 PR: #3017, Split
tornado_cash.depositsandtornado_cash.withdrawalsinto chain-specific models🧙 Author: @hildobby on 2023-04-14
📝 Summary: [changes too large] The model tornado_cash_ethereum_withdrawals.sql was added.
SECTOR: cow_protocol
MODEL: cow_protocol_ethereum_trade_slippage.sql
🟠 Modified by:
🔧 PR: #3187, [CoW] Trade Slippage for Partially Fillable Orders
🧙 Author: @bh2smith on 2023-04-17
📝 Summary: The SQL model calculates the fill proportion of a trade based on whether it is a buy or sell order. It then uses this to calculate the amount of atoms bought or sold, as well as the percentage and USD value of that amount. The logic for calculating these values has been updated to use the fill proportion instead of fixed amounts, resulting in more accurate calculations.
MODEL: cow_protocol_ethereum_assert_slippage.sql
🟢 Added by:
🔧 PR: #3187, [CoW] Trade Slippage for Partially Fillable Orders
🧙 Author: @bh2smith on 2023-04-17
📝 Summary: This SQL model creates a temporary table called 'test_1' that filters data from an existing table based on specific conditions. The filtered data is then selected and returned as the final output. This model enables analysts to easily filter and extract relevant information from large datasets for further analysis or reporting purposes.
SECTOR: onepunchswap
MODEL: onepunchswap_bnb_trades.sql
🟢 Added by:
🔧 PR: #3150, Add onepunchswap on bnb chain
🧙 Author: @sunopar on 2023-04-17
📝 Summary: This SQL model creates a table that enables data analysts to query and analyze trade events on the Onepunchswap decentralized exchange (DEX) for Binance Smart Chain. The table includes information such as the blockchain, project, version of DEX used, block date and time, token pair traded with their respective symbols and addresses, amount of tokens bought/sold in raw form as well as converted to decimals with corresponding USD value at the time of trade. It also includes transaction details such as hash values and trace address along with other relevant metadata.
SECTOR: bebop
MODEL: bebop_arbitrum_trades.sql
🟢 Added by:
🔧 PR: #3141, add bebop trades
🧙 Author: @B1boid on 2023-04-14
📝 Summary: This SQL model creates a view that enables data analysts to query and analyze trade data from the BebopAggregationContract_evt_AggregateOrderExecuted and BebopAggregationContract_call_SettleAggregateOrder sources on the Arbitrum blockchain. The view includes information such as block time, contract address, transaction hash, taker/maker addresses, token pairs traded with their respective amounts in both raw and converted USD values. It also joins with other tables to provide additional information about tokens (e.g., symbol) and prices (in USD).
MODEL: bebop_trades.sql
🟢 Added by:
🔧 PR: #3141, add bebop trades
🧙 Author: @B1boid on 2023-04-14
📝 Summary: This SQL model creates a union of three different trade tables from different blockchain networks (Polygon, Arbitrum, and Ethereum) into one table. This enables data analysts to easily query and analyze trades across multiple networks in a single table. The resulting table includes information such as token symbols, amounts bought/sold, USD value of the trade, addresses involved in the transaction and more.
MODEL: bebop_ethereum_trades.sql
🟢 Added by:
🔧 PR: #3141, add bebop trades
🧙 Author: @B1boid on 2023-04-14
📝 Summary: This SQL model creates a view that enables data analysts to query and analyze trade data from the BebopAggregationContract_evt_AggregateOrderExecuted and BebopAggregationContract_call_SettleAggregateOrder sources on Ethereum blockchain. The view includes information such as block time, contract address, transaction hash, taker/maker addresses, token pairs traded with their respective amounts in both raw and converted USD values. It also joins with other tables to provide additional details like token symbols/decimals/prices for each trade. This allows analysts to gain insights into trading patterns on the platform over time.
MODEL: bebop_polygon_trades.sql
🟢 Added by:
🔧 PR: #3141, add bebop trades
🧙 Author: @B1boid on 2023-04-14
📝 Summary: This SQL model creates a view that enables data analysts to query and analyze trade data on the Polygon blockchain. The view includes information such as block time, contract address, transaction hash, token pairs traded, amounts bought and sold in both raw and converted USD values. It also provides traceability of trades through their respective addresses. This model is designed to be used with an incremental update strategy but can also be run without one by specifying a project start date parameter.
Beta Was this translation helpful? Give feedback.
All reactions