Flipside Docs
  • Welcome to Flipside!
    • Welcome to Flipside
    • Growth Services
    • Data
      • Choose your Flipside plan
        • Free
        • Builder
        • Pro
          • Get Started in Snowflake
          • Incremental Table Pattern
          • Copy Data from Snowflake to AWS
          • Copy Data from Snowflake to GCP
          • Copy Data from Snowflake to Azure
        • Snowflake Data Shares
          • Mounting a Snowflake Data Share
    • Earn
    • Community
  • Data
    • Flipside Data
      • Table Docs by Chain
      • Data Modeling Approach
      • Labels
        • Centralized Exchange Label Type
        • Decentralized Exchange Label Type
        • Operator Label Type
        • Chain Admin Label Type
        • Decentralized Finance Label Type
        • NonFungible Tokens Label Type
        • Games Label Type
        • Bridge Label Type
        • Decentralized Applications Label Type
        • Token Label Type
        • Flotsam Label Type
      • Tags
      • Table Freshness Targets
      • Contribute to Our Data
        • Contract Decoding & ABIs
        • How to Add Your Own Tags
        • Community Curation
          • Getting Started
            • Contribution Workflow
          • Model Standards
            • dbt Tips
          • PR Checklist
    • Data Products
      • Data Studio (SQL Analysts)
        • Get Started
          • Write/fork your first query
        • Flipside AI
        • Studio in Depth
          • Query Editor
            • Query Referencing
            • Pro Tips for Querying
            • Keyboard Shortcuts
            • Hex-to-Integer Function
          • Create a Chart
            • Advanced Visualization
          • Build a Dashboard
            • Markdown Reference
          • Team Accounts
        • Tutorials
          • How to Analyze Web3 Data
          • Video Tutorials
            • Overview of Schemas & Tables
            • Ethereum Tutorials
              • Getting Started with Decoded Ethereum Events
              • Getting Started with Ethereum Balances
              • Block Level and Daily Balances
              • Finding Centralized Exchange Flows
            • Solana Tutorials
              • Solana Schema & Tables: Video Walkthrough
              • Solana Specialty Tables: Video Walkthrough
              • Exploring Transactions in solana.events
            • THORChain Tutorials
              • THORChain Schema & Tables
              • Calculating IL for THORChain
          • More Tools & Resources
        • Get Inspired
      • LiveQuery
        • Get Started
        • LiveQuery in Depth
          • Functions
            • 🤝Partner Functions
            • 🧙‍♂️EVM Functions
              • 💡Seaport: Real-time Orders
              • 💡WETH Pool Balances
              • 💡General EVM Node Queries
            • 🤖API Functions
              • 💡Query TheGraph
              • 💡Query Defi Llama
            • ⚙️Utility Functions
              • 💡Hex Converters
              • 💡JSON RPC Request Builder
              • 💡EVM Logs Decoder
              • 💡Keccak256 Encoder
          • QuickNode Setup Guide
        • Secrets Manager
        • Get Inspired
      • Snowflake
      • API/SDK (Developers)
        • Get Started - Your first API call in < 2 min
        • SDK in Depth
          • JSON RPC methods
          • Run A Query
          • Query Results
          • Pagination
          • Sorting
          • Filtering
          • Query Seconds
          • Caching (maxAgeMinutes)
          • Rate Limits
          • Errors
          • More Examples
          • Archive
            • [ARCHIVED] JS/TS SDK
            • ShroomDK Migration Guide
            • [LEGACY] R
        • Tutorials
          • Have Questions?
        • Get Inspired
    • Insights and Tools
  • Earn
    • Flipside Earn
    • Onchain Rewards
      • Quests
    • Analyst Rewards
      • Top Dashboards
        • Top Dashboard Guidelines
        • Skill Tree
      • Ambassador Program
      • Direct to Analyst Commissions
    • Wallet Management
    • Tax Center
  • Support
    • General Support
    • Open a Ticket
      • That email doesn't look quite right
    • 🌟Product Special Releases
      • 2025
        • 2025-02-06 | EVM Blockchain Standardization
          • Table Change Overview
      • 2024
        • 2024-06-13 | Solana native and wrapped addresses
        • 2024-05-01 | Improvements to Pricing Data
          • Actions for Data Studio Users
          • Actions for API Users
          • Action for Data Share Users
    • 🗒️Release Notes
      • 2025
        • 2025-05-01 | Release Notes
        • 2025-04-17 | Release Notes
        • 2025-04-03 | Release Notes
        • 2025-03-20 | Release Notes
        • 2025-03-06 | Release Notes
        • 2025-02-20 | Release Notes
        • 2025-02-06 | Release Notes
        • 2025-01-23 | Release Notes
      • 2024
        • 2024-12-24 | Release Notes
        • 2024-12-12 | Release Notes
        • 2024-11-27 | Release Notes
        • 2024-11-14 | Release Notes
        • 2024-10-31 | Release Notes
        • 2024-10-03 | Release Notes
        • 2024-10-17 | Release Notes
        • 2024-09-19 | Release Notes
        • 2024-09-05 | Release Notes
        • 2024-08-22 | Release Notes
        • 2024-08-08 | Release Notes
        • 2024-07-25 | Release Notes
        • 2024-07-11 | Release Notes
        • 2024-06-27 | Release Notes
        • 2024-06-14 | Release Notes
        • 2024-05-30 | Release Notes
        • 2024-05-16 | Release Notes
        • 2024-05-02 | Release Notes
        • 2024-04-18 | Release Notes
        • 2024-04-05 | Release Notes
        • 2024-03-18 | Release Notes
        • 2024-03-05 | Release Notes
        • 2024-02-20 | Release Notes
        • 2024-02-05 | Release Notes
    • 📊Studio Change log
  • Flipside Community
    • Get Started
    • Ambassador Program
    • Join Our Discord
    • Join Our Guild
