Vybe Network Docs
Search…
⌃K

Indexing Types

Guidance on using the various indexing types

Overview

Vybe's Indexing solution supports different kinds of indexing to cater to the needs of various teams. All the indexing types are connected by a consistent user experience. This document aims to provide more guidance on selecting an indexing type.
Have something which we don't support for indexing? Please reach out, we would love to learn about your needs and how we can help.

Anchor Accounts and Event Indexing

Anchor accounts indexing lets you store a historical timeline of updates to anchor accounts over time in your databases. Similarly, anchor event indexing indexes all events which take place within your programs. Anchor accounts and events store data in an encoded format that is not human readable. Our indexing solution decodes this data during the indexing process making it instantly queryable. We also provide a GraphQL API for you to query this data directly. You can also select to index only specific fields in your accounts/events or index the entire account/event.

Data Flattening and Column Name Overriding

Accounts and events store data in hierarchical structures similar to JSON. Data is organized in parent-child relationships where various data fields are linked vertically or diagonally. Many databases have a JSON type these days to store hierarchical data like this. However, it is often much harder to query as compared to the regular scalar types. To make your data easily queryable, we "flatten" your data into a two-dimensional non-hierarchical structure. When we flatten your data, we use the field names as the names for the columns in the database tables. Since it's possible for the same name to be used in multiple fields, to ensure the uniqueness of column names, we might append _1 , _2 to your field names. We understand that you may want to use different names for your columns over the ones we generate for you. For that purpose, we let you override the names for each of the columns. For instructions on doing this, please refer to Creating and Managing Indexes document.
Additionally, for some kinds of data, we do some extra processing on it so that it is easier to work with. Most notable of these types are public keys which are turned to base58 encoded strings, big numbers which get changed to their base 10 number strings and bytes which are turned to an object of shape:
{
type: "Buffer",
data: int[]
}
The names you use for columns must conform to the following rules:
  1. 1.
    The name must not be one of the reserved words. The reserved words are:
    • id
    • pubkey
    • write_version
    • lamports
    • slot
    • rent_epoch
    • team_id
    • pid
    • blocktime
    • signature
    • vybe_hash
  2. 2.
    Empty strings are not allowed.
  3. 3.
    The name must not exceed 55 characters in length.
  4. 4.
    The names must be unique.

SPL Token Transfer Indexing

During our user research, we got multiple requests to provide a way for teams to keep a record of all SPL token transfers happening on their programs. To support this, we've created SPL Token Transfer indexing. The following data gets indexed for each SPL token transfer instruction executing on your programs:
  1. 1.
    Transaction signature
  2. 2.
    Transaction block time
  3. 3.
    Authority public key
  4. 4.
    Source public key
  5. 5.
    Destination public key
  6. 6.
    Amount
  7. 7.
    Mint public key

Transaction Indexing

Coming soon...

Summary

The following table summarizes if an IDL is required (either pulled from the blockchain or provided directly by you) for an index type and whether field selections are needed for that indexing type.
Index Type
IDL Needed?
Field Selections Needed?
Anchor Event Indexing
Yes
Yes
Anchor Account Indexing
Yes
Yes
Transaction Indexing
No
Yes
SPL Token Transfer Indexing
No
No