DataModel

A DataModel is defined by a schema that specifies the entities (e.g., User, Transaction, Pool) and their fields (e.g., address, amount, timestamp). This schema acts as a blueprint, mapping raw blockchain logs and traces into a structured, relational format that is optimized for analytical queries.

The primary interface for querying a DataModel is SQL (Structured Query Language). Analysts write standard SQL SELECT statements against the defined entities and fields, abstracting away the complexity of interacting directly with low-level blockchain data structures like event logs. This enables complex joins, aggregations, and filters.

DataModels are designed for incremental computation. Instead of re-processing the entire blockchain history for each query, the system processes only new blocks, updating materialized views and aggregates. This is critical for maintaining performance and providing real-time or near-real-time analytics on fast-moving chains.

Transformation logic from raw data to the model is defined declaratively. Developers specify what the final data shape should be (e.g., "a table of token transfers") and the rules to derive it, rather than writing imperative code to process each block. This simplifies maintenance and ensures consistency.

To optimize query performance, DataModels often rely on materialized views. These are pre-computed query results (like daily transaction volumes or user balances) that are persisted and updated incrementally. Queries run against these views, delivering sub-second latency for complex analytical questions.

A core feature is the abstraction of chain-specific details. A well-designed DataModel for a concept like DEX swaps can have a unified schema, while the underlying transformation logic handles the differences between protocols on Ethereum, Arbitrum, or Solana. This allows for consistent cross-chain analysis.

A configurable real-time ETL DataModel defined via a YAML configuration file. It specifies data sources, transformations, and destinations. The pipeline:

• Ingests raw block data or event streams
• Transforms it using JavaScript functions
• Loads results into a destination like PostgreSQL or Kafka This model offers granular control for custom indexing logic.

The two primary data models for tracking ownership. Account-based models (e.g., Ethereum) maintain a global state of account balances and smart contract storage. UTXO (Unspent Transaction Output) models (e.g., Bitcoin) treat assets as discrete, chainable outputs that are consumed to create new ones. The choice impacts transaction design, privacy, and scalability.

A core data structure for verifiable state. Ethereum uses a Merkle Patricia Trie to store all accounts, balances, and contract data. This cryptographic tree allows any node to generate a concise Merkle proof that a specific piece of data (e.g., a user's balance) is part of the current, agreed-upon state without needing the entire dataset.

A mechanism for off-chain data access. Smart contracts emit structured event logs during execution, which are stored in a bloom-filtered, indexed data structure on-chain. These logs are not directly queryable by contracts but are the primary source for off-chain indexers (like The Graph) to build queryable databases of historical contract activity.

The specific data model for smart contract storage. In the EVM, each contract has a persistent storage area, a key-value store mapping 256-bit words to 256-bit words. Variables are packed according to the Solidity ABI specification. Understanding this layout is crucial for low-level operations, gas optimization, and building state access tools.

A model for scaling via data separation. Data Availability (DA) layers, like Celestia or Ethereum's danksharding, decouple the consensus on transaction ordering from the availability of the underlying data. Light clients use Data Availability Sampling (DAS) to probabilistically verify that all data for a block is published, without downloading it entirely.

The DataModel treats on-chain actors—wallets, smart contracts, and protocols—as first-class entities with defined relationships. This allows developers to build complex queries by chaining entities, such as tracing all interactions from a wallet to a specific DeFi protocol, without writing custom parsing logic for each chain.

Pre-computed metrics like wallet age, transaction volume, gas spending patterns, and counterparty diversity are standardized across the model. Developers can instantly assess user behavior and risk profiles, enabling features like:

• Sybil resistance for airdrops
• Creditworthiness scoring for undercollateralized lending
• Anomaly detection for security monitoring

The DataModel normalizes semantic differences between blockchains (e.g., EVM vs. Solana account models). A query for "NFT mints by a wallet" returns consistent results whether the activity occurred on Ethereum, Polygon, or another supported chain, drastically reducing integration complexity for multi-chain applications.

Beyond historical analysis, the model provides a real-time stream of structured events—token transfers, contract calls, and liquidity changes. Developers can subscribe to specific event patterns (e.g., large withdrawals from a lending pool) to trigger alerts, update dashboards, or execute logic in their dApps with sub-second latency.

By providing cleaned, indexed, and relationally linked on-chain data, the DataModel eliminates the need for teams to:

• Build and maintain indexers for raw blockchain data
• Develop ETL pipelines to transform log data
• Create entity resolution systems to link addresses to real-world actors This allows developers to focus on application logic rather than data infrastructure.

The structured schema is optimized for analytical queries, enabling complex joins and aggregations that would be prohibitively slow on raw blockchain data. Developers can perform cohort analysis, calculate total value locked (TVL) trends, or identify top traders across protocols with performance measured in milliseconds, not minutes.

The Unspent Transaction Output model, used by Bitcoin, treats blockchain state as a set of discrete, spendable outputs. Each transaction consumes existing UTXOs as inputs and creates new UTXOs as outputs. This model provides strong parallelism and privacy but is less expressive for complex state logic than account-based models.

A data model where state is stored in persistent accounts (like Ethereum's Externally Owned Accounts and Contract Accounts). Each account has a balance and state storage. Transactions directly modify account balances and storage, making state transitions more straightforward for complex applications like smart contracts.

The metadata section of a block that contains cryptographic commitments to its data. Key fields include the previous block hash, state root, transactions root, and receipts root. These roots are hashes of the respective Merkle tries, allowing light clients to verify data without storing the entire chain.

A Merkle trie containing transaction receipts generated after each transaction execution. A receipt logs key outcomes like the status code (success/failure), cumulative gas used, and event logs emitted by smart contracts. It provides a verifiable record of execution effects.

The complete set of accounts and their associated storage at a specific block height. It is the aggregate result of executing all transactions in the chain's history. In Ethereum, the world state is represented by the state root in the block header, derived from the State Trie.