Powered by GitBook
On this page
  • Style Standards
  • Dimensional Modeling & Star Schema
  • Table Layers
  • Core Naming Conventions
  • Model Properties
  • Testing
  • Documentation
  • Materialization
  • Incremental
  • View
  • Column Names

Was this helpful?

  1. Data
  2. Flipside Data
  3. Contribute to Our Data
  4. Community Curation

Model Standards

PreviousContribution WorkflowNextdbt Tips

Last updated 1 year ago

Was this helpful?

Style Standards

Our general model and style standards are derived from the best practices guide put forth by dbt Labs:

The primary needs with a Flipside dbt model (will be explained in greater detail below):

Dimensional Modeling & Star Schema

Table Layers

Bronze

  1. Blockchain data that has been indexed and piped into Snowflake under chainwalkers schema. This includes all core data characterizing what occurs on a chain (e.g. blocks, transactions, function calls, state changes, etc). Chainwalkers 2.0 decodes log data, but does no other transformation.

  2. The only data that has been added to this is _inserted_timestamp. This has been added a requirement for all blockchains for efficiency and data integrity reasons.

  3. Any ingested data should be in the bronze layer.

  4. This layer is a view on the source, as such it is the only layer where {{ source() }} should be called and no transformations shall happen in bronze.

Silver

  1. Filtered, cleaned and transformed data.

  2. Silver models should de-duplicate bronze, as chainwalkers may re-ingest a block at a later date.

  3. The models in this layer are incremental as to reduce compute time and cost.

  4. Fact and dimension tables which are completely decoded (where we can), are additive (no replacing data), deduped, have not been joined to other tables. We can expose silver tables in the public facing app as a gold view.

  5. Can be a combination of data sources.

Gold (Core)

  1. Curated models exposed to the public front-end.

  2. Views that can ease the burden for analysts. The wide array of data-users include some new to SQL, new to analytics, and/or new to blockchain technology. Incorporating off-chain metadata, and even aggregations (e.g. daily summaries of key transactions) can help new users understand the ecosystem as a whole.

    1. This also eases the burden on the underlying systems, and facilitates “Easy” bounty programs.

    2. Facilitates learning for new users.

    3. Examples include: labels, transfers, event logs, swaps, liquidity provision/removal, daily balances of holders, prices and decimals, daily transfer summary.

  3. Models that accelerate analytics for a particular protocol (e.g. compound, uniswapv3, anchor, mirror schemas).

Core Naming Conventions

3 Primary Types of Views

All names should_be_snake_case. Abbreviations should be avoided when possible. Abbreviations should match an iso standard ie: currency or country names, etc.

  1. Facts (fact_)

    1. Fact table contains measurements, metrics, and facts. Anything that is measurable, summing, averaging, anything over time.

  2. Dimensions (dim_)

    1. Dimension table is a companion to the fact table which contains descriptive attributes to be used as query constraining.

  3. Convenience Views (ez_)

    1. Convenience Views can combine facts and dimensions for reasons above. This should only be views in the gold layer.

    2. Where curation is doing more of the “lift” for the view.

Model Properties

SQL models do not dance alone! Each sql file should have an accompanying yml of the same name. This is the model properties file and we use it, primarily, to document the model and columns and to test data in the model, at the column level.

Testing

  • unique

  • not null

  • accepted values

Documentation

Materialization

Incremental

True to the name, incremental models load data based on some incremental filter. In silver, just about every model will be incrementally built, based on _inserted_timestamp.

View

Views persist as SQL transformations without actually storing data, like a table. Every core (gold) model is a view on a silver incremental model. This is done to:

  • drop any internal columns that need not be exposed to end users (like _inserted_timestamp)

  • rename the model to follow star schema

Column Names

When building a model, be sure to check how columns are already named in the blockchain's data tables. Within a database, one model should not refer to tx_id while another tx_hash. A more comprehensive naming standard will be published soon™️.

All code that is submitted for a PR should be formatted according to , available as an extension on the VS Code extension marketplace.

tables should never be combined in tables ie: no joining transactions and labels. They can be combined in views, where the logic is done in the underlying queries.

All views should have a prefix of what type of data is within (based on ).

The model properties allow us to test the model output to ensure the data flowing through meets expectations. Some common we use are:

There are also with utility functions that enhance the available tests to plug into a model, or you can write that apply to the model.

The yml file is also where tables and columns are . These should be clear and concise for users to understand what data the model contains. As several columns might be used across models, we utilize the to define the column in a markdown file, rather than in each individual model property file.

dbt Models can be configured to run using one of a number of strategies. The two most common materializations in our models are and .

this dbt autoformatter
Fact and dimension
star schema
generic tests
packages
custom tests
documented
doc block
incremental
view
Star schema
Tests and full documentation
Appropriate materialization
Consistent column names
corp/dbt_style_guide.md at main · dbt-labs/corpGitHub
Model properties | dbt Developer Hub
Materializations | dbt Developer Hub
Logo
Logo
Logo