What is Account-Centric Indexing?

Background

Smart contracts on blockchains allow the freedom of creating arbitrary softwares, allowing end users to record data to blockchains. Such data include users’ financial activities including assets and trading actions, and users’ consumer behaviors including gaming activities, NFT collections & social networks etc. As GameFi, SocialFi, Crypto AI and other consumer-facing Dapps thrive, users’ consumer behaviors are expected to become more prevalent on-chain in future. While users’ data are valuable assets and crucial to any potential AI & ML use cases, crypto data's lacks essential semantics for both human-readable needs and AI use cases. The major challenges are listed below:

  1. Data resides in silos across different Dapps & blockchains

  2. Raw crypto data lacks essential semantics

Here we propose Account-centric Indexing, a programmable semantic indexing protocol to tackle the above challenges.

Data Model

Account-centric Indexing mainly focuses on resolving accounts' on-chain profiles, and keeps the profiles updated in real-time. Here we model users’ on-chain profiles through Accounts & Features, each Account is described by a Feature set (see Figure1). On-chain transactions are programmed into Triggers, which in turn trigger Accounts’ Features to update via a functional interface defined by User-Defined Functions(UDFs).

Each Account is described by a set of Features, some of which are constant attributes (e.g age of an account), and others are dynamically changing values (e.g. total trading volume). A Feature could be a user's ETH balance, liquidity in a pool, recent 30 days DEX transaction volume, NFT holdings, MEME trading P&Ls, social followings & followers etc. Essentially, it refers to any semantic value describing a user’s on-chain activities. When developers utilize Account-Centric Indexing, they can access Accounts and their associated Features directly through interfaces provided by the Hemera Protocol Network.

A Feature can be defined by any developers, and created and updated programmatically during the Account-centric Indexing process. Each feature has a unique identifier (ID), a human-readable feature name, and a feature type, i.e. a Feature named “USDT balance” is an “ERC20 token balance” typed Feature. For feature types already supported by the protocol, i.e. “ERC20 token balance”, Account-Centric Indexer automatically creates new Features when needed and updates existing Feature values. For example, “ERC20 token balance” is a built-in feature type, and when a new ERC20 smart contract with token ticker $ABC generates transactions, a new Feature instance named “abc_balance” with type “ERC20 token balance” is created and updated for all Accounts who traded $ABC token.

Feature values are updated through UDFs (see Figure 3). A UDF consists of two elements: Triggers that listen to on-chain changes and the UDF code. A Trigger is essentially any action that causes on-chain state updates, which can be a transaction or an internal transaction. Developers can define Triggers through configuration files, and allow Account-centric indexers to create and manage Triggers. Each Trigger object is directly linked to one or more UDFs and when new Trigger instances are created, impacted UDFs keep Features up to date. UDFs take in standard data structures from EVM blockchains including transactions, logs, and traces, and in addition a list of developer-defined inputs allowing developers to express new Feature types when needed.

Finally, each Account’s Feature values are updated and historical value changes are stored by the Hemera Protocol Network. Each feature value is tied to a block number, and a new entry will be created when the feature value of a later block number differs from that of the preceding block number. With the data model, users can easily get current feature values and compute historical changes.

Last updated