fact_nft_transfers:

In this section, we will examine NFT transfers. For any transaction related to minting or sales, the transferred token information is accessible in the fact_receipts table. Within the logs of each transaction, two events, namely nft_transfer and nft_mint, can be identified. To select the appropriate receipt, its state must be one of the three states: SuccessValue, Failure, or SuccessReceiptId. This process enables us to retrieve all NFT transfers.

fact_native_transfers:

In every native transfer transaction, relevant information can be retrieved from the fact_actions_events table. The action_name should be Transfer, and the calculation of action_data:deposit is required. It's important to note that in certain exceptional transactions, this amount may not be numerical, leading to their exclusion. Overall, when compiling all transfer records, sorting is essential, and their USD price can be determined by multiplying the amount by the current NEAR token price.

fact_token_transfers:

Now, let's focus on token transfers (ft_transfers). It's crucial to acknowledge that some transactions may not be present in the receipts, necessitating data retrieval from the fact_actions_events_function_call. Retrieving these records involves filtering by the ft_transfer method and ensuring they are not duplicates by cross-referencing with previous sections. This approach prevents the inclusion of duplicate transactions and ensures the accuracy of the obtained data.

Moving on to the add_liquidity section, note that remove_liquidity has already been calculated in previous sections. Therefore, only add_liquidity transactions need separate calculations. In the logs of add_liquidity transactions, the key phrase "Liquidity added" should be identified. Extracting the token name, amount, and other relevant details is necessary. Notably, from_address is set to null to be computed in subsequent steps, reducing relational complexity and query load.

It is sufficient to retrieve the values, considering that two transfers have occurred. The initial part is obtained first, followed by the addition of the second token transfer in the same manner. Finally, consolidating these values through unions and subsequent adjustments in the USD price, from_address, and obtaining the final result.

Additionally, for transactions with the "order_added" event lacking an ft_transfer call method, the transfer amount is extracted from the Event Log Array.

Moreover, it's essential to acknowledge that some tokens lack pricing or decimal information in the dim_ft_contract_metadata table. Consequently, certain records may only have unadjusted amounts, lacking adjusted amounts and USD values due to the absence of decimals.