Tracking Data

The backbone of Openrep’s reputation framework starts with tracking critical on-chain information across various networks. This page explains which chains we support, what it means to track a chain, and how the Indexer service keeps up with real-time activity.

Which Chains Do We Track?

Openrep supports a growing list of EVM-compatible blockchains and sidechains. While this list will expand over time, below are the primary networks currently tracked:

  • Ethereum Mainnet

  • Optimism

  • Unichain

  • Abstract

  • Berachain

  • Base

  • Arbitrum

  • Linea

  • Blast

Note: We plan to integrate more chains based on community demand and protocol usage. If you require support for an unlisted chain, please get in touch with our team.

What Does It Mean to “Track” a Blockchain?

When we say Openrep “tracks” a blockchain, we mean:

  1. Discovery of New Blocks

    • As soon as a block is mined (or validated) on the network, the Indexer becomes aware of it in near-real time.

  2. Extraction of Transactions & Logs

    • Every transaction within the new block is fetched.

    • All logs/events from these transactions are also retrieved (e.g., ERC-20 Transfer events, DeFi protocol events).

  3. Data Normalization

    • The raw transaction and event data is transformed into a standardized schema for quick retrieval and analysis.

  4. Historical & Real-Time Coverage

    • Openrep maintains a full historical record of blockchain data (for all tracked networks) and continues to watch for any new activity.

By preserving this complete and structured history of on-chain events, Openrep can generate reliable reputation scores that reflect both past and current behavior.

How Do We Track These Chains?

  1. Continuous Polling or Subscriptions

    • The Indexer service either polls the chain’s RPC endpoint at regular intervals or uses WebSocket subscriptions to receive alerts when a new block is published.

    • Polling intervals can be tuned (for example, every few seconds on faster blockchains) to minimize latency.

  2. Block-by-Block Processing

    • Once the Indexer detects a new block, it fetches the block’s transactions and associated logs.

    • Each transaction is parsed to identify attributes such as from, to, value, and data (calldata); logs are captured with their topics, contract address, and unindexed data.

  3. Schema Conversion

    • Raw data is converted into a uniform schema for storage. This makes it easier for subsequent steps (like the Parser or the Pricing Service) to query or reference the data.

  4. Resiliency & Reconciliation

    • The Indexer keeps track of processed block numbers to avoid duplication.

    • If the Indexer goes offline, it picks up where it left off to ensure no gaps in the data.

  5. Storage in a High-Performance Database

    • Indexed transactions and logs are stored in a database optimized for quick lookups.

    • This enables efficient filtering and retrieval (e.g., by transaction hash, block number, or contract address).

PreviousIntroductionNextData Schema

Last updated