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).

Figure 1. Comparing EVM’s account data model with Account-Centric Indexing’s data model. EVM accounts contain 4 fields, the nonce, current ether balance, contract code (if any), account’s storage (empty by default). The left pink box shows examples of 4 different EVM accounts in light pink rectangles. The 1st and 4th accounts are externally owned accounts (EOA) and do not have contract code nor storage. The 2rd & 3rd accounts are smart contract accounts, as such both contain a code section, and a list storing contract related current values. The right gray box is the example of one Account object in Account-Centric Indexing. Account has an ID which is the account address, and a set of Features (white rectangles). Each Feature is recognized by a human-readable name, a unique ID, and a list of values and corresponding block number.

Figure 2. Account-Centric Indexing data models in action. Each Account is described by a set of Features, which are updated through UDFs. In the figure, Account 0xA (gray box on the left) has 4 features (blue circles and white boxes on the left), each of which has a unique ID, a human-readable name, and a list of values. UDF (blue diamond) is defined by Trigger, UDF code (gray box on the right) and listens (red arrow) to new events and updates the impacted feature.

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.

Figure 3 Account-centric Indexing updates Account Features when a new transaction occurs. A new transaction occurs from account 0xABC to swap 0.72 ether for 221M $PEPE on Uniswap (light pink box on the left). Account-Centric Indexer listens to the new transaction, and generates two triggers (blue rectangles with rounded corners) which in turn updates three different features for Account 0xABC (gray box on the right)

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.