Data Schema

Once the Indexer service retrieves block, transaction, and log information from various chains, it standardizes them into a uniform schema so that downstream services (like the Parser or Pricing Service) can quickly interpret the data.

In this page, we’ll break down the Transaction and Log schemas that Openrep uses.

---

Transaction Schema

A Transaction in the Openrep index captures the essential fields needed for reputation analysis and deeper parsing. Below is the typical format:

Field	Description
hash	Transaction Hash. Unique identifier for the transaction.
from	Sender Address. The address that initiated (and paid for) the transaction.
to	Recipient Address. Can be another EOA or a contract address.
data	Calldata. Raw hex data specifying which contract function was called and with what parameters. Empty if to is an EOA and not carrying meaningful data.
value	Native Currency Transferred. Always denominated in the chain’s native token (e.g., ETH).
gas_price	Cost per Gas Unit. Measured in wei (or equivalent smallest unit) for that chain.
gas_used	Total Gas Consumed by the transaction.
block	Block Number. The block where this transaction was included.
timestamp	Block Timestamp (Unix epoch) for when the transaction was mined.

Example Transaction Record (Simplified)

{
  "hash": "0xabcdef123456...",
  "from": "0x1111aaaabbbbccccdddd...",
  "to": "0x2222aaaabbbbccccdddd...",
  "data": "0x095ea7b3000000000000000000000000abcd...",
  "value": "1000000000000000000",  // 1 ETH
  "gas_price": "5000000000",
  "gas_used": 21000,
  "block": 1728394,
  "timestamp": 1678832345
}

---

Log (Event) Schema

When a contract processes a transaction, it may emit events (also called logs). These events contain additional, often critical information (e.g., ERC-20 Transfer events). We store log data with the fields below:

Field	Description
topics	Indexed Fields + Event Signature. An array of hashed values: <br/>1. Event signature <br/>2. Indexed event parameters
contract	Contract Address that emitted the log.
hash	Transaction Hash referencing which transaction this log belongs to.
data	Unindexed Event Data. Any parameters in the event that aren’t part of topics. Usually requires the event’s ABI for interpretation.

Event Signature & Topics

• The first topic is typically the event signature. For example, the ERC-20 Transfer event has a known signature 0xddf252ad1be2c89b....

• Indexed Parameters appear in separate topics. For instance, in a Transfer event:

  • topics[1] might store the from address (hashed).

  • topics[2] might store the to address (hashed).

• Non-indexed fields (like the value of tokens transferred) appear in the data field as raw hex.

Example Log Record (Simplified)

{
  "hash": "0xabcdef123456...",
  "contract": "0x3333aaaabbbbccccdddd...",
  "topics": [
    "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef", 
    "0x0000000000000000000000001111aaaabbbbccccdddd...", 
    "0x0000000000000000000000002222aaaabbbbccccdddd..."
  ],
  "data": "0x0000000000000000000000000000000000000000000000000000056bc75e2d63100000"
}

---

Why Standardization Matters

• Consistent Querying: Downstream services (like the Parser) can rely on fixed field names and data types, simplifying their logic.

• Multi-Chain Support: A single schema helps unify data across different blockchains.

• Efficient Storage & Retrieval: Pre-defined structures allow the Indexer to store data in a database optimized for the types of queries we expect (e.g., by transaction hash, block number, contract address).

---

Accessing the Indexed Data

Openrep provides multiple ways to query stored transactions and logs:

1. Database Queries (Internal)

   • For internal modules like the Parser or Pricing Service, direct database lookups by transaction hash or block range are common.

2. API Endpoints

   • For custom needs mercle's indexers can respond in millisecond latency with information about any block, address etc

   • Please get in touch with the team to access this data through APIs.