mirror of
https://github.com/FlipsideCrypto/flow-models.git
synced 2026-02-06 11:47:00 +00:00
AN-6423/docs update (#462)
* add overview * core and defi * cadence * evm * fix dim labels name * fix docs syntax
This commit is contained in:
Jack Forgash
GitHub
parent
de9b8f0c63
commit
84ca2eb298
@ -1,112 +1,165 @@
|
||||
{% docs __overview__ %}
|
||||
|
||||
# Welcome to the Flipside Crypto FLOW Models Documentation
|
||||
# Flipside Crypto FLOW Models Documentation
|
||||
|
||||
## **What does this documentation cover?**
|
||||
|
||||
The documentation included here details the design of the FLOW
|
||||
tables and views available via [Flipside Crypto.](https://flipsidecrypto.xyz/) For more information on how these models are built, please see [the github repository.](https://github.com/flipsideCrypto/flow-models/)
|
||||
|
||||
## **How do I use these docs?**
|
||||
|
||||
The easiest way to navigate this documentation is to use the Quick Links below. These links will take you to the documentation for each table, which contains a description, a list of the columns, and other helpful information.
|
||||
|
||||
If you are experienced with dbt docs, feel free to use the sidebar to navigate the documentation, as well as explore the relationships between tables and the logic building them.
|
||||
|
||||
There is more information on how to use dbt docs in the last section of this document.
|
||||
Welcome to the Flipside Crypto FLOW models! This documentation provides a comprehensive overview of the data models, tables, and views available for the Flow blockchain and related ecosystems, as curated and maintained by Flipside Crypto. These models are designed to support deep analytics, protocol research, and data-driven insights for developers, analysts, and the broader Flow community. The models follow a layered architecture (bronze, silver, gold) to ensure data quality, traceability, and performance, and are built using dbt best practices for modularity and transparency.
|
||||
|
||||
## **Quick Links to Table Documentation**
|
||||
|
||||
**Click on the links below to jump to the documentation for each schema.**
|
||||
|
||||
### Beta Tables (`FLOW`.`BETA`.`<table_name>`)
|
||||
### Beta Tables
|
||||
**Dimension Tables:**
|
||||
- [beta__dim_nfl_athletes](#!/model/model.flow_models.beta__dim_nfl_athletes)
|
||||
- [beta__dim_nfl_teams](#!/model/model.flow_models.beta__dim_nfl_teams)
|
||||
- [beta__dim_nflad_playoff_rosters](#!/model/model.flow_models.beta__dim_nflad_playoff_rosters)
|
||||
**Easy Views:**
|
||||
- [beta__ez_moment_player_ids](#!/model/model.flow_models.beta__ez_moment_player_ids)
|
||||
|
||||
- [ez_nft_topshot_packs](#!/model/model.flow_models.beta__ez_nft_topshot_packs)
|
||||
### Core Tables
|
||||
**Dimension Tables:**
|
||||
- [core__dim_address_mapping](#!/model/model.flow_models.core__dim_address_mapping)
|
||||
- [core__dim_contract_labels](#!/model/model.flow_models.core__dim_contract_labels)
|
||||
- [core__dim_labels](#!/model/model.flow_models.core__dim_labels)
|
||||
**Fact Tables:**
|
||||
- [core__fact_blocks](#!/model/model.flow_models.core__fact_blocks)
|
||||
- [core__fact_events](#!/model/model.flow_models.core__fact_events)
|
||||
- [core__fact_transactions](#!/model/model.flow_models.core__fact_transactions)
|
||||
**Easy Views:**
|
||||
- [core__ez_token_transfers](#!/model/model.flow_models.core__ez_token_transfers)
|
||||
- [core__ez_transaction_actors](#!/model/model.flow_models.core__ez_transaction_actors)
|
||||
|
||||
### Core Tables (`flow`.`CORE`.`<table_name>`)
|
||||
### DeFi Tables
|
||||
**Dimension Tables:**
|
||||
- [defi__dim_swap_pool_labels](#!/model/model.flow_models.defi__dim_swap_pool_labels)
|
||||
**Fact Tables:**
|
||||
- [defi__fact_bridge_activity](#!/model/model.flow_models.defi__fact_bridge_activity)
|
||||
- [defi__fact_dex_swaps](#!/model/model.flow_models.defi__fact_dex_swaps)
|
||||
**Easy Views:**
|
||||
- [defi__ez_bridge_activity](#!/model/model.flow_models.defi__ez_bridge_activity)
|
||||
- [defi__ez_dex_swaps](#!/model/model.flow_models.defi__ez_dex_swaps)
|
||||
|
||||
- [dim_contract_labels](#!/model/model.flow_models.core__dim_contract_labels)
|
||||
- [ez_token_transfers](#!/model/model.flow_models.core__ez_token_transfers)
|
||||
- [fact_blocks](#!/model/model.flow_models.core__fact_blocks)
|
||||
- [fact_events](#!/model/model.flow_models.core__fact_events)
|
||||
- [fact_transactions](#!/model/model.flow_models.core__fact_transactions)
|
||||
### NFT Tables
|
||||
**Dimension Tables:**
|
||||
- [nft__dim_allday_metadata](#!/model/model.flow_models.nft__dim_allday_metadata)
|
||||
- [nft__dim_moment_metadata](#!/model/model.flow_models.nft__dim_moment_metadata)
|
||||
- [nft__dim_topshot_metadata](#!/model/model.flow_models.nft__dim_topshot_metadata)
|
||||
- [nft__dim_ufc_strike_metadata](#!/model/model.flow_models.nft__dim_ufc_strike_metadata)
|
||||
**Fact Tables:**
|
||||
- [nft__fact_topshot_buybacks](#!/model/model.flow_models.nft__fact_topshot_buybacks)
|
||||
**Easy Views:**
|
||||
- [nft__ez_nft_sales](#!/model/model.flow_models.nft__ez_nft_sales)
|
||||
|
||||
### DeFi Tables (`flow`.`DEFI`.`<table_name>`)
|
||||
### Price Tables
|
||||
**Dimension Tables:**
|
||||
- [price__dim_asset_metadata](#!/model/model.flow_models.price__dim_asset_metadata)
|
||||
**Fact Tables:**
|
||||
- [price__fact_prices_ohlc_hourly](#!/model/model.flow_models.price__fact_prices_ohlc_hourly)
|
||||
**Easy Views:**
|
||||
- [price__ez_asset_metadata](#!/model/model.flow_models.price__ez_asset_metadata)
|
||||
- [price__ez_prices_hourly](#!/model/model.flow_models.price__ez_prices_hourly)
|
||||
|
||||
- [dim_swap_pool_labels](#!/model/model.flow_models.defi__dim_swap_pool_labels)
|
||||
- [ez_bridge_transactions](#!/model/model.flow_models.defi__ez_bridge_transactions)
|
||||
- [ez_swaps](#!/model/model.flow_models.defi__ez_swaps)
|
||||
### Governance Tables
|
||||
**Dimension Tables:**
|
||||
- [gov__dim_validator_labels](#!/model/model.flow_models.gov__dim_validator_labels)
|
||||
**Easy Views:**
|
||||
- [gov__ez_staking_actions](#!/model/model.flow_models.gov__ez_staking_actions)
|
||||
|
||||
### Governance Tables (`flow`.`GOV`.`<table_name>`)
|
||||
### Rewards Tables
|
||||
**Dimension Tables:**
|
||||
- [rewards__dim_storefront_items](#!/model/model.flow_models.rewards__dim_storefront_items)
|
||||
**Fact Tables:**
|
||||
- [rewards__fact_points_balances](#!/model/model.flow_models.rewards__fact_points_balances)
|
||||
- [rewards__fact_points_transfers](#!/model/model.flow_models.rewards__fact_points_transfers)
|
||||
- [rewards__fact_transaction_entries](#!/model/model.flow_models.rewards__fact_transaction_entries)
|
||||
|
||||
- [dim_validator_labels](#!/model/model.flow_models.gov__dim_validator_labels)
|
||||
- [ez_staking_actions](#!/model/model.flow_models.gov__ez_staking_actions)
|
||||
|
||||
### NFT Tables (`flow`.`NFT`.`<table_name>`)
|
||||
|
||||
- [dim_allday_metadata](#!/model/model.flow_models.nft__dim_allday_metadata)
|
||||
- [dim_moment_metadata](#!/model/model.flow_models.nft__dim_moment_metadata)
|
||||
- [dim_topshot_metadata](#!/model/model.flow_models.nft__dim_topshot_metadata)
|
||||
- [ez_nft_sales](#!/model/model.flow_models.nft__ez_nft_sales)
|
||||
|
||||
### Price Tables (`flow`.`PRICE`.`<table_name>`)
|
||||
|
||||
- [fact_hourly_prices](#!/model/model.flow_models.price__fact_hourly_prices)
|
||||
- [fact_prices](#!/model/model.flow_models.price__fact_prices)
|
||||
|
||||
### Stats Tables (flow.stats)
|
||||
|
||||
- [ez_core_metrics_hourly](#!/model/model.flow_models.stats__ez_core_metrics_hourly)
|
||||
|
||||
### EVM Tables (`flow.core_evm`)
|
||||
### Stats Tables
|
||||
**Easy Views:**
|
||||
- [stats__ez_core_metrics_hourly](#!/model/model.flow_models.stats__ez_core_metrics_hourly)
|
||||
|
||||
### EVM Tables
|
||||
**Dimension Tables:**
|
||||
- [core_evm__dim_contracts](#!/model/model.flow_models.core_evm__dim_contracts)
|
||||
- [core_evm__dim_labels](#!/model/model.flow_models.core_evm__dim_labels)
|
||||
- [core_evm__dim_contract_abis](#!/model/model.flow_models.core_evm__dim_contract_abis)
|
||||
**Fact Tables:**
|
||||
- [core_evm__fact_blocks](#!/model/model.flow_models.core_evm__fact_blocks)
|
||||
- [core_evm__fact_event_logs](#!/model/model.flow_models.core_evm__fact_event_logs)
|
||||
- [core_evm__fact_traces](#!/model/model.flow_models.core_evm__fact_traces)
|
||||
- [core_evm__fact_blocks](#!/model/model.flow_models.core_evm__fact_blocks)
|
||||
- [core_evm__fact_transactions](#!/model/model.flow_models.core_evm__fact_transactions)
|
||||
- [core_evm__ez_native_transfers](#!/model/model.flow_models.core_evm__ez_native_transfers)
|
||||
**Easy Views:**
|
||||
- [core_evm__ez_token_transfers](#!/model/model.flow_models.core_evm__ez_token_transfers)
|
||||
- [core_evm__ez_native_transfers](#!/model/model.flow_models.core_evm__ez_native_transfers)
|
||||
- [core_evm__ez_decoded_event_logs](#!/model/model.flow_models.core_evm__ez_decoded_event_logs)
|
||||
|
||||
## **Data Model Overview**
|
||||
---
|
||||
|
||||
The FLOW
|
||||
models are built a few different ways, but the core fact tables are built using three layers of sql models: **bronze, silver, and gold (or core).**
|
||||
## Data Model Overview
|
||||
|
||||
- Bronze: Data is loaded in from the source as a view
|
||||
- Silver: All necessary parsing, filtering, de-duping, and other transformations are done here
|
||||
- Gold (or core): Final views and tables that are available publicly
|
||||
The FLOW models are organized in a layered architecture:
|
||||
- **Bronze**: Raw data ingested from the blockchain or external sources, minimally processed.
|
||||
- **Silver**: Cleaned, parsed, and enriched data, with deduplication and normalization applied.
|
||||
- **Gold**: Final, analytics-ready tables and views, including core facts, dimensions, and curated "ez" views for common use cases.
|
||||
|
||||
The dimension tables are sourced from a variety of on-chain and off-chain sources.
|
||||
Dimension tables (`dim_`) provide reference data and entity mappings. Fact tables (`fact_`) record core blockchain events and transactions. Easy views (`ez_`) combine facts and dimensions for simplified analytics.
|
||||
|
||||
Convenience views (denoted ez\_) are a combination of different fact and dimension tables. These views are built to make it easier to query the data.
|
||||
|
||||
## **Using dbt docs**
|
||||
|
||||
### Navigation
|
||||
|
||||
You can use the `Project` and `Database` navigation tabs on the left side of the window to explore the models in the project.
|
||||
|
||||
### Database Tab
|
||||
|
||||
This view shows relations (tables and views) grouped into database schemas. Note that ephemeral models are _not_ shown in this interface, as they do not exist in the database.
|
||||
|
||||
### Graph Exploration
|
||||
|
||||
You can click the blue icon on the bottom-right corner of the page to view the lineage graph of your models.
|
||||
|
||||
On model pages, you'll see the immediate parents and children of the model you're exploring. By clicking the Expand button at the top-right of this lineage pane, you'll be able to see all of the models that are used to build, or are built from, the model you're exploring.
|
||||
|
||||
Once expanded, you'll be able to use the `--models` and `--exclude` model selection syntax to filter the models in the graph. For more information on model selection, check out the [dbt docs](https://docs.getdbt.com/docs/model-selection-syntax).
|
||||
|
||||
Note that you can also right-click on models to interactively filter and explore the graph.
|
||||
|
||||
### **More information**
|
||||
|
||||
- [Flipside](https://flipsidecrypto.xyz/)
|
||||
- [Velocity](https://app.flipsidecrypto.com/velocity?nav=Discover)
|
||||
- [Tutorials](https://docs.flipsidecrypto.com/our-data/tutorials)
|
||||
- [Github](https://github.com/FlipsideCrypto/flow-models)
|
||||
- [What is dbt?](https://docs.getdbt.com/docs/introduction)
|
||||
<llm>
|
||||
<blockchain>Flow</blockchain>
|
||||
<aliases>FLOW</aliases>
|
||||
<ecosystem>Layer 1, Cadence</ecosystem>
|
||||
<description>Flow is a high-throughput, developer-friendly Layer 1 blockchain designed for consumer applications, NFTs, and gaming. It uses a unique multi-role architecture and Cadence smart contract language to optimize for scalability and usability. Flow powers major NFT projects (NBA Top Shot, NFL All Day) and supports both native and EVM-compatible assets via bridges. Its architecture enables fast, low-cost transactions and a rich ecosystem for developers and users.</description>
|
||||
<external_resources>
|
||||
<block_scanner>https://flowscan.org/</block_scanner>
|
||||
<developer_documentation>https://developers.flow.com/</developer_documentation>
|
||||
</external_resources>
|
||||
<expert>
|
||||
<constraints>
|
||||
<table_availability>
|
||||
Use only tables and schemas listed in the Quick Links section for Flow analytics.
|
||||
</table_availability>
|
||||
<schema_structure>
|
||||
Gold models are organized by schema (core, defi, nft, etc.) and type (dim_, fact_, ez_). EVM models are in the core_evm schema.
|
||||
</schema_structure>
|
||||
</constraints>
|
||||
<optimization>
|
||||
<performance_filters>
|
||||
Filter by block_timestamp or date fields for efficient queries. Use indexed columns for large tables.
|
||||
</performance_filters>
|
||||
<query_structure>
|
||||
Prefer CTEs for readability. Avoid deeply nested subqueries. Use incremental logic for large models.
|
||||
</query_structure>
|
||||
<implementation_guidance>
|
||||
Use window functions and aggregations judiciously. Leverage clustering and partitioning for performance.
|
||||
</implementation_guidance>
|
||||
</optimization>
|
||||
<domain_mapping>
|
||||
<token_operations>
|
||||
Use core__ez_token_transfers for Flow native and bridged token transfers. For EVM, use core_evm__ez_token_transfers.
|
||||
</token_operations>
|
||||
<defi_analysis>
|
||||
Use defi__ez_bridge_activity and defi__ez_dex_swaps for DeFi analytics. EVM DeFi is not natively supported on Flow.
|
||||
</defi_analysis>
|
||||
<nft_analysis>
|
||||
Use nft__ez_nft_sales and nft__dim_allday_metadata for NFT analytics. Flow is a leading NFT chain.
|
||||
</nft_analysis>
|
||||
<specialized_features>
|
||||
Flow's Cadence language and multi-role architecture are unique. EVM compatibility is via bridge only.
|
||||
</specialized_features>
|
||||
</domain_mapping>
|
||||
<interaction_modes>
|
||||
<direct_user>
|
||||
Ask clarifying questions for complex analytics or cross-chain queries.
|
||||
</direct_user>
|
||||
<agent_invocation>
|
||||
When invoked by another agent, respond with relevant SQL or model references.
|
||||
</agent_invocation>
|
||||
</interaction_modes>
|
||||
<engagement>
|
||||
<exploration_tone>
|
||||
Have fun exploring the Flow ecosystem and its rich data landscape!
|
||||
</exploration_tone>
|
||||
</engagement>
|
||||
</expert>
|
||||
</llm>
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
{% docs action %}
|
||||
|
||||
The action occurring in this record, as derived from `event_type` in the transaction.
|
||||
The specific action or operation occurring in this record, as derived from the event_type in the transaction. Data type: STRING. This field describes the type of staking operation being performed, such as delegation, undelegation, or reward collection. Used for staking operation analysis, transaction categorization, and governance tracking. Example: 'delegate' for delegation actions, 'undelegate' for undelegation actions, 'collect_rewards' for reward collection actions. Critical for understanding staking behavior, governance participation, and maintaining accurate transaction categorization in the Flow staking ecosystem.
|
||||
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,3 @@
|
||||
{% docs address %}
|
||||
|
||||
The on-chain address. See more in the Flow docs on accounts and addresses: https://developers.flow.com/build/basics/accounts and https://developers.flow.com/evm/accounts
|
||||
|
||||
The unique on-chain address representing an account or contract on the Flow blockchain. Data type: STRING. Addresses are used to identify participants, contracts, and assets in all Flow transactions and events. Example: '0x1cf0e2f2f715450'. Used for joins, analytics, and entity mapping. For more details, see [Flow Accounts and Addresses](https://developers.flow.com/build/basics/accounts).
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,5 @@
|
||||
{% docs amount %}
|
||||
|
||||
Number of points transferred in the transaction.
|
||||
The quantity of points, tokens, or assets transferred in the transaction. Data type: NUMBER (decimal adjusted). This field represents the amount moved between accounts, earned through activities, or spent on rewards. Used for financial analysis, volume tracking, reward program analytics, and transaction value calculations. Example: 100.0 for 100 reward points, 50.5 for 50.5 Flow tokens. Critical for reward program performance analysis, user engagement tracking, and maintaining accurate transaction records.
|
||||
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,5 @@
|
||||
{% docs amount_end %}
|
||||
|
||||
Ending balance of the loyalty account after the transaction.
|
||||
The ending balance of the loyalty account after the transaction was processed. Data type: NUMBER (decimal adjusted). This field represents the account balance at the conclusion of the transaction and is used for balance verification and audit trails. Used for transaction validation, balance reconciliation, and understanding account state changes. Example: 1100.0 for an account ending with 1100 reward points after earning 100 points. Critical for maintaining data integrity, audit compliance, and accurate balance tracking in the rewards system.
|
||||
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,3 @@
|
||||
{% docs amount_fee %}
|
||||
|
||||
The fee taken by the protocol or contract as part of the transaction.
|
||||
|
||||
The fee amount deducted by the protocol, bridge, or contract as part of the transaction. Data type: NUMBER (decimal adjusted). Represents the cost paid by the user for using the service (e.g., bridge fee). Example: 0.1 (for 0.1 Flow tokens). Used for fee analysis, cost tracking, and protocol revenue analytics.
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,3 @@
|
||||
{% docs amount_fee_usd %}
|
||||
|
||||
Amount denominated in USD, where pricing data is available.
|
||||
|
||||
The value of the fee amount denominated in US dollars, based on available pricing data at the time of the transaction. Data type: NUMBER (decimal adjusted). Used for cost analysis, protocol revenue tracking, and financial reporting. Example: 0.25 (for $0.25 USD). Important for fee analytics and dashboards.
|
||||
{% enddocs %}
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
{% docs amount_start %}
|
||||
|
||||
Starting balance of the loyalty account before the transaction.
|
||||
The starting balance of the loyalty account before the transaction was processed. Data type: NUMBER (decimal adjusted). This field represents the account balance at the beginning of the transaction and is used for balance verification and audit trails. Used for transaction validation, balance reconciliation, and understanding account state changes. Example: 1000.0 for an account starting with 1000 reward points. Critical for maintaining data integrity, audit compliance, and accurate balance tracking in the rewards system.
|
||||
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,5 @@
|
||||
{% docs amount_usd %}
|
||||
|
||||
Amount denominated in USD, where pricing data is available.
|
||||
The value of the amount field denominated in US dollars, based on available pricing data at the time of the transaction. Data type: NUMBER (decimal adjusted). Used for financial analysis, protocol revenue tracking, and cross-chain comparisons. Example: 100.25 (for $100.25 USD). This field is essential for normalizing value across different tokens and blockchains, enabling USD-based analytics and dashboards. Important for DeFi analytics, cost analysis, and protocol performance measurement.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
{% docs arguments %}
|
||||
|
||||
The arguments passed into the Cadence script when the transaction was submitted.
|
||||
|
||||
The parameters or values passed into the Cadence script when the transaction was submitted. Data type: ARRAY<STRING> or STRING (JSON-encoded). Arguments customize the behavior of the script, enabling dynamic contract interactions. Used for auditing, debugging, and analyzing transaction intent. Example: ['0x1cf0e2f2f715450', 100]. Important for understanding how smart contracts are invoked and parameterized on Flow.
|
||||
{% enddocs %}
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
{% docs authorizers %}
|
||||
|
||||
Address(es) authorizing the transaction.
|
||||
|
||||
A list of Flow addresses that authorized the transaction. Data type: ARRAY<STRING> or STRING (comma-separated). Authorizers are accounts whose keys are required to sign the transaction, enabling multi-party authorization. This field is used to analyze participant roles, multi-sig patterns, and access control in Flow's transaction model. Example: ['0x1cf0e2f2f715450', '0x2a2e1b2c3d4e5f6']. Important for understanding transaction security and collaborative workflows.
|
||||
{% enddocs %}
|
||||
@ -1,6 +1,4 @@
|
||||
|
||||
{% docs block_height %}
|
||||
|
||||
The block height the block was recorded at.
|
||||
|
||||
Block height is the unique, sequential integer assigned to each block as it is added to the Flow blockchain. It serves as the primary identifier for block ordering and is used to reference the position of a block within the chain. Data type: INTEGER. Block height is essential for joining block, transaction, and event tables, and for analyzing blockchain growth over time. For example, block height 100,000 refers to the 100,000th block produced on Flow. This field is critical for time-series analytics, chain reorganization analysis, and historical state reconstruction.
|
||||
{% enddocs %}
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
{% docs block_timestamp %}
|
||||
|
||||
The date and time for when the block was written.
|
||||
|
||||
The timestamp (in UTC) when the block or transaction was recorded on the Flow blockchain. Data type: TIMESTAMP_NTZ. This field is essential for time-series analysis, ordering events, and joining with other tables by time. For example, a block with block_height 100,000 may have a block_timestamp of '2023-01-01 12:00:00'. Used for analytics on network activity, transaction throughput, and historical state reconstruction.
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,5 @@
|
||||
{% docs blockchain %}
|
||||
|
||||
The name of the blockchain for this address or transaction.
|
||||
The name of the blockchain network involved in the transaction or address. Data type: STRING. This field is used to distinguish between different blockchains (e.g., 'flow', 'ethereum', 'polygon') in cross-chain analytics, bridge activity, and multi-chain protocols. It is essential for filtering, aggregating, and attributing activity to the correct network, especially in bridge and DeFi models where assets may move between chains. Example: 'flow' for native Flow transactions, 'ethereum' for bridged assets. Important for cross-chain analytics, protocol attribution, and ensuring accurate data segmentation in multi-chain environments.
|
||||
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,5 @@
|
||||
{% docs bridge %}
|
||||
|
||||
The name of the bridge or protocol used.
|
||||
The name of the bridge protocol or service used to transfer tokens or assets between blockchains. Data type: STRING. This field identifies the specific bridge (e.g., 'blocto', 'celer') facilitating the cross-chain transfer. Used for protocol attribution, analytics, and filtering bridge activity. Example: 'blocto' for Blocto Teleport, 'celer' for Celer Bridge. Important for cross-chain analytics, protocol usage tracking, and understanding the flow of assets between networks.
|
||||
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,3 @@
|
||||
{% docs bridge_contract %}
|
||||
|
||||
The contract address for the bridge used to move tokens to or from Flow.
|
||||
|
||||
The Flow contract address for the bridge protocol used to transfer tokens to or from the Flow blockchain. Data type: STRING. Identifies the specific bridge (e.g., Blocto Teleport, Celer) facilitating cross-chain transfers. Used for protocol attribution, analytics, and filtering bridge activity. Example: '0xabcdef1234567890'. Important for cross-chain analytics and monitoring bridge usage.
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,3 @@
|
||||
{% docs chain_id %}
|
||||
|
||||
The id for the chain of the network on which this block occurred.
|
||||
|
||||
The unique identifier for the blockchain network (chain) where the block or transaction was recorded. Data type: STRING. On Flow, this value distinguishes between different network deployments (e.g., mainnet, testnet). Used for cross-network analytics and ensuring data integrity when working with multiple environments. Example: 'flow-mainnet' or 'flow-testnet'.
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,3 @@
|
||||
{% docs contract_name %}
|
||||
|
||||
The primary name of the contract, derived from the full contract address.
|
||||
|
||||
The primary name assigned to a smart contract on the Flow blockchain, typically derived from the contract's deployment address. Data type: STRING. Used for identifying, filtering, and joining contract metadata. Example: 'FlowToken', 'TopShot'. Important for contract-level analytics, entity mapping, and dashboarding.
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,5 @@
|
||||
{% docs created_at %}
|
||||
|
||||
Timestamp when the transaction entry was created.
|
||||
The timestamp when the transaction entry was created in the rewards system. Data type: TIMESTAMP. This field provides the temporal reference for when the reward transaction occurred and is used for chronological analysis and audit trails. Used for transaction timing analysis, reward distribution tracking, and temporal data aggregation. Example: '2024-01-15 14:30:25' for a transaction created on January 15, 2024 at 2:30:25 PM. Critical for time-series analysis, reward program performance tracking, and maintaining accurate transaction timelines.
|
||||
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,5 @@
|
||||
{% docs delegator %}
|
||||
|
||||
The Flow account address for the wallet delegating to a node. This is derived from the first authorizer on the transaction and may be inaccurate if the transaction was signed by an EOA. Refer to delegator_id as the unique identifier for the delegator, taken directly from the emitted event data.
|
||||
The Flow account address for the wallet delegating stake to a validator node. Data type: STRING. This field represents the address of the account that is delegating FLOW tokens to a validator node for staking operations. Used for delegator identification, staking analysis, and governance operations. Example: '0x1234567890abcdef' for a specific delegator account address. Note: This is derived from the first authorizer on the transaction and may be inaccurate if the transaction was signed by an EOA. Refer to delegator_id as the unique identifier for the delegator, taken directly from the emitted event data.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
{% docs direction %}
|
||||
|
||||
Direction of the points transfer (e.g., debit or credit).
|
||||
The direction of the points transfer indicating whether points are being added or removed from an account. Data type: STRING. This field specifies whether the transaction represents a credit (points earned) or debit (points spent) operation in the rewards system. Used for understanding reward flows, calculating net point changes, and analyzing reward program participation. Example: 'credit' for points earned through activities, 'debit' for points spent on rewards or transfers. Critical for reward program analytics, user engagement tracking, and maintaining accurate point balance calculations.
|
||||
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,5 @@
|
||||
{% docs entry_id %}
|
||||
|
||||
Unique identifier for the transaction entry record.
|
||||
The unique identifier for the transaction entry record within the rewards system. Data type: STRING. This field serves as the primary key for identifying individual transaction entries in the rewards points system. Used for tracking specific reward transactions, maintaining referential integrity, and enabling detailed transaction analysis. Example: 'entry_12345' for a specific points transfer entry. Critical for transaction tracking, audit trails, and maintaining data consistency in the rewards analytics system.
|
||||
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,3 @@
|
||||
{% docs event_contract %}
|
||||
|
||||
The contract called for this event. This is equivalent to the Contract column on Flowscan and is a concatenation of the contract's account address and primary name.
|
||||
|
||||
The Flow contract that emitted the event. Data type: STRING. This value is a concatenation of the contract's account address and its primary name (e.g., 'A.0ae53cb6e3f42a79.FlowToken'). Used for identifying the source of events, joining with contract metadata, and analyzing contract activity. Example: 'A.0ae53cb6e3f42a79.FlowToken'. Equivalent to the 'Contract' column on Flowscan.
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,3 @@
|
||||
{% docs event_data %}
|
||||
|
||||
The raw event data from the event.
|
||||
|
||||
The raw payload or data emitted by the event during transaction execution. Data type: STRING (JSON-encoded or structured). This field contains event-specific information such as addresses, amounts, or custom fields defined in the contract. Used for auditing, analytics, and extracting business logic from on-chain activity. Example: '{"amount": "100.0", "to": "0x1cf0e2f2f715450"}'. Essential for event-driven analytics and contract monitoring.
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,3 @@
|
||||
{% docs event_index %}
|
||||
|
||||
The index of the event within the transaction, i.e. in what order the events occurred.
|
||||
|
||||
The zero-based position of the event within the list of events emitted by a transaction. Data type: INTEGER. This field indicates the order in which events occurred during transaction execution. Used for reconstructing event sequences, debugging, and analyzing event-driven workflows. Example: 0 (first event), 1 (second event), etc. Important for event ordering and traceability.
|
||||
{% enddocs %}
|
||||
@ -1,6 +1,3 @@
|
||||
{% docs event_type %}
|
||||
|
||||
The type of method called on the event_contract. In the fact_events table, this represents the method called on a contract. This may also reference the full user-defined event type from the event object. See more on this in the Flow docs: https://developers.flow.com/build/basics/events#user-defined-events.
|
||||
|
||||
|
||||
The name or identifier of the event emitted by a contract during transaction execution. Data type: STRING. In the `fact_events` table, this field represents the user-defined or system event type, such as 'A.0ae53cb6e3f42a79.FlowToken.TokensDeposited'. Used for filtering, categorizing, and analyzing on-chain events. Example: 'A.0ae53cb6e3f42a79.FlowToken.TokensWithdrawn'. For more details, see [Flow User-Defined Events](https://developers.flow.com/build/basics/events#user-defined-events).
|
||||
{% enddocs %}
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
{% docs flow_wallet_address %}
|
||||
|
||||
Address of a FLOW wallet related to the transaction.
|
||||
|
||||
The Flow blockchain address of a wallet involved in the transaction (as sender, recipient, source, or destination). Data type: STRING. Used to identify participants in token transfers, swaps, or bridge activity. Example: '0x1cf0e2f2f715450'. Important for wallet attribution, cross-chain analytics, and user-level tracking.
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,3 @@
|
||||
{% docs gas_limit %}
|
||||
|
||||
Upper gas limit attached to the transaction.
|
||||
|
||||
The maximum amount of computational resources (gas) allocated for executing the transaction on the Flow blockchain. Data type: INTEGER. If the transaction exceeds this limit, it will fail. This field is used to analyze resource usage, transaction costs, and execution constraints. Example: 1000. Important for understanding transaction execution, fee estimation, and optimizing smart contract operations.
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,3 @@
|
||||
{% docs id %}
|
||||
|
||||
The block hash.
|
||||
|
||||
A unique identifier for the record. In the context of blocks, this is the block hash—a cryptographic string that uniquely identifies a block on the Flow blockchain. Data type: STRING. Used for verifying block integrity, referencing blocks in other tables, and supporting chain reorganization analysis. Example: 'a1b2c3d4...'. For other models, 'id' may refer to a unique row identifier.
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,3 @@
|
||||
{% docs inserted_timestamp %}
|
||||
|
||||
The timestamp at which the record was initially created and inserted into this table.
|
||||
|
||||
The UTC timestamp when the record was first created and inserted into this table. Data type: TIMESTAMP_NTZ. Used for ETL auditing, tracking data freshness, and identifying when data was loaded or updated in the analytics pipeline. Example: '2023-01-01 12:00:00'. This field is critical for monitoring data latency, troubleshooting ETL issues, and supporting recency tests in dbt.
|
||||
{% enddocs %}
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
{% docs label %}
|
||||
|
||||
The label for this address.
|
||||
|
||||
A human-readable name or tag assigned to an address, contract, or entity for identification and analytics. Data type: STRING. Labels provide context such as project names, exchange names, or protocol identifiers. Used for dashboards, segmentation, and entity-level reporting. Example: 'Blocto', 'NBA Top Shot', 'Flow Foundation'. Important for making blockchain data more interpretable and actionable.
|
||||
{% enddocs %}
|
||||
|
||||
3
models/descriptions/label_created.md
Normal file
3
models/descriptions/label_created.md
Normal file
@ -0,0 +1,3 @@
|
||||
{% docs label_created %}
|
||||
The UTC timestamp when the label for an address, contract, or entity was first created or assigned. Data type: TIMESTAMP_NTZ. Used for auditing label history, analyzing label adoption, and supporting lifecycle analysis. Example: '2022-12-15 09:00:00'. Important for understanding when an entity was first classified and for historical analytics.
|
||||
{% enddocs %}
|
||||
3
models/descriptions/label_last_updated.md
Normal file
3
models/descriptions/label_last_updated.md
Normal file
@ -0,0 +1,3 @@
|
||||
{% docs label_last_updated %}
|
||||
The UTC timestamp when the label for an address, contract, or entity was most recently updated. Data type: TIMESTAMP_NTZ. Used for tracking label recency, auditing changes, and supporting freshness analysis in dashboards and dbt tests. Example: '2023-01-05 10:00:00'. Important for monitoring label lifecycle and ensuring up-to-date entity classification.
|
||||
{% enddocs %}
|
||||
3
models/descriptions/label_priority.md
Normal file
3
models/descriptions/label_priority.md
Normal file
@ -0,0 +1,3 @@
|
||||
{% docs label_priority %}
|
||||
A numeric or categorical value indicating the precedence of a label when multiple labels are assigned to the same address, contract, or entity. Data type: INTEGER or STRING. Higher priority labels are preferred for analytics and reporting. Used for conflict resolution, deduplication, and ensuring consistent labeling. Example: 1 (highest priority), 2, 3, etc. Important for maintaining data quality and clarity in dashboards.
|
||||
{% enddocs %}
|
||||
3
models/descriptions/label_source.md
Normal file
3
models/descriptions/label_source.md
Normal file
@ -0,0 +1,3 @@
|
||||
{% docs label_source %}
|
||||
The origin or provenance of the label assigned to an address, contract, or entity. Data type: STRING. Indicates whether the label was assigned by Flipside, a community contributor, an external provider, or derived from on-chain data. Used for auditing, trust assessment, and understanding label reliability. Example: 'Flipside', 'Community', 'On-chain'. Important for data quality and transparency in analytics.
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,3 @@
|
||||
{% docs label_subtype %}
|
||||
|
||||
The type of address, within the higher order label_type, such as hot wallet, deposit wallet, validator, etc.
|
||||
|
||||
A more granular classification within the primary `label_type`, specifying the role or function of the address or contract (e.g., 'hot wallet', 'deposit wallet', 'validator', 'marketplace'). Data type: STRING. Used for detailed segmentation, filtering, and analytics. Example: 'hot wallet' under 'CEX', or 'validator' under 'Operator'. Important for fine-grained entity analysis and reporting.
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,3 @@
|
||||
{% docs label_type %}
|
||||
|
||||
Predominant label categorization, such as CEX, Operator, NFT, etc.
|
||||
|
||||
The primary category or classification assigned to an address, contract, or entity (e.g., 'CEX', 'Operator', 'NFT', 'DeFi', 'Game'). Data type: STRING. Used for grouping, filtering, and analyzing entities by type in dashboards and reports. Example: 'CEX' for centralized exchanges, 'NFT' for non-fungible token contracts. Important for segmentation and entity-level analytics.
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,5 @@
|
||||
{% docs metadata %}
|
||||
|
||||
A JSON object containing moment or play metadata.
|
||||
A JSON object containing comprehensive metadata for the NFT moment or play. Data type: OBJECT/VARIANT. This field stores detailed information about the NFT including play details, statistics, video URLs, and other descriptive data. Used for rich NFT analysis, content discovery, and detailed moment information retrieval. Example: Contains play statistics, video links, game context, and other moment-specific details. Important for comprehensive NFT analysis, content discovery, and providing rich context for NFT transactions and analytics.
|
||||
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,3 @@
|
||||
{% docs modified_timestamp %}
|
||||
|
||||
The timestamp at which this record was last modified by an internal process.
|
||||
|
||||
The UTC timestamp when this record was last updated or modified by an internal ETL or dbt process. Data type: TIMESTAMP_NTZ. Used for change tracking, ETL auditing, and identifying the most recent update to a record. Example: '2023-01-02 15:30:00'. This field is important for troubleshooting data issues, monitoring pipeline health, and supporting recency or freshness tests in dbt.
|
||||
{% enddocs %}
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
{% docs moment_description %}
|
||||
|
||||
Long-form description of the play, from NBA TopShot.
|
||||
A detailed, long-form description of the play or moment captured in the NFT. Data type: STRING. This field provides a comprehensive narrative description of the sports play, including context, key details, and notable aspects of the moment. Used for content discovery, play identification, and providing rich context for NFT analysis. Example: 'LeBron James hits a game-winning three-pointer with 2.1 seconds remaining in the fourth quarter.' Important for content discovery, play identification, and providing rich context for NFT transactions and analytics.
|
||||
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,5 @@
|
||||
{% docs nbatopshot_id %}
|
||||
|
||||
The ID used by NBA TopShot. This can be pasted into the URL https://nbatopshot.com/moment/{nbatopshot_id} to view the moment on the marketplace.
|
||||
The unique identifier used by NBA TopShot for the moment. Data type: STRING. This field provides the official NBA TopShot identifier for the moment, enabling direct linking to the marketplace and cross-referencing with external NBA TopShot data. Used for marketplace integration, external data joins, and direct user navigation to moments. Example: Can be used in URL https://nbatopshot.com/moment/{nbatopshot_id} to view the moment on the marketplace. Important for marketplace integration, external data correlation, and user experience features.
|
||||
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,3 @@
|
||||
{% docs network %}
|
||||
|
||||
The blockchain network the block or transaction occurred on.
|
||||
|
||||
The name of the blockchain network where the block or transaction was recorded. Data type: STRING. For Flow, this typically indicates the environment (e.g., 'mainnet', 'testnet', 'sandboxnet'). This field is important for distinguishing between production and test data, and for multi-network analytics. Example: 'mainnet'.
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,3 @@
|
||||
{% docs network_version %}
|
||||
|
||||
The version of the Blockchain that cooresponds with the block height. For more information on Flow's network upgrades (Sporks), see https://developers.flow.com/nodes/node-operation/spork
|
||||
|
||||
The version identifier of the Flow blockchain network at the time the block was produced. Data type: STRING. This value changes when the network undergoes a protocol upgrade ("spork"). Useful for tracking changes in protocol behavior, analyzing the impact of upgrades, and debugging issues related to network versioning. Example: 'spork-22'. For more information on Flow's network upgrades (Sporks), see https://developers.flow.com/nodes/node-operation/spork
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,5 @@
|
||||
{% docs nflallday_id %}
|
||||
|
||||
The ID used by NFL AllDay. This can be pasted into the URL https://nflallday.com/moments/{nflallday_id} to view the moment on the marketplace.
|
||||
The unique identifier used by NFL AllDay for the moment. Data type: STRING. This field provides the official NFL AllDay identifier for the moment, enabling direct linking to the marketplace and cross-referencing with external NFL AllDay data. Used for marketplace integration, external data joins, and direct user navigation to moments. Example: Can be used in URL https://nflallday.com/moments/{nflallday_id} to view the moment on the marketplace. Important for marketplace integration, external data correlation, and user experience features.
|
||||
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,5 @@
|
||||
{% docs nft_collection %}
|
||||
|
||||
The contract address or ID for the NFT Collection.
|
||||
The contract address or identifier for the NFT collection on the Flow blockchain. Data type: STRING. This field identifies the smart contract that manages the NFT collection, enabling collection-level analytics, filtering, and protocol attribution. Used for grouping NFTs by collection, tracking collection performance, and joining with metadata tables. Example: 'A.e4cf4bdc1751c65d.AllDay' for NFL All Day, 'A.87ca73a41bb50ad5.TopShot' for NBA TopShot. Important for collection analytics, marketplace filtering, and cross-collection comparisons.
|
||||
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,5 @@
|
||||
{% docs nft_id %}
|
||||
|
||||
The id of the NFT, usually a number.
|
||||
The unique identifier for the NFT within its collection. Data type: STRING or NUMBER. This field uniquely identifies a specific NFT token within a collection, typically representing the token ID or serial number assigned during minting. Used for NFT-level analytics, tracking individual token movements, and joining with metadata tables. Example: '12345' for TopShot moment #12345, or 'A.1234567890abcdef.Moment#456' for a specific moment. Important for NFT tracking, sales analysis, and metadata joins.
|
||||
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,5 @@
|
||||
{% docs node_id %}
|
||||
|
||||
The address, known on the Flow blockchain as Node ID, of the validator.
|
||||
The unique identifier for a validator node in the Flow blockchain network. Data type: STRING. This field represents the address or identifier of a validator node that participates in the consensus mechanism and staking operations. Used for validator identification, staking analysis, and governance operations. Example: '0x1234567890abcdef' for a specific validator node address. Critical for staking operations, validator performance tracking, and maintaining the integrity of the Flow blockchain consensus mechanism.
|
||||
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,3 @@
|
||||
{% docs parent_id %}
|
||||
|
||||
The block hash for the parent block.
|
||||
|
||||
The hash of the parent block for the current block on the Flow blockchain. Data type: STRING. This field establishes the chain structure by linking each block to its predecessor, enabling chain traversal and reorganization analysis. Example: 'a1b2c3d4...' (the block hash of the previous block). Used for lineage analysis, fork detection, and chain integrity verification.
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,3 @@
|
||||
{% docs payer %}
|
||||
|
||||
Address of the wallet paying for the transaction.
|
||||
|
||||
The Flow address of the account responsible for paying the transaction fees. Data type: STRING. The payer may be different from the proposer or authorizers. This field is used to analyze fee attribution, sponsorship patterns, and participant roles in Flow's multi-signer transaction model. Example: '0x1cf0e2f2f715450'. Important for understanding who bears the cost of transaction execution.
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,3 @@
|
||||
{% docs pk_id %}
|
||||
|
||||
A uniquely generated identifier assigned by a surrogate key
|
||||
|
||||
`pk_id` is a surrogate primary key, uniquely generated for each row in the table. Data type: STRING or INTEGER (implementation-specific). This field ensures every record is uniquely identifiable, even if the source data lacks a natural primary key. Used for efficient joins, deduplication, and as a reference in downstream models. Example: an auto-incremented integer or a UUID string. Essential for maintaining data integrity and supporting dbt tests for uniqueness.
|
||||
{% enddocs %}
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
{% docs platform %}
|
||||
|
||||
Protocol on which the event (dex swap, nft trade) occurred, where able to determine.
|
||||
The name of the protocol, platform, or DEX where the event (swap, trade, or other DeFi action) occurred. Data type: STRING. Used to attribute activity to a specific protocol (e.g., 'blocto', 'metapier', 'topshot_marketplace') for analytics, filtering, and reporting. This field is essential for protocol-level analysis, market share tracking, and understanding user behavior across DeFi platforms. Example: 'blocto' for BloctoSwap, 'metapier' for Metapier DEX. Important for protocol attribution, competitive analysis, and cross-platform comparisons.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
{% docs player %}
|
||||
|
||||
The player who is the focus of the moment.
|
||||
The name of the athlete or player featured in the NFT moment. Data type: STRING. This field identifies the sports figure who is the primary subject of the NFT, enabling player-level analytics, performance tracking, and fan engagement analysis. Used for player attribution, performance correlation with NFT values, and fan behavior analysis. Example: 'LeBron James' for NBA TopShot, 'Tom Brady' for NFL All Day. Important for player-based analytics, fan engagement tracking, and athlete performance correlation with NFT market activity.
|
||||
|
||||
{% enddocs %}
|
||||
@ -1,84 +1,64 @@
|
||||
{% docs prices_dim_asset_metadata_table_doc %}
|
||||
|
||||
A comprehensive dimensional table holding asset metadata and other relevant details pertaining to each id, from multiple providers. This data set includes raw, non-transformed data coming directly from the provider APIs and rows are not intended to be unique. As a result, there may be data quality issues persisting in the APIs that flow through to this dimensional model. If you are interested in using a curated data set instead, please utilize ez_asset_metadata.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
{% docs prices_ez_asset_metadata_table_doc %}
|
||||
|
||||
A convenience table holding prioritized asset metadata and other relevant details pertaining to each token_address and native asset. This data set is highly curated and contains metadata for one unique asset per blockchain.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
{% docs prices_fact_prices_ohlc_hourly_table_doc %}
|
||||
|
||||
A comprehensive fact table holding id and provider specific open, high, low, close hourly prices, from multiple providers. This data set includes raw, non-transformed data coming directly from the provider APIs and rows are not intended to be unique. As a result, there may be data quality issues persisting in the APIs that flow through to this fact based model. If you are interested in using a curated data set instead, please utilize ez_prices_hourly.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
{% docs prices_ez_prices_hourly_table_doc %}
|
||||
|
||||
A convenience table for determining token prices by address and blockchain, and native asset prices by symbol and blockchain. This data set is highly curated and contains metadata for one price per hour per unique asset and blockchain.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
{% docs prices_provider %}
|
||||
|
||||
The provider or source of the data.
|
||||
The data provider or source for the asset metadata or price record. Data type: STRING. This field identifies the external service, API, or protocol that supplied the asset or price data (e.g., 'CoinGecko', 'CoinMarketCap', 'Dapper', 'Flow Oracle'). Used for data quality analysis, source attribution, and filtering by provider. Example: 'CoinGecko' for token prices, 'Dapper' for Flow-native asset metadata. Important for understanding data provenance, resolving discrepancies, and ensuring data reliability in analytics workflows.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
{% docs prices_asset_id %}
|
||||
|
||||
The unique identifier representing the asset.
|
||||
The unique identifier representing the asset within the price provider's system. Data type: STRING. This field serves as the primary key for identifying specific assets across different price providers and data sources. Used for joining price data with asset metadata, tracking price movements over time, and maintaining referential integrity between fact and dimension tables. Example: 'bitcoin' for Bitcoin on CoinGecko, 'ethereum' for Ethereum on CoinMarketCap. Critical for data lineage, asset identification, and cross-provider data reconciliation in financial analytics and reporting workflows.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
{% docs prices_name %}
|
||||
|
||||
The name of asset.
|
||||
The full name of the asset as provided by the price data source. Data type: STRING. This field contains the human-readable, official name of the cryptocurrency, token, or digital asset. Used for display purposes, user interfaces, reporting, and asset identification in analytics dashboards. Example: 'Bitcoin' for BTC, 'Ethereum' for ETH, 'Flow' for FLOW. Important for user experience, data presentation, and maintaining consistency across different price providers and blockchain networks.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
{% docs prices_symbol %}
|
||||
|
||||
The symbol of asset.
|
||||
The ticker symbol or abbreviated code representing the asset. Data type: STRING. This field contains the short, standardized identifier used in trading, price displays, and market data. Used for quick asset identification, trading interfaces, price feeds, and cross-platform asset matching. Example: 'BTC' for Bitcoin, 'ETH' for Ethereum, 'FLOW' for Flow, 'USDC' for USD Coin. Critical for market data integration, trading operations, and maintaining consistency across different exchanges and price providers.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
{% docs prices_token_address %}
|
||||
|
||||
The specific address representing the asset on a specific platform. This will be NULL if referring to a native asset.
|
||||
The blockchain-specific contract address or identifier for the token asset. Data type: STRING. This field contains the unique address where the token contract is deployed on its respective blockchain network. Used for token identification, contract verification, cross-chain asset mapping, and blockchain-specific operations. Example: '0xa0b86a33e6441b8c4c8c8c8c8c8c8c8c8c8c8c8c' for USDC on Ethereum, NULL for native assets like Bitcoin or Flow. Critical for DeFi operations, smart contract interactions, and maintaining accurate token mappings across different blockchain networks.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
{% docs prices_blockchain %}
|
||||
|
||||
The Blockchain, Network, or Platform for this asset.
|
||||
The blockchain network or platform where the asset is native or primarily traded. Data type: STRING. This field identifies the specific blockchain ecosystem that hosts the asset's smart contract or where the native asset operates. Used for cross-chain analytics, multi-chain portfolio tracking, and blockchain-specific filtering and grouping. Example: 'ethereum' for ETH and ERC-20 tokens, 'flow' for FLOW and Flow-native assets, 'bitcoin' for BTC. Critical for understanding asset distribution across blockchain networks, cross-chain bridge analysis, and multi-chain DeFi analytics.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
{% docs prices_blockchain_id %}
|
||||
|
||||
The unique identifier of the Blockchain, Network, or Platform for this asset.
|
||||
The unique numeric identifier for the blockchain network or platform. Data type: INTEGER. This field provides a standardized way to identify blockchain networks across different systems and APIs. Used for blockchain network identification, cross-platform data integration, and maintaining consistent blockchain references. Example: 1 for Ethereum mainnet, 137 for Polygon, 0 for Bitcoin. Important for chain ID validation, cross-chain bridge operations, and maintaining referential integrity in multi-chain analytics systems.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
{% docs prices_decimals %}
|
||||
|
||||
The number of decimals for the asset. May be NULL.
|
||||
The number of decimal places used to represent the smallest unit of the asset. Data type: INTEGER. This field indicates the precision with which the asset can be divided and is essential for accurate price calculations and token amount conversions. Used for token amount normalization, price precision calculations, and ensuring accurate financial computations. Example: 18 for most ERC-20 tokens, 8 for Bitcoin, 6 for USDC. Critical for DeFi operations, token transfers, and maintaining precision in financial calculations across different blockchain networks.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
{% docs prices_is_native %}
|
||||
|
||||
A flag indicating assets native to the respective blockchain.
|
||||
A boolean flag indicating whether the asset is the native token of its respective blockchain network. Data type: BOOLEAN. This field distinguishes between native blockchain tokens and smart contract-based tokens. Used for filtering native vs. token assets, blockchain-specific analytics, and understanding asset distribution across different token types. Example: TRUE for Bitcoin (BTC), Ethereum (ETH), and Flow (FLOW), FALSE for USDC, DAI, and other smart contract tokens. Important for blockchain economics analysis, native token price tracking, and understanding the relationship between native tokens and their ecosystem tokens.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
{% docs prices_is_deprecated %}
|
||||
|
||||
A flag indicating if the asset is deprecated or no longer supported by the provider.
|
||||
A boolean flag indicating whether the asset has been deprecated or is no longer actively supported by the price provider. Data type: BOOLEAN. This field helps identify assets that may have outdated or unreliable price data. Used for data quality filtering, identifying discontinued assets, and ensuring data reliability in analytics and trading operations. Example: TRUE for deprecated tokens or assets no longer listed on exchanges, FALSE for actively traded assets. Critical for data quality management, avoiding stale price data, and maintaining accurate market analytics.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
@ -96,42 +76,42 @@ Deprecating soon! Please use the decimals column in `ez_asset_metadata` or join
|
||||
|
||||
{% docs prices_hour %}
|
||||
|
||||
Hour that the price was recorded at.
|
||||
The timestamp representing the hour when the price data was recorded or aggregated. Data type: TIMESTAMP. This field provides the temporal reference for hourly price data and is used for time-series analysis, price trend calculations, and temporal data aggregation. Used for hourly price tracking, time-based filtering, and chronological analysis of price movements. Example: '2024-01-15 14:00:00' for the hour starting at 2 PM on January 15, 2024. Critical for time-series analytics, price volatility calculations, and maintaining temporal consistency in financial data analysis.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
{% docs prices_price %}
|
||||
|
||||
Closing price of the recorded hour in USD.
|
||||
The closing price of the asset for the specified hour, denominated in USD. Data type: FLOAT. This field represents the final trading price of the asset during the hour and is used for price analysis, portfolio valuation, and market performance calculations. Used for price trend analysis, asset valuation, and financial reporting. Example: 45000.50 for Bitcoin price at $45,000.50 USD per BTC. Critical for portfolio management, price impact analysis, and maintaining accurate financial records for trading and investment operations.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
{% docs prices_is_imputed %}
|
||||
|
||||
A flag indicating if the price was imputed, or derived, from the last arriving record. This is generally used for tokens with low-liquidity or inconsistent reporting.
|
||||
A boolean flag indicating whether the price data was imputed or derived from previous records rather than being directly observed. Data type: BOOLEAN. This field helps identify price data that may be less reliable due to low liquidity or inconsistent reporting from the source. Used for data quality assessment, filtering out potentially unreliable price data, and understanding data completeness. Example: TRUE for low-liquidity tokens with infrequent trading, FALSE for actively traded assets with regular price updates. Critical for data quality management, risk assessment, and ensuring accurate price analysis for trading and investment decisions.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
{% docs prices_open %}
|
||||
|
||||
Opening price of the recorded hour in USD.
|
||||
The opening price of the asset at the beginning of the specified hour, denominated in USD. Data type: FLOAT. This field represents the first trading price of the asset during the hour and is used for OHLC (Open, High, Low, Close) price analysis and volatility calculations. Used for price range analysis, volatility measurement, and technical analysis indicators. Example: 44000.00 for Bitcoin opening at $44,000.00 USD per BTC at the start of the hour. Critical for candlestick chart analysis, price momentum calculations, and understanding intra-hour price movements.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
{% docs prices_high %}
|
||||
|
||||
Highest price of the recorded hour in USD
|
||||
The highest trading price of the asset during the specified hour, denominated in USD. Data type: FLOAT. This field represents the peak price reached by the asset within the hour and is used for price range analysis and volatility calculations. Used for resistance level analysis, volatility measurement, and understanding price extremes during trading periods. Example: 46000.00 for Bitcoin reaching a high of $46,000.00 USD per BTC during the hour. Critical for technical analysis, price range calculations, and understanding market sentiment and price momentum.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
{% docs prices_low %}
|
||||
|
||||
Lowest price of the recorded hour in USD
|
||||
The lowest trading price of the asset during the specified hour, denominated in USD. Data type: FLOAT. This field represents the minimum price reached by the asset within the hour and is used for price range analysis and volatility calculations. Used for support level analysis, volatility measurement, and understanding price extremes during trading periods. Example: 43000.00 for Bitcoin reaching a low of $43,000.00 USD per BTC during the hour. Critical for technical analysis, price range calculations, and understanding market sentiment and price momentum.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
{% docs prices_close %}
|
||||
|
||||
Closing price of the recorded hour in USD
|
||||
The closing price of the asset at the end of the specified hour, denominated in USD. Data type: FLOAT. This field represents the final trading price of the asset during the hour and is used for OHLC (Open, High, Low, Close) price analysis and trend calculations. Used for price trend analysis, momentum calculations, and technical indicator computations. Example: 45000.50 for Bitcoin closing at $45,000.50 USD per BTC at the end of the hour. Critical for candlestick chart analysis, price trend identification, and understanding market direction and momentum.
|
||||
|
||||
{% enddocs %}
|
||||
@ -1,6 +1,5 @@
|
||||
{% docs project_name %}
|
||||
|
||||
The overarching project name, related to the address name. For example, Kraken (vs. Kraken Deposit Wallet for address_names).
|
||||
For validators, this will be the name only if provided as most validators do not provide such a name.
|
||||
The overarching project or organization name associated with the validator node. Data type: STRING. This field provides a human-readable identifier for the entity operating the validator node, helping to categorize and identify validator operators. Used for validator operator analysis, governance transparency, and network participant identification. Example: 'Kraken' for Kraken-operated validators, 'Dapper Labs' for Dapper-operated validators. Critical for governance analysis, validator accountability, and understanding the distribution of network control among different entities.
|
||||
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,3 @@
|
||||
{% docs proposer %}
|
||||
|
||||
Address of the transaction proposer.
|
||||
|
||||
The Flow address of the account that proposed the transaction. Data type: STRING. The proposer is responsible for submitting the transaction to the network and paying the proposal fee. This field is used to analyze transaction origination, proposer activity, and fee attribution. Example: '0x1cf0e2f2f715450'. Important for understanding transaction lifecycle and participant roles in Flow's multi-signer model.
|
||||
{% enddocs %}
|
||||
@ -1,7 +1,3 @@
|
||||
{% docs script %}
|
||||
|
||||
The Cadence script executed in this transaction.
|
||||
|
||||
https://developers.flow.com/tooling/fcl-js/scripts
|
||||
|
||||
The Cadence smart contract code or script executed as part of the transaction. Data type: STRING. This field contains the source code that defines the transaction's logic, including function calls, arguments, and contract interactions. Used for auditing, debugging, and analyzing smart contract usage on Flow. Example: a Cadence script for transferring tokens. For more details, see [Flow Cadence Scripts](https://developers.flow.com/tooling/fcl-js/scripts).
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,5 @@
|
||||
{% docs season %}
|
||||
|
||||
The season during which the moment occurred.
|
||||
The sports season during which the NFT moment occurred. Data type: STRING. This field identifies the specific season when the moment was captured, enabling temporal analysis, season-based performance tracking, and historical trend analysis. Used for season-level analytics, performance correlation across seasons, and historical NFT value analysis. Example: '2021-22' for NBA season, '2022' for NFL season. Important for temporal analysis, season-based performance tracking, and understanding how NFT values correlate with seasonal sports performance.
|
||||
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,5 @@
|
||||
{% docs serial_number %}
|
||||
|
||||
The serial number for the Moment, such as 25, within the collection.
|
||||
The serial number or edition number of the NFT within its collection. Data type: NUMBER. This field represents the specific edition number of the NFT, indicating its position within the total circulation of that particular moment or token. Used for rarity analysis, edition tracking, and determining the uniqueness of NFTs within a collection. Example: 25 for the 25th edition of a moment, 1 for the first edition. Important for rarity calculations, edition-based analytics, and determining NFT scarcity within collections.
|
||||
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,5 @@
|
||||
{% docs set_name %}
|
||||
|
||||
Name of the set in which the moment was dropped.
|
||||
The name of the NFT set or series in which the moment was released. Data type: STRING. This field identifies the specific set or collection within a broader NFT project, enabling set-level analytics, rarity analysis, and set performance tracking. Used for set attribution, set-based market analysis, and understanding the organizational structure of NFT collections. Example: 'Base Set' for TopShot, 'Genesis' for All Day. Important for set-based analytics, rarity calculations, and understanding the hierarchical structure of NFT collections.
|
||||
|
||||
{% enddocs %}
|
||||
@ -1,71 +1,66 @@
|
||||
{% docs ez_core_metrics_hourly_table_doc %}
|
||||
|
||||
A convenience table that aggregates block and transaction related metrics using various aggregate functions such as SUM, COUNT, MIN and MAX from the fact_transactions table, on an hourly basis. Stats for the current hour will be updated as new data arrives.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
{% docs block_timestamp_hour %}
|
||||
|
||||
The hour of the timestamp of the block.
|
||||
The hour timestamp representing the aggregation period for core blockchain metrics. Data type: TIMESTAMP. This field provides the temporal reference for hourly aggregated metrics and is used for time-series analysis and chronological data organization. Used for hourly performance tracking, trend analysis, and temporal data aggregation. Example: '2024-01-15 14:00:00' for the hour starting at 2 PM on January 15, 2024. Critical for time-series analytics, performance monitoring, and maintaining temporal consistency in blockchain metrics analysis.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
{% docs block_number_min %}
|
||||
|
||||
The minimum block number in the hour.
|
||||
The minimum block number within the specified hour period. Data type: INTEGER. This field represents the lowest block number processed during the hour and is used for block range analysis and data completeness verification. Used for block range tracking, data gap identification, and understanding blockchain progression within time periods. Example: 12345678 for the first block in the hour. Critical for data quality assessment, block progression monitoring, and maintaining accurate blockchain state tracking.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
{% docs block_number_max %}
|
||||
|
||||
The maximum block number in the hour.
|
||||
The maximum block number within the specified hour period. Data type: INTEGER. This field represents the highest block number processed during the hour and is used for block range analysis and data completeness verification. Used for block range tracking, data gap identification, and understanding blockchain progression within time periods. Example: 12345999 for the last block in the hour. Critical for data quality assessment, block progression monitoring, and maintaining accurate blockchain state tracking.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
{% docs block_count %}
|
||||
|
||||
The number of blocks in the hour.
|
||||
The total number of blocks processed within the specified hour period. Data type: INTEGER. This field represents the count of blocks that were created and processed during the hour, providing a key metric for blockchain throughput and network activity. Used for network performance analysis, throughput monitoring, and understanding blockchain activity levels. Example: 321 for 321 blocks processed in the hour. Critical for network health monitoring, performance benchmarking, and understanding blockchain scalability and efficiency.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
{% docs transaction_count %}
|
||||
|
||||
The number of transactions in the hour.
|
||||
The total number of transactions processed within the specified hour period. Data type: INTEGER. This field represents the count of all transactions that were submitted and processed during the hour, regardless of success or failure status. Used for transaction volume analysis, network activity monitoring, and understanding user engagement levels. Example: 15420 for 15,420 transactions processed in the hour. Critical for network performance analysis, user activity tracking, and understanding blockchain adoption and usage patterns.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
{% docs transaction_count_success %}
|
||||
|
||||
The number of successful transactions in the hour.
|
||||
The number of transactions that were successfully processed within the specified hour period. Data type: INTEGER. This field represents the count of transactions that completed successfully without errors or failures. Used for success rate analysis, network reliability monitoring, and understanding transaction processing efficiency. Example: 15200 for 15,200 successful transactions out of 15,420 total transactions. Critical for network health assessment, user experience analysis, and identifying potential network issues or bottlenecks.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
{% docs transaction_count_failed %}
|
||||
|
||||
The number of failed transactions in the hour.
|
||||
The number of transactions that failed to process within the specified hour period. Data type: INTEGER. This field represents the count of transactions that encountered errors or failures during processing. Used for failure rate analysis, network issue identification, and understanding transaction processing reliability. Example: 220 for 220 failed transactions out of 15,420 total transactions. Critical for network health monitoring, error pattern analysis, and identifying potential network issues or user experience problems.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
{% docs unique_from_count %}
|
||||
|
||||
The number of unique proposer from addresses in the hour.
|
||||
The number of unique proposer addresses that submitted transactions within the specified hour period. Data type: INTEGER. This field represents the count of distinct accounts that acted as transaction proposers during the hour. Used for user activity analysis, network participation monitoring, and understanding user engagement patterns. Example: 8500 for 8,500 unique proposer addresses in the hour. Critical for understanding network decentralization, user adoption patterns, and identifying active user communities.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
{% docs unique_payer_count %}
|
||||
|
||||
The number of unique payers to addresses in the hour.
|
||||
The number of unique payer addresses that funded transactions within the specified hour period. Data type: INTEGER. This field represents the count of distinct accounts that acted as transaction payers during the hour. Used for user activity analysis, network participation monitoring, and understanding transaction funding patterns. Example: 8200 for 8,200 unique payer addresses in the hour. Critical for understanding network decentralization, user adoption patterns, and identifying accounts that fund transaction operations.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
{% docs total_fees_native %}
|
||||
|
||||
The sum of all fees in the hour, in the native fee currency.
|
||||
The total sum of all transaction fees collected within the specified hour period, denominated in the native blockchain currency (FLOW). Data type: NUMBER (decimal adjusted). This field represents the aggregate fees paid by users for transaction processing during the hour. Used for fee revenue analysis, network economics monitoring, and understanding transaction cost patterns. Example: 1250.75 for 1,250.75 FLOW in total fees collected. Critical for network economics analysis, validator reward calculations, and understanding the cost of blockchain operations.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
{% docs total_fees_usd %}
|
||||
|
||||
The sum of all fees in the hour, in USD.
|
||||
The total sum of all transaction fees collected within the specified hour period, converted to USD equivalent value. Data type: NUMBER (decimal adjusted). This field represents the aggregate fees paid by users for transaction processing during the hour, normalized to USD for cross-currency comparison and financial analysis. Used for fee revenue analysis, network economics monitoring, and understanding transaction cost patterns in standardized currency terms. Example: 1250.50 for $1,250.50 USD equivalent in total fees collected. Critical for network economics analysis, financial reporting, and understanding the real-world cost of blockchain operations.
|
||||
|
||||
{% enddocs %}
|
||||
|
||||
@ -1,6 +1,5 @@
|
||||
{% docs swap_contract %}
|
||||
|
||||
The smart contract address of the DEX swap pool.
|
||||
Note for metapier swaps in the labels table - they all appear to use the same master contract `A.609e10301860b683.PierPair` so the `pool_id` is essential to differentiating what pool is used in the swap route.
|
||||
The smart contract address of the DEX swap pool or liquidity pool involved in the transaction. Data type: STRING. This field identifies the specific contract facilitating the swap, which is essential for protocol attribution, pool-level analytics, and tracing liquidity movements. For Metapier swaps, all pools may use the same master contract (e.g., 'A.609e10301860b683.PierPair'), so the 'pool_id' is required to differentiate between pools. Example: 'A.609e10301860b683.PierPair' for Metapier, or a unique contract address for other DEXs. Important for understanding liquidity routing, protocol usage, and swap path analysis.
|
||||
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,5 @@
|
||||
{% docs swap_index %}
|
||||
|
||||
The positioning of the swap within a transaction. The first swap will index at 0. A swap transaction may only run through 1 pool, in which case the max index will be 0. A multi-pool swap that runs through 2 pools, for example, will have 2 records with swap index 0 and 1.
|
||||
The position of the swap within a transaction, indicating the order of execution in multi-hop or multi-pool swaps. Data type: NUMBER (integer). The first swap in a transaction is indexed at 0. If a transaction routes through multiple pools, each swap is assigned an incrementing index (e.g., 0, 1, 2). Used to reconstruct swap paths, analyze routing strategies, and understand complex DeFi trades. Example: A single-pool swap has swap_index 0; a two-pool route has swaps with indices 0 and 1. Important for path analysis, DEX routing analytics, and multi-hop trade reconstruction.
|
||||
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,5 @@
|
||||
{% docs symbol %}
|
||||
|
||||
Short-name symbol for the crypto token, e.g. BLT.
|
||||
Short-name symbol for the crypto token or asset, such as 'FLOW', 'USDC', or 'BLT'. Data type: STRING. Used to identify the asset in analytics, dashboards, and reporting. This field is critical for token-level analysis, price lookups, and filtering. Example: 'FLOW' for Flow's native token, 'USDC' for USD Coin. Important for user-facing analytics, protocol attribution, and cross-chain comparisons.
|
||||
|
||||
{% enddocs %}
|
||||
@ -1,5 +0,0 @@
|
||||
{% docs table_dim_labels %}
|
||||
|
||||
The labels table is a store of one-to-one address identifiers, or an address name. Labels are broken out into a "type" (such as cex, dex, dapp, games, etc.) and a "subtype" (ex: contract_deployer, hot_wallet, token_contract, etc.) in order to help classify each address name into similar groups. Our labels are sourced from many different places, but can primarily be grouped into two categories: automatic and manual. Automatic labels are continuously labeled based on certain criteria, such as a known contract deploying another contract, behavior based algorithms for finding deposit wallets, and consistent data pulls of custom protocol APIs. Manual labels are done periodically to find addresses that cannot be found programmatically such as finding new protocol addresses, centralized exchange hot wallets, or trending addresses. Labels can also be added by our community by using our add-a-label tool (https://science.flipsidecrypto.xyz/add-a-label/) or on-chain with near (https://near.social/lord1.near/widget/Form) and are reviewed by our labels team. A label can be removed by our labels team if it is found to be incorrect or no longer relevant; this generally will only happen for mislabeled deposit wallets.
|
||||
|
||||
{% enddocs %}
|
||||
28
models/descriptions/tables/beta__dim_nfl_athletes.md
Normal file
28
models/descriptions/tables/beta__dim_nfl_athletes.md
Normal file
@ -0,0 +1,28 @@
|
||||
{% docs beta__dim_nfl_athletes %}
|
||||
# beta__dim_nfl_athletes
|
||||
|
||||
## Description
|
||||
|
||||
A beta-dimensional table containing NFL athlete metadata from the ESPN Athletes Endpoint. This table serves as an experimental data source for NFL AllDay NFT analytics and athlete-related analysis. The table is in beta mode and subject to change, providing athlete information that may be used for NFT moment analysis, player performance tracking, and sports analytics. Due to its experimental nature, this table should not be used for production purposes without accepting the risk of sudden changes or deletion.
|
||||
|
||||
## Key Use Cases
|
||||
|
||||
- **NFL AllDay Analytics**: Supporting NFT moment analysis and athlete-related NFT performance tracking
|
||||
- **Player Research**: Providing athlete metadata for sports analytics and player performance analysis
|
||||
- **Experimental Features**: Supporting beta features and experimental analytics in the sports NFT space
|
||||
- **Data Exploration**: Investigating potential use cases for athlete data in blockchain applications
|
||||
- **Prototype Development**: Supporting prototype development for sports-related blockchain features
|
||||
|
||||
## Important Relationships
|
||||
|
||||
- **beta__dim_nfl_teams**: Links to team information for athlete-team relationship analysis
|
||||
- **beta__dim_nflad_playoff_rosters**: May link to playoff roster information for seasonal analysis
|
||||
- **nft__dim_moment_metadata**: May overlap with NFL AllDay NFT moment data
|
||||
- **beta__ez_moment_player_ids**: May provide additional player identification and linking capabilities
|
||||
|
||||
## Commonly-used Fields
|
||||
|
||||
- **Athlete identification fields**: For player identification and analysis
|
||||
- **Team association fields**: For athlete-team relationship analysis
|
||||
- **Metadata fields**: For athlete information and categorization
|
||||
{% enddocs %}
|
||||
28
models/descriptions/tables/beta__dim_nfl_teams.md
Normal file
28
models/descriptions/tables/beta__dim_nfl_teams.md
Normal file
@ -0,0 +1,28 @@
|
||||
{% docs beta__dim_nfl_teams %}
|
||||
# beta__dim_nfl_teams
|
||||
|
||||
## Description
|
||||
|
||||
A beta-dimensional table containing NFL team metadata from the ESPN Teams Endpoint. This table serves as an experimental data source for NFL AllDay NFT analytics and team-related analysis. The table is in beta mode and subject to change, providing team information that may be used for NFT moment analysis, team performance tracking, and sports analytics. Due to its experimental nature, this table should not be used for production purposes without accepting the risk of sudden changes or deletion.
|
||||
|
||||
## Key Use Cases
|
||||
|
||||
- **NFL AllDay Analytics**: Supporting NFT moment analysis and team-related NFT performance tracking
|
||||
- **Team Research**: Providing team metadata for sports analytics and team performance analysis
|
||||
- **Experimental Features**: Supporting beta features and experimental analytics in the sports NFT space
|
||||
- **Data Exploration**: Investigating potential use cases for team data in blockchain applications
|
||||
- **Prototype Development**: Supporting prototype development for sports-related blockchain features
|
||||
|
||||
## Important Relationships
|
||||
|
||||
- **beta__dim_nfl_athletes**: Links to athlete information for team-athlete relationship analysis
|
||||
- **beta__dim_nflad_playoff_rosters**: May link to playoff roster information for seasonal analysis
|
||||
- **nft__dim_moment_metadata**: May overlap with NFL AllDay NFT moment data
|
||||
- **beta__ez_moment_player_ids**: May provide additional team identification and linking capabilities
|
||||
|
||||
## Commonly-used Fields
|
||||
|
||||
- **Team identification fields**: For team identification and analysis
|
||||
- **League association fields**: For team-league relationship analysis
|
||||
- **Metadata fields**: For team information and categorization
|
||||
{% enddocs %}
|
||||
@ -0,0 +1,29 @@
|
||||
{% docs beta__dim_nflad_playoff_rosters %}
|
||||
# beta__dim_nflad_playoff_rosters
|
||||
|
||||
## Description
|
||||
|
||||
A temporary dimensional table containing official rosters for the Flipside x NFL AllDay Playoff Challenge. This table serves as a specialized data source for playoff-specific NFT analytics and roster management during the NFL playoff season. The table is designed to support the playoff challenge by providing accurate roster information for participating teams and players. Due to its temporary nature, this table may be removed or significantly modified after the playoff challenge concludes.
|
||||
|
||||
## Key Use Cases
|
||||
|
||||
- **Playoff Challenge Support**: Providing roster data for the Flipside x NFL AllDay Playoff Challenge
|
||||
- **Playoff Analytics**: Supporting playoff-specific NFT moment analysis and performance tracking
|
||||
- **Roster Management**: Maintaining accurate roster information for playoff participants
|
||||
- **Challenge Validation**: Supporting challenge rules and participant validation
|
||||
- **Seasonal Analysis**: Providing playoff-specific data for seasonal sports analytics
|
||||
|
||||
## Important Relationships
|
||||
|
||||
- **beta__dim_nfl_athletes**: Links to athlete information for roster-athlete relationship analysis
|
||||
- **beta__dim_nfl_teams**: Links to team information for roster-team relationship analysis
|
||||
- **nft__dim_moment_metadata**: May overlap with NFL AllDay playoff moment data
|
||||
- **beta__ez_moment_player_ids**: May provide additional player identification for playoff rosters
|
||||
|
||||
## Commonly-used Fields
|
||||
|
||||
- **Roster identification fields**: For roster identification and challenge management
|
||||
- **Player association fields**: For roster-player relationship analysis
|
||||
- **Team association fields**: For roster-team relationship analysis
|
||||
- **Playoff-specific fields**: For playoff challenge and seasonal analysis
|
||||
{% enddocs %}
|
||||
21
models/descriptions/tables/core__dim_address_mapping.md
Normal file
21
models/descriptions/tables/core__dim_address_mapping.md
Normal file
@ -0,0 +1,21 @@
|
||||
{% docs core__dim_address_mapping %}
|
||||
## Description
|
||||
This table maps EVM addresses to Flow addresses based on COA (Custody of Account) Creation events. Each row represents an association between a Flow address and an EVM address, enabling cross-chain identity mapping and analytics. A single Flow address may have multiple EVM addresses linked to it, reflecting multi-chain participation or asset bridging. The table is updated as new COA Creation events are detected on-chain.
|
||||
|
||||
## Key Use Cases
|
||||
- Linking user or contract activity across Flow and EVM-compatible chains
|
||||
- Supporting cross-chain analytics, wallet attribution, and identity resolution
|
||||
- Enabling DeFi, NFT, and bridge analytics that require address mapping
|
||||
- Auditing and monitoring asset flows between Flow and EVM ecosystems
|
||||
|
||||
## Important Relationships
|
||||
- Can be joined to Flow transaction and event tables (e.g., `core.fact_transactions`, `core.fact_events`) via `FLOW_ADDRESS` for on-chain activity
|
||||
- Can be joined to EVM-based analytics tables via `EVM_ADDRESS` for cross-chain analysis
|
||||
- Used by curated models in DeFi and NFT domains to enrich user and contract analytics with cross-chain context
|
||||
|
||||
## Commonly-used Fields
|
||||
- `FLOW_ADDRESS`: The Flow blockchain address for the user or contract
|
||||
- `EVM_ADDRESS`: The associated EVM-compatible address
|
||||
- `BLOCK_TIMESTAMP_ASSOCIATED`: Timestamp when the mapping was established
|
||||
- `BLOCK_HEIGHT_ASSOCIATED`: Block height at which the mapping was recorded
|
||||
{% enddocs %}
|
||||
20
models/descriptions/tables/core__dim_contract_labels.md
Normal file
20
models/descriptions/tables/core__dim_contract_labels.md
Normal file
@ -0,0 +1,20 @@
|
||||
{% docs core__dim_contract_labels %}
|
||||
## Description
|
||||
This table contains all contract labels referenced in the events of Flow transactions. Each row represents a unique contract, identified by its event contract address and contract name, and is enriched with account address metadata. The table provides a canonical mapping of contracts to their human-readable names and associated addresses, supporting entity resolution and contract-level analytics across the Flow blockchain.
|
||||
|
||||
## Key Use Cases
|
||||
- Enriching event and transaction data with contract labels for analytics and dashboards
|
||||
- Supporting entity resolution and contract-level segmentation in DeFi, NFT, and governance analytics
|
||||
- Enabling contract-level filtering, grouping, and reporting in business intelligence tools
|
||||
- Auditing and monitoring contract activity and deployments on Flow
|
||||
|
||||
## Important Relationships
|
||||
- Can be joined to `core.fact_events` via `event_contract` to enrich event data with contract names and addresses
|
||||
- Can be joined to `core.fact_transactions` via contract addresses for transaction-level analytics
|
||||
- Used by curated gold models in DeFi, NFT, and other domains to provide contract context and labeling
|
||||
|
||||
## Commonly-used Fields
|
||||
- `event_contract`: The Flow contract address emitting events
|
||||
- `contract_name`: The human-readable name of the contract
|
||||
- `account_address`: The account address associated with the contract
|
||||
{% enddocs %}
|
||||
22
models/descriptions/tables/core__dim_labels.md
Normal file
22
models/descriptions/tables/core__dim_labels.md
Normal file
@ -0,0 +1,22 @@
|
||||
{% docs core__dim_labels %}
|
||||
## Description
|
||||
This table provides a comprehensive mapping of Flow addresses to human-readable labels, supporting entity identification and classification across the blockchain. Each row represents a unique address and its associated label, with additional metadata such as label type, subtype, and creator. Labels are sourced from both automated algorithms and manual curation, enabling robust address classification for analytics and reporting. The table is continuously updated to reflect new addresses, protocol deployments, and community contributions.
|
||||
|
||||
## Key Use Cases
|
||||
- Enriching transaction, event, and contract data with human-readable labels for dashboards and analytics
|
||||
- Segmenting addresses by type (e.g., CEX, DEX, dApp, game) and subtype (e.g., contract_deployer, hot_wallet)
|
||||
- Supporting compliance, risk analysis, and wallet attribution
|
||||
- Powering entity-level analytics for DeFi, NFT, and governance applications
|
||||
|
||||
## Important Relationships
|
||||
- Can be joined to `core.fact_transactions`, `core.fact_events`, and other gold models via `address` for entity enrichment
|
||||
- Used by curated models in DeFi, NFT, and rewards domains to provide address context and segmentation
|
||||
- Label type and subtype fields enable advanced filtering and grouping in analytics workflows
|
||||
|
||||
## Commonly-used Fields
|
||||
- `address`: The Flow blockchain address being labeled
|
||||
- `label`: The human-readable name or tag for the address
|
||||
- `label_type`: The primary category of the address (e.g., CEX, NFT, DeFi)
|
||||
- `label_subtype`: The secondary classification (e.g., hot_wallet, validator)
|
||||
- `creator`: The source or contributor of the label
|
||||
{% enddocs %}
|
||||
24
models/descriptions/tables/core__ez_token_transfers.md
Normal file
24
models/descriptions/tables/core__ez_token_transfers.md
Normal file
@ -0,0 +1,24 @@
|
||||
{% docs core__ez_token_transfers %}
|
||||
## Description
|
||||
This table records all token transfers on the Flow blockchain, capturing both native and fungible token movements between accounts. Each row represents a single transfer event, including metadata such as transaction ID, block height, timestamp, sender, recipient, token contract, and amount. The table provides a normalized, analytics-ready view of token flows, supporting financial analysis, wallet tracking, and protocol monitoring.
|
||||
|
||||
## Key Use Cases
|
||||
- Analyzing token flow and wallet activity across the Flow ecosystem
|
||||
- Measuring protocol, dApp, or user-level token volumes and trends
|
||||
- Supporting DeFi analytics, whale tracking, and compliance monitoring
|
||||
- Building dashboards for token distribution, holder analysis, and transfer patterns
|
||||
|
||||
## Important Relationships
|
||||
- Derived from `core.fact_events` by extracting token transfer events and normalizing fields
|
||||
- Can be joined to `core.dim_labels` via `sender` or `recipient` for entity enrichment
|
||||
- Token contract field can be joined to contract label tables for protocol-level analytics
|
||||
- Used as a source for curated gold models in DeFi, rewards, and NFT analytics
|
||||
|
||||
## Commonly-used Fields
|
||||
- `tx_id`: Unique identifier for the transaction containing the transfer
|
||||
- `sender`: The Flow address sending tokens
|
||||
- `recipient`: The Flow address receiving tokens
|
||||
- `token_contract`: The contract address of the transferred token
|
||||
- `amount`: The quantity of tokens transferred (decimal adjusted)
|
||||
- `block_timestamp`: Used for time-series and trend analysis
|
||||
{% enddocs %}
|
||||
20
models/descriptions/tables/core__ez_transaction_actors.md
Normal file
20
models/descriptions/tables/core__ez_transaction_actors.md
Normal file
@ -0,0 +1,20 @@
|
||||
{% docs core__ez_transaction_actors %}
|
||||
## Description
|
||||
This curated table extracts all addresses involved in the events of each transaction on the Flow blockchain, generating an array of distinct actors for every transaction. Actors include authorizers, payers, proposers, and any other addresses referenced in transaction events. The table provides a normalized, analytics-ready view of transaction participants, supporting entity-level analysis and wallet attribution.
|
||||
|
||||
## Key Use Cases
|
||||
- Identifying all participants in a transaction for compliance and risk analysis
|
||||
- Supporting wallet attribution, entity mapping, and participant segmentation
|
||||
- Enabling analytics on transaction complexity, multi-sig usage, and collaborative workflows
|
||||
- Building dashboards for protocol, dApp, or user-level activity
|
||||
|
||||
## Important Relationships
|
||||
- Derived from `core.fact_transactions` and `core.fact_events` by extracting and aggregating participant addresses
|
||||
- Can be joined to `core.dim_labels` via `actors` for entity enrichment
|
||||
- Used by curated models in DeFi, NFT, and rewards domains to provide participant context
|
||||
|
||||
## Commonly-used Fields
|
||||
- `tx_id`: Unique identifier for the transaction
|
||||
- `actors`: Array of all addresses involved in the transaction (authorizers, payers, proposers, event participants)
|
||||
- `block_timestamp`: Used for time-series and participant trend analysis
|
||||
{% enddocs %}
|
||||
23
models/descriptions/tables/core__fact_blocks.md
Normal file
23
models/descriptions/tables/core__fact_blocks.md
Normal file
@ -0,0 +1,23 @@
|
||||
{% docs core__fact_blocks %}
|
||||
## Description
|
||||
This table records all blocks produced on the Flow blockchain, capturing block-level metadata such as block height, timestamp, network, chain ID, transaction count, and parent block references. Each row represents a unique block, providing the foundational structure for all on-chain activity and supporting block-level analytics. The data is sourced directly from the Flow blockchain and is updated as new blocks are produced.
|
||||
|
||||
## Key Use Cases
|
||||
- Analyzing block production rates and network performance
|
||||
- Measuring transaction throughput and block utilization
|
||||
- Investigating block-level events, forks, or anomalies
|
||||
- Supporting time-series analytics and historical blockchain state reconstruction
|
||||
- Serving as a join point for transaction, event, and token transfer models
|
||||
|
||||
## Important Relationships
|
||||
- Serves as the parent table for `core.fact_transactions`, `core.fact_events`, and `core.ez_token_transfers`, which reference block height and block timestamp
|
||||
- Can be joined with `core__fact_transactions` on `block_height` to analyze transactions per block
|
||||
- Used by downstream models in the gold layer for time-based aggregations and network health metrics
|
||||
|
||||
## Commonly-used Fields
|
||||
- `BLOCK_HEIGHT`: Unique identifier for each block, used for joins and ordering
|
||||
- `BLOCK_TIMESTAMP`: Timestamp of block production, essential for time-series analysis
|
||||
- `TX_COUNT`: Number of transactions included in the block, used for throughput and activity metrics
|
||||
- `CHAIN_ID`, `NETWORK`, `NETWORK_VERSION`: Identify the network context for the block
|
||||
- `PARENT_ID`: Reference to the parent block, useful for chain reorganization and lineage analysis
|
||||
{% enddocs %}
|
||||
25
models/descriptions/tables/core__fact_events.md
Normal file
25
models/descriptions/tables/core__fact_events.md
Normal file
@ -0,0 +1,25 @@
|
||||
{% docs core__fact_events %}
|
||||
## Description
|
||||
This table records all events emitted by transactions on the Flow blockchain. Each row represents a single event, capturing metadata such as the transaction ID, block height, timestamp, event type, emitting contract, event index, and event data payload. The table provides a granular, event-level view of on-chain activity, supporting detailed event-driven analytics and contract monitoring. Data is sourced directly from Flow transaction execution and includes both user-defined and system events.
|
||||
|
||||
## Key Use Cases
|
||||
- Analyzing contract activity and event emissions over time
|
||||
- Monitoring protocol-specific or user-defined events for dApps
|
||||
- Auditing on-chain activity and reconstructing transaction flows
|
||||
- Building dashboards for NFT, DeFi, and governance event tracking
|
||||
- Supporting alerting and anomaly detection based on event patterns
|
||||
|
||||
## Important Relationships
|
||||
- Linked to `core.fact_blocks` via `block_height` and `block_timestamp` for block context
|
||||
- Linked to `core.fact_transactions` via `tx_id` for transaction context and execution results
|
||||
- Event contract and event type fields can be joined to `core.dim_contract_labels` and other label tables for entity enrichment
|
||||
- Used as a source for curated gold models in DeFi, NFT, and other domains that analyze event activity
|
||||
|
||||
## Commonly-used Fields
|
||||
- `tx_id`: Unique identifier for the transaction emitting the event
|
||||
- `event_type`: Specifies the type of event (user-defined or system)
|
||||
- `event_contract`: Identifies the contract that emitted the event
|
||||
- `event_data`: Contains the event payload for analytics and business logic extraction
|
||||
- `block_timestamp`: Used for time-series analysis and event sequencing
|
||||
- `event_index`: Orders events within a transaction for accurate reconstruction
|
||||
{% enddocs %}
|
||||
23
models/descriptions/tables/core__fact_transactions.md
Normal file
23
models/descriptions/tables/core__fact_transactions.md
Normal file
@ -0,0 +1,23 @@
|
||||
{% docs core__fact_transactions %}
|
||||
## Description
|
||||
This table records all transactions executed on the Flow blockchain, including metadata such as transaction ID, block height, timestamp, proposer, payer, authorizers, gas limit, script, arguments, and execution results. Each row represents a unique transaction, capturing both successful and failed executions, and providing the foundation for transaction-level analytics and tracing.
|
||||
|
||||
## Key Use Cases
|
||||
- Analyzing transaction throughput and network activity
|
||||
- Investigating failed transactions and error messages
|
||||
- Tracing the flow of funds and contract interactions
|
||||
- Supporting DeFi, NFT, and governance analytics by linking transactions to events and token transfers
|
||||
- Building dashboards for transaction monitoring and user behavior analysis
|
||||
|
||||
## Important Relationships
|
||||
- Linked to `core.fact_blocks` via `block_height` and `block_timestamp` for block-level context
|
||||
- Referenced by `core.fact_events` and `core.ez_token_transfers` for event and token transfer analysis
|
||||
- Used as a base for downstream gold models in DeFi, NFT, and governance analytics
|
||||
|
||||
## Commonly-used Fields
|
||||
- `TX_ID`: Unique identifier for each transaction, used for joins and tracing
|
||||
- `BLOCK_HEIGHT`, `BLOCK_TIMESTAMP`: Provide block context for the transaction
|
||||
- `PROPOSER`, `PAYER`, `AUTHORIZERS`: Identify the parties involved in the transaction
|
||||
- `TX_SUCCEEDED`, `ERROR_MSG`: Indicate transaction success or failure and error details
|
||||
- `GAS_LIMIT`: Specifies the maximum gas allowed for execution
|
||||
{% enddocs %}
|
||||
24
models/descriptions/tables/defi__dim_swap_pool_labels.md
Normal file
24
models/descriptions/tables/defi__dim_swap_pool_labels.md
Normal file
@ -0,0 +1,24 @@
|
||||
{% docs defi__dim_swap_pool_labels %}
|
||||
## Description
|
||||
Models all DEX swap pool and pair creation events on the Flow blockchain. Captures metadata for each pool, including token contracts, deployment timestamp, pool ID, vault address, and swap contract. Supports pool-level analytics, liquidity tracking, and protocol attribution. Data is sourced from on-chain pool creation events and normalized for analytics.
|
||||
|
||||
## Key Use Cases
|
||||
- Analyze DEX pool creation and liquidity provisioning
|
||||
- Attribute swaps to specific pools and protocols
|
||||
- Track pool deployment and vault addresses
|
||||
- Support liquidity, TVL, and protocol market share analysis
|
||||
- Power DeFi dashboards and pool explorer tools
|
||||
|
||||
## Important Relationships
|
||||
- Can be joined with `defi__fact_dex_swaps` and `defi__ez_dex_swaps` for swap-level analytics
|
||||
- Protocol attribution via `swap_contract` and `platform` fields
|
||||
- Token-level analytics via `token0_contract` and `token1_contract`
|
||||
|
||||
## Commonly-used Fields
|
||||
- `swap_contract`: DEX pool contract address
|
||||
- `deployment_timestamp`: When the pool was deployed
|
||||
- `token0_contract` / `token1_contract`: Token contracts in the pool
|
||||
- `pool_id`: Unique identifier for the pool
|
||||
- `vault_address`: Address holding pool assets
|
||||
|
||||
{% enddocs %}
|
||||
27
models/descriptions/tables/defi__ez_bridge_activity.md
Normal file
27
models/descriptions/tables/defi__ez_bridge_activity.md
Normal file
@ -0,0 +1,27 @@
|
||||
{% docs defi__ez_bridge_activity %}
|
||||
## Description
|
||||
Enriched view of all token bridge transactions to and from the Flow blockchain, combining raw bridge activity with token symbol and USD price information. Adds business logic for easier analytics, including normalized asset values and protocol attribution. Data is sourced from bridge events and joined with curated price feeds.
|
||||
|
||||
## Key Use Cases
|
||||
- Analyze cross-chain token flows with USD normalization
|
||||
- Track protocol revenue and fee analytics in USD
|
||||
- Attribute bridge activity by token symbol and protocol
|
||||
- Power dashboards and user-facing analytics for cross-chain flows
|
||||
- Support compliance, risk, and DeFi market research
|
||||
|
||||
## Important Relationships
|
||||
- Sourced from `defi__fact_bridge_activity` (adds enrichment)
|
||||
- Joins with price models for USD values (`amount_usd`, `amount_fee_usd`)
|
||||
- Token symbol enrichment via curated price feeds
|
||||
- Can be joined with `core__ez_token_transfers` for full asset movement
|
||||
|
||||
## Commonly-used Fields
|
||||
- `tx_id`: Unique transaction identifier for bridge event
|
||||
- `block_timestamp`: When the bridge transaction occurred
|
||||
- `token_symbol`: Abbreviated symbol for the bridged token
|
||||
- `amount`: Quantity of tokens bridged (decimal adjusted)
|
||||
- `amount_usd`: Value of tokens bridged in USD
|
||||
- `amount_fee_usd`: Fee charged by the bridge protocol in USD
|
||||
- `platform`: Name of the bridge protocol
|
||||
|
||||
{% enddocs %}
|
||||
25
models/descriptions/tables/defi__ez_dex_swaps.md
Normal file
25
models/descriptions/tables/defi__ez_dex_swaps.md
Normal file
@ -0,0 +1,25 @@
|
||||
{% docs defi__ez_dex_swaps %}
|
||||
## Description
|
||||
Enriched view of all DEX swap transactions on the Flow blockchain, combining raw swap data with token symbol and USD price information. Adds business logic for easier analytics, including normalized asset values, protocol attribution, and swap path context. Data is sourced from swap events and joined with curated price feeds.
|
||||
|
||||
## Key Use Cases
|
||||
- Analyze DEX trading activity with USD normalization
|
||||
- Track protocol revenue and fee analytics in USD
|
||||
- Attribute swaps by token symbol, pool, and protocol
|
||||
- Power dashboards and user-facing analytics for DeFi trading
|
||||
- Support liquidity, slippage, and market research
|
||||
|
||||
## Important Relationships
|
||||
- Sourced from `defi__fact_dex_swaps` (adds enrichment)
|
||||
- Joins with price models for USD values (`amount_out_usd`, `amount_in_usd`)
|
||||
- Token symbol enrichment via curated price feeds
|
||||
- Can be joined with `defi__dim_swap_pool_labels` for pool metadata
|
||||
|
||||
## Commonly-used Fields
|
||||
- `tx_id`: Unique transaction identifier for swap event
|
||||
- `block_timestamp`: When the swap occurred
|
||||
- `token_out_symbol` / `token_in_symbol`: Abbreviated symbols for swapped tokens
|
||||
- `amount_out_usd` / `amount_in_usd`: USD value of tokens swapped
|
||||
- `platform`: Name of the DEX protocol
|
||||
|
||||
{% enddocs %}
|
||||
28
models/descriptions/tables/defi__fact_bridge_activity.md
Normal file
28
models/descriptions/tables/defi__fact_bridge_activity.md
Normal file
@ -0,0 +1,28 @@
|
||||
{% docs defi__fact_bridge_activity %}
|
||||
## Description
|
||||
Records all token bridge transactions to and from the Flow blockchain using supported bridge protocols (e.g., Blocto Teleport, Celer Bridge). Captures the full context of each cross-chain transfer, including source/destination addresses, token details, amounts, fees, and protocol metadata. Data is sourced from on-chain bridge events and normalized for analytics.
|
||||
|
||||
## Key Use Cases
|
||||
- Analyze cross-chain token flows into and out of Flow
|
||||
- Monitor bridge usage, volume, and protocol adoption
|
||||
- Track user participation in bridging activity
|
||||
- Attribute fees and bridge revenue by protocol
|
||||
- Support compliance and risk monitoring for cross-chain transfers
|
||||
|
||||
## Important Relationships
|
||||
- Linked to `defi__ez_bridge_activity` for enriched analytics (adds token symbols, USD values)
|
||||
- Can be joined with `core__ez_token_transfers` for end-to-end asset movement
|
||||
- Protocol attribution via `platform` and `bridge_address` fields
|
||||
- Token-level analytics via `token_address` and `amount`
|
||||
|
||||
## Commonly-used Fields
|
||||
- `tx_id`: Unique transaction identifier for bridge event
|
||||
- `block_timestamp`: When the bridge transaction occurred
|
||||
- `bridge_address`: Contract address of the bridge protocol
|
||||
- `token_address`: Contract address of the bridged token
|
||||
- `amount`: Quantity of tokens bridged (decimal adjusted)
|
||||
- `amount_fee`: Fee charged by the bridge protocol
|
||||
- `source_chain` / `destination_chain`: Blockchains involved in the transfer
|
||||
- `platform`: Name of the bridge protocol
|
||||
|
||||
{% enddocs %}
|
||||
28
models/descriptions/tables/defi__fact_dex_swaps.md
Normal file
28
models/descriptions/tables/defi__fact_dex_swaps.md
Normal file
@ -0,0 +1,28 @@
|
||||
{% docs defi__fact_dex_swaps %}
|
||||
## Description
|
||||
Records all decentralized exchange (DEX) swap transactions on the Flow blockchain. Captures the full context of each swap, including trader, pool, token in/out, amounts, and protocol metadata. Data is sourced from on-chain swap events and normalized for analytics, supporting both single-pool and multi-hop swaps.
|
||||
|
||||
## Key Use Cases
|
||||
- Analyze DEX trading activity and swap volume
|
||||
- Track user participation and trading behavior
|
||||
- Attribute swaps to specific pools and protocols
|
||||
- Support price impact, slippage, and liquidity analysis
|
||||
- Power DeFi dashboards and market research
|
||||
|
||||
## Important Relationships
|
||||
- Linked to `defi__ez_dex_swaps` for enriched analytics (adds token symbols, USD values)
|
||||
- Can be joined with `defi__dim_swap_pool_labels` for pool metadata
|
||||
- Protocol attribution via `platform` and `contract_address` fields
|
||||
- Token-level analytics via `token_in`/`token_out` and amounts
|
||||
|
||||
## Commonly-used Fields
|
||||
- `tx_id`: Unique transaction identifier for swap event
|
||||
- `block_timestamp`: When the swap occurred
|
||||
- `contract_address`: DEX pool contract address
|
||||
- `swap_index`: Order of swap in multi-hop transactions
|
||||
- `trader`: Account address of the swap initiator
|
||||
- `token_out` / `token_in`: Token contract addresses swapped out/in
|
||||
- `amount_out` / `amount_in`: Amounts swapped (decimal adjusted)
|
||||
- `platform`: Name of the DEX protocol
|
||||
|
||||
{% enddocs %}
|
||||
30
models/descriptions/tables/gov__dim_validator_labels.md
Normal file
30
models/descriptions/tables/gov__dim_validator_labels.md
Normal file
@ -0,0 +1,30 @@
|
||||
{% docs gov__dim_validator_labels %}
|
||||
|
||||
## Description
|
||||
|
||||
A dimensional table containing validator node metadata and labeling information for the Flow blockchain network. This table serves as the foundation for understanding the validator ecosystem, providing information about node types, roles, and associated projects or organizations. It supports governance analysis by enabling identification and categorization of validator nodes based on their function in the consensus mechanism and their operational characteristics.
|
||||
|
||||
## Key Use Cases
|
||||
|
||||
- **Validator Identification**: Identifying and categorizing validator nodes by type and role in the network
|
||||
- **Governance Analysis**: Understanding the distribution of validator types and their impact on network security
|
||||
- **Network Architecture**: Analyzing the composition of the Flow blockchain's multi-role validator system
|
||||
- **Project Attribution**: Identifying which organizations or projects operate specific validator nodes
|
||||
- **Staking Analysis**: Supporting staking operations by providing validator metadata for delegation decisions
|
||||
- **Network Health Monitoring**: Tracking validator distribution and identifying potential centralization risks
|
||||
|
||||
## Important Relationships
|
||||
|
||||
- **gov__ez_staking_actions**: Links to staking transactions involving these validator nodes
|
||||
- **core__fact_transactions**: May link to validator-related transactions for additional context
|
||||
- **core__dim_contract_labels**: May provide additional labeling for validator contracts
|
||||
- **core__fact_events**: May link to validator-related events for governance analysis
|
||||
- **evm/core_evm__dim_contracts**: For EVM-based validators, provides additional contract metadata
|
||||
|
||||
## Commonly-used Fields
|
||||
|
||||
- **NODE_ID**: Primary identifier for validator nodes and staking operations
|
||||
- **VALIDATOR_TYPE**: Essential for understanding validator roles and network architecture
|
||||
- **PROJECT_NAME**: Important for governance transparency and validator operator identification
|
||||
|
||||
{% enddocs %}
|
||||
33
models/descriptions/tables/gov__ez_staking_actions.md
Normal file
33
models/descriptions/tables/gov__ez_staking_actions.md
Normal file
@ -0,0 +1,33 @@
|
||||
{% docs gov__ez_staking_actions %}
|
||||
# gov__ez_staking_actions
|
||||
|
||||
## Description
|
||||
|
||||
A fact table containing transaction-level information on FLOW staking activities within the governance system. This table tracks all staking-related actions including delegation, undelegation, and reward collection operations. Each record represents a specific staking action with detailed metadata about the delegator, validator node, action type, and amount involved. The table serves as the primary source for staking analytics and governance participation analysis in the Flow ecosystem.
|
||||
|
||||
## Key Use Cases
|
||||
|
||||
- **Staking Analysis**: Tracking delegation and undelegation patterns across the Flow network
|
||||
- **Governance Participation**: Understanding user engagement in the staking ecosystem
|
||||
- **Validator Performance**: Analyzing validator attractiveness and delegation trends
|
||||
- **Reward Distribution**: Monitoring staking rewards and their distribution patterns
|
||||
- **Network Security**: Understanding the distribution of staked FLOW and its impact on network security
|
||||
- **User Behavior Analysis**: Identifying patterns in how users interact with the staking system
|
||||
|
||||
## Important Relationships
|
||||
|
||||
- **gov__dim_validator_labels**: Links to validator metadata for node analysis and categorization
|
||||
- **core__fact_transactions**: Provides additional transaction context and blockchain data
|
||||
- **core__fact_events**: May link to staking-related events for detailed governance analysis
|
||||
- **core__dim_address_mapping**: Provides additional user context for delegator analysis
|
||||
- **price__ez_prices_hourly**: May link to FLOW price data for staking value analysis
|
||||
|
||||
## Commonly-used Fields
|
||||
|
||||
- **TX_ID**: Primary identifier for linking to blockchain transactions and audit trails
|
||||
- **DELEGATOR**: User account address for delegator identification and behavior analysis
|
||||
- **NODE_ID**: Validator node identifier for validator-specific analysis
|
||||
- **ACTION**: Staking operation type for transaction categorization and analysis
|
||||
- **AMOUNT**: Staking amount for value analysis and volume tracking
|
||||
- **BLOCK_TIMESTAMP**: Temporal reference for chronological analysis and time-series tracking
|
||||
{% enddocs %}
|
||||
28
models/descriptions/tables/nft__dim_allday_metadata.md
Normal file
28
models/descriptions/tables/nft__dim_allday_metadata.md
Normal file
@ -0,0 +1,28 @@
|
||||
{% docs nft__dim_allday_metadata %}
|
||||
## Description
|
||||
Comprehensive metadata for NFL All Day Moments, including player information, team details, statistics, and rich content data. This table is produced via API integration and provides detailed information about each NFL All Day NFT moment, including play descriptions, video URLs, and comprehensive statistics. The data structure may differ from on-chain metadata available in other tables, providing a more complete and curated view of NFL All Day moments.
|
||||
|
||||
## Key Use Cases
|
||||
- Analyze NFL All Day moment performance and market activity
|
||||
- Track player and team-based NFT analytics
|
||||
- Power NFL All Day dashboards and user-facing applications
|
||||
- Support content discovery and moment exploration
|
||||
- Enable player and team-based market analysis
|
||||
|
||||
## Important Relationships
|
||||
- Can be joined with `nft__ez_nft_sales` for sales analytics
|
||||
- Links to `nft__dim_moment_metadata` for on-chain data comparison
|
||||
- Player and team data enables cross-platform athlete analysis
|
||||
- NFL All Day ID enables direct marketplace integration
|
||||
|
||||
## Commonly-used Fields
|
||||
- `nft_id`: Unique identifier for the NFL All Day moment
|
||||
- `nflallday_id`: Official NFL All Day identifier for marketplace integration
|
||||
- `player`: Athlete featured in the moment
|
||||
- `team`: Team affiliation at time of moment
|
||||
- `season`: NFL season when moment occurred
|
||||
- `set_name`: Collection set name for organization
|
||||
- `total_circulation`: Maximum supply for rarity analysis
|
||||
- `moment_description`: Detailed play description
|
||||
|
||||
{% enddocs %}
|
||||
27
models/descriptions/tables/nft__dim_moment_metadata.md
Normal file
27
models/descriptions/tables/nft__dim_moment_metadata.md
Normal file
@ -0,0 +1,27 @@
|
||||
{% docs nft__dim_moment_metadata %}
|
||||
## Description
|
||||
NFT moment metadata scraped from on-chain activity across multiple Flow NFT projects. This table captures metadata that is stored directly on the blockchain when moments are minted, providing a decentralized source of NFT information. The table supports multiple NFT collections including All Day, TopShot, and Golazos, with comprehensive metadata including play details, series information, and collection hierarchy.
|
||||
|
||||
## Key Use Cases
|
||||
- Analyze on-chain NFT metadata across multiple collections
|
||||
- Track moment creation and minting activity
|
||||
- Support cross-collection NFT analytics
|
||||
- Enable decentralized metadata verification
|
||||
- Power NFT explorer and discovery tools
|
||||
|
||||
## Important Relationships
|
||||
- Can be joined with `nft__ez_nft_sales` for sales analytics
|
||||
- Links to `nft__dim_allday_metadata` and `nft__dim_topshot_metadata` for enriched data
|
||||
- NFT collection and ID enable cross-table joins
|
||||
- Supports multiple NFT projects on Flow
|
||||
|
||||
## Commonly-used Fields
|
||||
- `nft_collection`: Contract address of the NFT collection
|
||||
- `nft_id`: Unique identifier for the NFT moment
|
||||
- `serial_number`: Edition number within the collection
|
||||
- `set_name`: Name of the set containing the moment
|
||||
- `series_name`: Series name for organizational hierarchy
|
||||
- `metadata`: JSON object containing detailed moment information
|
||||
- `tier`: Rarity tier classification
|
||||
|
||||
{% enddocs %}
|
||||
30
models/descriptions/tables/nft__dim_topshot_metadata.md
Normal file
30
models/descriptions/tables/nft__dim_topshot_metadata.md
Normal file
@ -0,0 +1,30 @@
|
||||
{% docs nft__dim_topshot_metadata %}
|
||||
## Description
|
||||
Comprehensive metadata for NBA TopShot Moments, including player information, team details, statistics, and rich content data. This table is produced via API integration and provides detailed information about each NBA TopShot NFT moment, including play descriptions, video URLs, and comprehensive player statistics. The data structure may differ from on-chain metadata, providing a more complete and curated view of NBA TopShot moments with enhanced statistical information.
|
||||
|
||||
## Key Use Cases
|
||||
- Analyze NBA TopShot moment performance and market activity
|
||||
- Track player and team-based NFT analytics
|
||||
- Power NBA TopShot dashboards and user-facing applications
|
||||
- Support content discovery and moment exploration
|
||||
- Enable player performance correlation with NFT values
|
||||
|
||||
## Important Relationships
|
||||
- Can be joined with `nft__ez_nft_sales` for sales analytics
|
||||
- Links to `nft__dim_moment_metadata` for on-chain data comparison
|
||||
- Player and team data enables cross-platform athlete analysis
|
||||
- NBA TopShot ID enables direct marketplace integration
|
||||
- Used by `nft__fact_topshot_buybacks` for buyback analytics
|
||||
|
||||
## Commonly-used Fields
|
||||
- `nft_id`: Unique identifier for the NBA TopShot moment
|
||||
- `nbatopshot_id`: Official NBA TopShot identifier for marketplace integration
|
||||
- `player`: Athlete featured in the moment
|
||||
- `team`: Team affiliation at time of moment
|
||||
- `season`: NBA season when moment occurred
|
||||
- `set_name`: Collection set name for organization
|
||||
- `total_circulation`: Maximum supply for rarity analysis
|
||||
- `moment_description`: Detailed play description
|
||||
- `player_stats_game`: Game-specific player statistics
|
||||
|
||||
{% enddocs %}
|
||||
26
models/descriptions/tables/nft__dim_ufc_strike_metadata.md
Normal file
26
models/descriptions/tables/nft__dim_ufc_strike_metadata.md
Normal file
@ -0,0 +1,26 @@
|
||||
{% docs nft__dim_ufc_strike_metadata %}
|
||||
## Description
|
||||
Metadata for UFC Strike NFTs, capturing information about UFC-themed digital collectibles on the Flow blockchain. This table provides comprehensive metadata for UFC Strike moments, including set information, listing details, and rich content data. The table supports UFC Strike marketplace integration and enables analysis of UFC-themed NFT performance and market activity.
|
||||
|
||||
## Key Use Cases
|
||||
- Analyze UFC Strike NFT performance and market activity
|
||||
- Track UFC-themed digital collectible analytics
|
||||
- Power UFC Strike dashboards and user-facing applications
|
||||
- Support content discovery and moment exploration
|
||||
- Enable UFC event correlation with NFT values
|
||||
|
||||
## Important Relationships
|
||||
- Can be joined with `nft__ez_nft_sales` for sales analytics
|
||||
- Links to other NFT metadata tables for cross-collection analysis
|
||||
- UFC Strike ID enables direct marketplace integration
|
||||
- Supports UFC-themed NFT ecosystem analysis
|
||||
|
||||
## Commonly-used Fields
|
||||
- `nft_id`: Unique identifier for the UFC Strike moment
|
||||
- `serial_number`: Edition number within the collection
|
||||
- `listing_id`: Marketplace listing identifier
|
||||
- `set_name`: Name of the UFC Strike set
|
||||
- `set_description`: Detailed description of the set
|
||||
- `metadata`: JSON object containing detailed moment information
|
||||
|
||||
{% enddocs %}
|
||||
29
models/descriptions/tables/nft__ez_nft_sales.md
Normal file
29
models/descriptions/tables/nft__ez_nft_sales.md
Normal file
@ -0,0 +1,29 @@
|
||||
{% docs nft__ez_nft_sales %}
|
||||
## Description
|
||||
Comprehensive view of all NFT marketplace sales on the Flow blockchain, providing a unified interface for NFT trading activity across multiple marketplaces and collections. This table captures sales from the primary NFT Marketplace contract, Fabricant NFT Marketplace, NBA TopShot primary market, and other supported marketplaces. The table includes transaction details, pricing information, and marketplace attribution, enabling cross-platform NFT sales analysis.
|
||||
|
||||
## Key Use Cases
|
||||
- Analyze NFT sales activity across multiple marketplaces
|
||||
- Track collection and marketplace performance
|
||||
- Power NFT market dashboards and analytics
|
||||
- Support price analysis and market trends
|
||||
- Enable cross-collection and cross-marketplace comparisons
|
||||
|
||||
## Important Relationships
|
||||
- Sources data from `silver__nft_sales_s` for unified sales data
|
||||
- Can be joined with metadata tables (`nft__dim_allday_metadata`, `nft__dim_topshot_metadata`, etc.) for enriched analytics
|
||||
- Links to `nft__fact_topshot_buybacks` for buyback program analysis
|
||||
- Supports multiple NFT collections and marketplaces
|
||||
|
||||
## Commonly-used Fields
|
||||
- `tx_id`: Unique transaction identifier for the sale
|
||||
- `block_timestamp`: When the sale transaction occurred
|
||||
- `marketplace`: Name of the marketplace where sale occurred
|
||||
- `nft_collection`: Contract address of the NFT collection
|
||||
- `nft_id`: Unique identifier for the NFT sold
|
||||
- `buyer`: Address of the buyer
|
||||
- `seller`: Address of the seller
|
||||
- `price`: Sale price in the specified currency
|
||||
- `currency`: Currency used for the transaction
|
||||
|
||||
{% enddocs %}
|
||||
29
models/descriptions/tables/nft__fact_topshot_buybacks.md
Normal file
29
models/descriptions/tables/nft__fact_topshot_buybacks.md
Normal file
@ -0,0 +1,29 @@
|
||||
{% docs nft__fact_topshot_buybacks %}
|
||||
## Description
|
||||
Records all NBA TopShot buyback transactions where the official TopShot buyback wallet purchases moments from users. This table combines sales data from both the standard TopShot marketplace and Flowty, tracking the buyback program's activity with running totals of amounts spent over time. The table includes enriched metadata from both TopShot and on-chain sources, providing comprehensive tracking of the buyback program's market impact and spending patterns.
|
||||
|
||||
## Key Use Cases
|
||||
- Track TopShot buyback program spending and activity
|
||||
- Analyze buyback market impact on moment prices
|
||||
- Monitor buyback wallet behavior and patterns
|
||||
- Support TopShot market analysis and reporting
|
||||
- Enable buyback program performance analytics
|
||||
|
||||
## Important Relationships
|
||||
- Sources data from `nft__ez_nft_sales` for marketplace transactions
|
||||
- Joins with `nft__dim_topshot_metadata` for enriched moment data
|
||||
- Links to `nft__dim_moment_metadata` for on-chain metadata
|
||||
- Filters for specific buyback wallet address (0xe1f2a091f7bb5245)
|
||||
|
||||
## Commonly-used Fields
|
||||
- `tx_id`: Unique transaction identifier for buyback event
|
||||
- `block_timestamp`: When the buyback transaction occurred
|
||||
- `nft_id`: TopShot moment identifier
|
||||
- `player`: Athlete featured in the bought moment
|
||||
- `team`: Team affiliation at time of moment
|
||||
- `price`: USD price paid for the moment
|
||||
- `total`: Running total of all buyback purchases
|
||||
- `buyer`: TopShot buyback wallet address
|
||||
- `seller`: Original moment owner
|
||||
|
||||
{% enddocs %}
|
||||
33
models/descriptions/tables/price__dim_asset_metadata.md
Normal file
33
models/descriptions/tables/price__dim_asset_metadata.md
Normal file
@ -0,0 +1,33 @@
|
||||
{% docs price__dim_asset_metadata %}
|
||||
# price__dim_asset_metadata
|
||||
|
||||
## Description
|
||||
|
||||
A comprehensive dimensional table containing raw asset metadata from multiple price providers. This table serves as the foundation for asset identification and metadata management across different blockchain networks and price data sources. It contains uncurated, provider-specific data that may include duplicates, inconsistencies, and data quality issues inherent to the source APIs. The table maintains the original provider structure to preserve data lineage and enable source-specific analysis.
|
||||
|
||||
## Key Use Cases
|
||||
|
||||
- **Asset Discovery and Identification**: Finding all available assets across different price providers and blockchain networks
|
||||
- **Data Quality Analysis**: Identifying inconsistencies, duplicates, and gaps in asset metadata across providers
|
||||
- **Provider Comparison**: Analyzing how different price providers categorize and describe the same assets
|
||||
- **Cross-Chain Asset Mapping**: Understanding how assets are represented across different blockchain networks
|
||||
- **Data Lineage Tracking**: Maintaining audit trails for asset metadata changes and provider updates
|
||||
- **Raw Data Access**: Providing access to unprocessed asset metadata for custom curation and analysis
|
||||
|
||||
## Important Relationships
|
||||
|
||||
- **price__ez_asset_metadata**: Curated, deduplicated version of this table with one record per unique asset
|
||||
- **price__fact_prices_ohlc_hourly**: Links to price data through asset_id and provider
|
||||
- **price__ez_prices_hourly**: Provides curated price data for assets in this dimension
|
||||
- **core__dim_contract_labels**: May overlap with contract-based assets for additional labeling
|
||||
- **evm/core_evm__dim_contracts**: For EVM-based tokens, provides additional contract metadata
|
||||
|
||||
## Commonly-used Fields
|
||||
|
||||
- **PROVIDER**: Essential for filtering by data source and understanding data provenance
|
||||
- **ASSET_ID**: Primary identifier for joining with price fact tables and other asset-related data
|
||||
- **TOKEN_ADDRESS**: Critical for blockchain-specific operations and smart contract interactions
|
||||
- **BLOCKCHAIN**: Key for cross-chain analysis and blockchain-specific filtering
|
||||
- **SYMBOL**: Commonly used for asset identification in reports and dashboards
|
||||
- **NAME**: Human-readable asset name for display and reporting purposes
|
||||
{% enddocs %}
|
||||
33
models/descriptions/tables/price__ez_asset_metadata.md
Normal file
33
models/descriptions/tables/price__ez_asset_metadata.md
Normal file
@ -0,0 +1,33 @@
|
||||
{% docs price__ez_asset_metadata %}
|
||||
# price__ez_asset_metadata
|
||||
|
||||
## Description
|
||||
|
||||
A curated and deduplicated asset metadata table that provides a single source of truth for asset information across different blockchain networks. This table consolidates data from multiple price providers, resolving conflicts and maintaining one record per unique asset per blockchain. It serves as the primary dimension table for asset identification in price analytics and provides clean, reliable metadata for reporting and analysis. The table prioritizes data quality and consistency over raw data preservation.
|
||||
|
||||
## Key Use Cases
|
||||
|
||||
- **Asset Reference**: Primary lookup table for asset metadata in price analytics and reporting
|
||||
- **Portfolio Management**: Providing consistent asset information for multi-asset portfolio tracking
|
||||
- **Price Analysis**: Joining with price fact tables for comprehensive asset price analysis
|
||||
- **Cross-Chain Analytics**: Understanding asset distribution and characteristics across blockchain networks
|
||||
- **Reporting and Dashboards**: Providing clean, consistent asset names and symbols for user interfaces
|
||||
- **Data Quality Assurance**: Ensuring consistent asset representation across different data sources
|
||||
|
||||
## Important Relationships
|
||||
|
||||
- **price__dim_asset_metadata**: Raw source data that feeds into this curated table
|
||||
- **price__fact_prices_ohlc_hourly**: Links to raw price data through asset_id
|
||||
- **price__ez_prices_hourly**: Primary price table that uses this for asset metadata
|
||||
- **core__dim_contract_labels**: Provides additional labeling for contract-based assets
|
||||
- **evm/core_evm__dim_contracts**: For EVM tokens, provides additional contract-level metadata
|
||||
|
||||
## Commonly-used Fields
|
||||
|
||||
- **TOKEN_ADDRESS**: Primary identifier for blockchain-specific operations and smart contract interactions
|
||||
- **SYMBOL**: Most commonly used field for asset identification in reports and dashboards
|
||||
- **NAME**: Human-readable asset name for display and user interfaces
|
||||
- **BLOCKCHAIN**: Essential for cross-chain analysis and blockchain-specific filtering
|
||||
- **DECIMALS**: Critical for accurate price calculations and token amount conversions
|
||||
- **IS_NATIVE**: Important for distinguishing native blockchain tokens from smart contract tokens
|
||||
{% enddocs %}
|
||||
33
models/descriptions/tables/price__ez_prices_hourly.md
Normal file
33
models/descriptions/tables/price__ez_prices_hourly.md
Normal file
@ -0,0 +1,33 @@
|
||||
{% docs price__ez_prices_hourly %}
|
||||
# price__ez_prices_hourly
|
||||
|
||||
## Description
|
||||
|
||||
A curated and deduplicated hourly price table that provides a single source of truth for asset prices across different blockchain networks. This table consolidates price data from multiple providers, resolving conflicts and maintaining one price per unique asset per hour. It serves as the primary price table for analytics, reporting, and portfolio management, providing clean, reliable price data that prioritizes data quality and consistency. The table includes comprehensive asset metadata for easy analysis and reporting.
|
||||
|
||||
## Key Use Cases
|
||||
|
||||
- **Portfolio Valuation**: Calculating current and historical portfolio values across multiple assets
|
||||
- **Price Analysis**: Conducting price trend analysis and market performance evaluation
|
||||
- **Cross-Chain Analytics**: Comparing asset performance across different blockchain networks
|
||||
- **Reporting and Dashboards**: Providing clean price data for user interfaces and automated reporting
|
||||
- **Risk Management**: Monitoring price movements and calculating risk metrics
|
||||
- **Trading Operations**: Supporting trading decisions with reliable price data
|
||||
|
||||
## Important Relationships
|
||||
|
||||
- **price__fact_prices_ohlc_hourly**: Raw source data that feeds into this curated table
|
||||
- **price__ez_asset_metadata**: Provides comprehensive asset metadata for analysis
|
||||
- **price__dim_asset_metadata**: Raw asset metadata source for additional provider-specific information
|
||||
- **core__fact_transactions**: For transaction value analysis and price impact correlation studies
|
||||
- **defi__fact_dex_swaps**: For DeFi trading analysis and price impact on swap volumes
|
||||
|
||||
## Commonly-used Fields
|
||||
|
||||
- **HOUR**: Essential for time-series analysis and temporal data aggregation
|
||||
- **TOKEN_ADDRESS**: Primary identifier for blockchain-specific operations and smart contract interactions
|
||||
- **SYMBOL**: Most commonly used field for asset identification in reports and dashboards
|
||||
- **PRICE**: Core price field used for valuation, analysis, and reporting
|
||||
- **BLOCKCHAIN**: Essential for cross-chain analysis and blockchain-specific filtering
|
||||
- **IS_IMPUTED**: Important for data quality assessment and filtering potentially unreliable prices
|
||||
{% enddocs %}
|
||||
33
models/descriptions/tables/price__fact_prices_ohlc_hourly.md
Normal file
33
models/descriptions/tables/price__fact_prices_ohlc_hourly.md
Normal file
@ -0,0 +1,33 @@
|
||||
{% docs price__fact_prices_ohlc_hourly %}
|
||||
# price__fact_prices_ohlc_hourly
|
||||
|
||||
## Description
|
||||
|
||||
A comprehensive fact table containing raw OHLC (Open, High, Low, Close) price data at hourly intervals from multiple price providers. This table preserves the original provider structure and contains uncurated price data that may include duplicates, inconsistencies, and data quality issues inherent to the source APIs. It serves as the foundation for price analysis while maintaining data lineage and enabling provider-specific analysis. The table supports detailed price movement analysis and technical indicator calculations.
|
||||
|
||||
## Key Use Cases
|
||||
|
||||
- **Technical Analysis**: Calculating technical indicators, support/resistance levels, and price patterns
|
||||
- **Volatility Analysis**: Measuring price volatility and risk metrics across different time periods
|
||||
- **Provider Comparison**: Analyzing price differences and data quality across different price providers
|
||||
- **Data Quality Assessment**: Identifying gaps, anomalies, and inconsistencies in price data
|
||||
- **Raw Data Access**: Providing access to unprocessed price data for custom analysis and backtesting
|
||||
- **Historical Price Analysis**: Conducting detailed historical price movement analysis and research
|
||||
|
||||
## Important Relationships
|
||||
|
||||
- **price__dim_asset_metadata**: Links to asset metadata through asset_id and provider
|
||||
- **price__ez_asset_metadata**: Provides curated asset information for analysis
|
||||
- **price__ez_prices_hourly**: Curated, deduplicated version of this table with one price per asset per hour
|
||||
- **core__fact_blocks**: May be used for blockchain-specific price analysis and correlation studies
|
||||
- **core__fact_transactions**: For transaction value analysis and price impact studies
|
||||
|
||||
## Commonly-used Fields
|
||||
|
||||
- **HOUR**: Essential for time-series analysis and temporal data aggregation
|
||||
- **ASSET_ID**: Primary identifier for joining with asset metadata and other price-related data
|
||||
- **OPEN**: Starting price for the hour, used in OHLC analysis and trend calculations
|
||||
- **HIGH**: Maximum price during the hour, important for resistance level analysis
|
||||
- **LOW**: Minimum price during the hour, important for support level analysis
|
||||
- **CLOSE**: Ending price for the hour, most commonly used for price trend analysis
|
||||
{% enddocs %}
|
||||
33
models/descriptions/tables/rewards__dim_storefront_items.md
Normal file
33
models/descriptions/tables/rewards__dim_storefront_items.md
Normal file
@ -0,0 +1,33 @@
|
||||
{% docs rewards__dim_storefront_items %}
|
||||
# rewards__dim_storefront_items
|
||||
|
||||
## Description
|
||||
|
||||
A comprehensive dimensional table containing storefront item metadata from the Minting Assets API. This table serves as the foundation for understanding the rewards storefront inventory, including NFTs, physical items, and digital assets available for purchase with reward points. It contains detailed information about item characteristics, pricing, availability, and redemption mechanics. The table supports the rewards ecosystem by providing item metadata for storefront operations and user experience.
|
||||
|
||||
## Key Use Cases
|
||||
|
||||
- **Storefront Management**: Understanding available items, pricing, and inventory levels in the rewards storefront
|
||||
- **Item Discovery**: Finding items by category, price range, or availability status
|
||||
- **Redemption Analysis**: Tracking item redemption patterns and user preferences
|
||||
- **Inventory Planning**: Monitoring item quantities, minting status, and supply management
|
||||
- **User Experience**: Providing item details, images, and metadata for storefront displays
|
||||
- **Reward Program Optimization**: Analyzing which items drive user engagement and point spending
|
||||
|
||||
## Important Relationships
|
||||
|
||||
- **rewards__fact_points_balances**: Links to user point balances for purchase eligibility analysis
|
||||
- **rewards__fact_points_transfers**: Tracks point spending on storefront purchases
|
||||
- **rewards__fact_transaction_entries**: Provides detailed transaction history for item purchases
|
||||
- **nft__dim_moment_metadata**: May overlap with NFT items for additional metadata
|
||||
- **core__dim_contract_labels**: For contract-based items, provides additional labeling
|
||||
|
||||
## Commonly-used Fields
|
||||
|
||||
- **ITEM_ID**: Primary identifier for storefront items and purchase tracking
|
||||
- **NAME**: Human-readable item name for display and reporting
|
||||
- **PRICE**: Item cost in reward points or currency for purchase analysis
|
||||
- **QUANTITY**: Available inventory for supply management and availability tracking
|
||||
- **MINT_STATUS**: Current minting status for understanding item availability
|
||||
- **IS_LISTED**: Flag indicating whether item is currently available for purchase
|
||||
{% enddocs %}
|
||||
33
models/descriptions/tables/rewards__fact_points_balances.md
Normal file
33
models/descriptions/tables/rewards__fact_points_balances.md
Normal file
@ -0,0 +1,33 @@
|
||||
{% docs rewards__fact_points_balances %}
|
||||
# rewards__fact_points_balances
|
||||
|
||||
## Description
|
||||
|
||||
A fact table containing point-in-time balances for user reward accounts from the Reward Points API. This table provides snapshots of user balances including points, boxes, and keys at specific request dates. The data represents balance states rather than transaction flows, with early data potentially being patchy due to API limitations. The table supports reward program analytics by providing current and historical balance information for user engagement analysis and program performance tracking.
|
||||
|
||||
## Key Use Cases
|
||||
|
||||
- **Balance Tracking**: Monitoring current and historical user reward balances across different asset types
|
||||
- **User Engagement Analysis**: Understanding user participation levels and reward accumulation patterns
|
||||
- **Program Performance**: Analyzing reward program effectiveness and user retention
|
||||
- **Balance Reconciliation**: Verifying account balances and identifying data quality issues
|
||||
- **Reward Distribution Analysis**: Understanding how rewards are distributed across the user base
|
||||
- **Predictive Analytics**: Using balance patterns to predict user behavior and program outcomes
|
||||
|
||||
## Important Relationships
|
||||
|
||||
- **rewards__fact_points_transfers**: Provides transaction history that explains balance changes
|
||||
- **rewards__fact_transaction_entries**: Offers detailed transaction-level data for balance reconciliation
|
||||
- **rewards__dim_storefront_items**: Links to items that can be purchased with accumulated points
|
||||
- **core__dim_address_mapping**: May link to user addresses for additional user context
|
||||
- **evm/core_evm__dim_contracts**: For contract-based reward systems, provides contract metadata
|
||||
|
||||
## Commonly-used Fields
|
||||
|
||||
- **ADDRESS**: Primary identifier for user accounts and balance tracking
|
||||
- **POINTS**: Core reward currency balance for program analysis
|
||||
- **BOXES**: Special reward item balance for gamification analysis
|
||||
- **KEYS**: Special reward item balance for access control analysis
|
||||
- **REQUEST_DATE**: Temporal reference for balance snapshots and time-series analysis
|
||||
- **BOXES_OPENED**: Historical metric for user engagement and reward consumption
|
||||
{% enddocs %}
|
||||
34
models/descriptions/tables/rewards__fact_points_transfers.md
Normal file
34
models/descriptions/tables/rewards__fact_points_transfers.md
Normal file
@ -0,0 +1,34 @@
|
||||
{% docs rewards__fact_points_transfers %}
|
||||
# rewards__fact_points_transfers
|
||||
|
||||
## Description
|
||||
|
||||
A fact table containing reward points transfer transactions from the Reward Points API Transfers Endpoint. This table tracks the movement of points, boxes, and keys between user accounts in batch transfer operations. Each transfer is organized within batches and includes detailed metadata about the sending and receiving accounts. The table provides the transaction-level foundation for understanding reward flows, user interactions, and program participation patterns.
|
||||
|
||||
## Key Use Cases
|
||||
|
||||
- **Transfer Tracking**: Monitoring reward point movements between user accounts and system operations
|
||||
- **Batch Analysis**: Understanding transfer batch operations and their impact on the reward system
|
||||
- **User Interaction Analysis**: Identifying patterns in how users transfer rewards to each other
|
||||
- **Program Participation**: Measuring user engagement through transfer activity
|
||||
- **Audit and Compliance**: Maintaining detailed records of all reward transfers for regulatory and internal audit purposes
|
||||
- **Network Analysis**: Understanding reward flow patterns and identifying key users in the reward ecosystem
|
||||
|
||||
## Important Relationships
|
||||
|
||||
- **rewards__fact_points_balances**: Links to account balances that are affected by these transfers
|
||||
- **rewards__fact_transaction_entries**: Provides more granular transaction details for transfer analysis
|
||||
- **rewards__dim_storefront_items**: May link to items purchased with transferred points
|
||||
- **core__dim_address_mapping**: Provides additional user context for transfer analysis
|
||||
- **evm/core_evm__dim_contracts**: For contract-based transfers, provides contract metadata
|
||||
|
||||
## Commonly-used Fields
|
||||
|
||||
- **BATCH_ID**: Primary identifier for grouping related transfers in batch operations
|
||||
- **FROM_ADDRESS**: Source account for transfer tracking and user behavior analysis
|
||||
- **TO_ADDRESS**: Destination account for transfer tracking and user behavior analysis
|
||||
- **POINTS**: Core reward currency transferred for value analysis
|
||||
- **BOXES**: Special reward items transferred for gamification analysis
|
||||
- **KEYS**: Special reward items transferred for access control analysis
|
||||
- **CREATED_AT**: Temporal reference for transfer timing and chronological analysis
|
||||
{% enddocs %}
|
||||
@ -0,0 +1,34 @@
|
||||
{% docs rewards__fact_transaction_entries %}
|
||||
# rewards__fact_transaction_entries
|
||||
|
||||
## Description
|
||||
|
||||
A fact table containing individual Flow points transfer events flattened from responses from the Snag transaction entries endpoint. This table provides the most granular level of transaction detail in the rewards system, tracking individual entry-level transactions with balance state information. Each record represents a single transaction entry with before and after balance states, enabling detailed audit trails and transaction-level analysis. The table serves as the foundation for understanding reward system operations at the most detailed level.
|
||||
|
||||
## Key Use Cases
|
||||
|
||||
- **Transaction Analysis**: Examining individual reward transactions for detailed audit and analysis
|
||||
- **Balance Reconciliation**: Verifying account balance changes through detailed transaction records
|
||||
- **Audit Trails**: Maintaining comprehensive records of all reward system activities
|
||||
- **User Behavior Analysis**: Understanding detailed patterns in how users interact with the reward system
|
||||
- **System Performance**: Monitoring transaction processing and identifying potential issues
|
||||
- **Compliance Reporting**: Providing detailed transaction records for regulatory and internal compliance
|
||||
|
||||
## Important Relationships
|
||||
|
||||
- **rewards__fact_points_balances**: Links to account balances that are affected by these transactions
|
||||
- **rewards__fact_points_transfers**: Provides batch-level context for individual transaction entries
|
||||
- **rewards__dim_storefront_items**: May link to items involved in transaction entries
|
||||
- **core__fact_transactions**: May link to underlying blockchain transactions for additional context
|
||||
- **core__dim_address_mapping**: Provides user context for transaction analysis
|
||||
|
||||
## Commonly-used Fields
|
||||
|
||||
- **ENTRY_ID**: Primary identifier for individual transaction entries and audit trails
|
||||
- **ACCOUNT_ID**: User account identifier for transaction attribution and analysis
|
||||
- **USER_WALLET_ADDRESS**: Blockchain address for cross-system analysis and user identification
|
||||
- **DIRECTION**: Transaction direction (credit/debit) for understanding reward flows
|
||||
- **AMOUNT**: Transaction value for financial analysis and volume tracking
|
||||
- **AMOUNT_START/AMOUNT_END**: Balance state information for transaction validation and audit
|
||||
- **CREATED_AT**: Temporal reference for transaction timing and chronological analysis
|
||||
{% enddocs %}
|
||||
33
models/descriptions/tables/stats__ez_core_metrics_hourly.md
Normal file
33
models/descriptions/tables/stats__ez_core_metrics_hourly.md
Normal file
@ -0,0 +1,33 @@
|
||||
{% docs stats__ez_core_metrics_hourly %}
|
||||
|
||||
## Description
|
||||
|
||||
A comprehensive metrics table that aggregates core blockchain performance indicators on an hourly basis. This table provides key network health and performance metrics including block counts, transaction volumes, success rates, user activity, and fee collection data. The metrics are calculated using various aggregate functions (SUM, COUNT, MIN, MAX) from the core fact tables and are updated as new data arrives. This table serves as the primary source for network performance monitoring, trend analysis, and blockchain health assessment.
|
||||
|
||||
## Key Use Cases
|
||||
|
||||
- **Network Performance Monitoring**: Tracking blockchain throughput, transaction processing rates, and network efficiency
|
||||
- **Health Assessment**: Monitoring transaction success rates, failure patterns, and network reliability
|
||||
- **User Activity Analysis**: Understanding user engagement levels and network participation patterns
|
||||
- **Economic Analysis**: Tracking fee collection, revenue generation, and network economics
|
||||
- **Trend Analysis**: Identifying performance trends, seasonal patterns, and growth indicators
|
||||
- **Alerting and Monitoring**: Supporting automated monitoring systems for network health and performance
|
||||
|
||||
## Important Relationships
|
||||
|
||||
- **core__fact_blocks**: Source data for block-related metrics and block range analysis
|
||||
- **core__fact_transactions**: Source data for transaction counts, success rates, and user activity metrics
|
||||
- **core__fact_events**: May provide additional context for transaction analysis
|
||||
- **price__ez_prices_hourly**: May link to FLOW price data for fee value analysis
|
||||
- **silver_stats__core_metrics_hourly**: May provide additional statistical context and validation
|
||||
|
||||
## Commonly-used Fields
|
||||
|
||||
- **BLOCK_TIMESTAMP_HOUR**: Essential for time-series analysis and temporal data aggregation
|
||||
- **TRANSACTION_COUNT**: Core metric for network activity and throughput analysis
|
||||
- **TRANSACTION_COUNT_SUCCESS/FAILED**: Critical for network health and reliability assessment
|
||||
- **UNIQUE_FROM_COUNT/PAYER_COUNT**: Important for user activity and network participation analysis
|
||||
- **TOTAL_FEES_NATIVE/USD**: Key for network economics and revenue analysis
|
||||
- **BLOCK_COUNT**: Fundamental metric for blockchain throughput and performance
|
||||
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,5 @@
|
||||
{% docs team %}
|
||||
|
||||
The team that the player from the moment is on, at the time of the moment.
|
||||
The sports team that the player represented at the time the NFT moment was captured. Data type: STRING. This field identifies the team affiliation of the featured player, enabling team-level analytics, regional market analysis, and team performance correlation with NFT values. Used for team attribution, regional market analysis, and team-based fan engagement tracking. Example: 'Los Angeles Lakers' for NBA TopShot, 'Tampa Bay Buccaneers' for NFL All Day. Important for team-based analytics, regional market insights, and team performance correlation with NFT market activity.
|
||||
|
||||
{% enddocs %}
|
||||
@ -1,5 +1,3 @@
|
||||
{% docs token_contract %}
|
||||
|
||||
The contract address for a token on the Flow blockchain.
|
||||
|
||||
The Flow contract address for the token involved in the transaction. Data type: STRING. Used to identify the specific fungible or non-fungible token being transferred, swapped, or bridged. Example: 'A.1654653399040a61.FlowToken'. Important for token-level analytics, filtering, and protocol attribution.
|
||||
{% enddocs %}
|
||||
@ -1,7 +1,4 @@
|
||||
{% docs token_in_amount %}
|
||||
|
||||
The amount of the token being swapped that the trader is receiving from the pool (buying).
|
||||
Token OUT / IN is from the perspective of the trader. So, an out token is leaving the wallet while the in token is being deposited to the wallet. This perspective is not changing for multi-pool trades - think of it directionally, the tokens continue flowing from out to in. Out of wallet, into pool, out of pool, into (another pool / wallet), with the final movement being tokens into final wallet.
|
||||
|
||||
The amount of tokens received by the trader (or next pool) in a DEX swap. Data type: NUMBER (decimal adjusted). Represents the quantity of the "in" token in the swap, from the trader's perspective. Used for volume analysis, price impact, and swap path tracing. Example: 49.5 (for 49.5 tokens received). Directionality is always from the pool to the trader or next hop in multi-pool swaps.
|
||||
{% enddocs %}
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user