1. Introduction

Accumulate Digital Identifiers (ADIs) are URL-based digital identities with hierarchical key sets that can manage data, tokens, and other identities. They can also be used to govern more complicated operations such as token issuance, off-chain consensus building, and multisignature transactions. While key hierarchies are useful for organizing priorities, identity hierarchies are useful for organizing objects. Objects might include different token types held by a user, different departments within an organization, or different data types collected by an array of IoT sensors. How a company organizes its departments, financial records, or data structures can be reproduced in the organization of objects on the Accumulate network.

We introduced ADIs and Lite Accounts in previous technical guides and differentiated their URL-based addresses from the addresses typically encountered in other blockchains. In this guide, we’ll take a deeper look at how URLs are constructed in the Accumulate protocol with a particular focus on the identity hierarchy.

2. Nomenclature

The identity hierarchy refers to the organization of tokens, data, and identities under an ADI or Lite Account. It is useful to know the following terms to better understand how identities are organized.

• ADI: A digital identifier that governs data, tokens, and identities on the Accumulate network. An ADI manages these assets using a set of hierarchical keys that it owns or shares with other ADIs.
• Sub-ADI: A digital identifier that performs the same functions as an ADI but with slightly less autonomy due to its management by a parent ADI.
• Account: A terminal data or token sub-chain of an ADI or sub-ADI that is initially specified by the user but fixed in function after its creation.
• Lite Account: A simplified version of an ADI that can only manage tokens. Unlike a token account, which managed by an ADI and named by the user, a Lite Account manages itself and is addressed by the hash of its public key.
• Directory: An optional cataloging structure that references the location of sub-ADIs and accounts but does not manage their contents.

3. Architecture

Any number of data accounts or sub-ADIs can be nested within an ADI. Accounts and sub-ADIs are independent from each other and possess their own sets of keys with which they can manage their assets, while the parent ADI possesses an administrative key set that can add, delete, transfer, or modify the security of its account or sub-ADI. Data and token accounts are terminal, meaning that sub-accounts cannot exist. However, sub-ADIs and accounts can be nested within another sub-ADI.

This architecture is illustrated in the figure below, where a hypothetical ADI is managing a sub-ADI, token account, and data account. The sub-ADI manages two different token accounts, as well as a data account and second level sub-ADI which in turn manages several data accounts. While not shown, multiple sibling sub-ADIs can be nested within a parent sub-ADI. Lite Accounts are excluded because their architecture only includes the Lite Account and its associated token accounts.

4. Accounts

Account URLs have the general format <prefix>://<ADI>/<directory>/<account> where the prefix acc:// specifies the Accumulate blockchain, ADI specifies the top-level identity in control of the URL, directory specifies a particular type of account, and account specifies data or tokens. Several examples of data and token accounts are provided in the table below for the hypothetical ADI ‘bank’. Note that both cryptocurrencies and tokenized assets may be considered token sub-chains.

Directories are optional, and we anticipate that their utility will be mostly confined to enterprise applications where greater organization of large numbers of accounts and sub-ADIs is needed. The directory label is defined by the user and can be single or multi-character. For the sake of clarity, data, tokens, and identities are given the labels d, t, and i. However, an investment firm with ADI ‘firm’ may create data accounts with directories r and c for residential and commercial properties, while a cryptocurrency trader and non-fungible token (NFT) art collector may create token accounts with directories nft and stable to denote NFTs and stablecoins. Any label can be used so long as the object type is specified within the wallet. However, a directory label cannot be changed after it is created.

5. Sub-ADIs

The structure of identity subchains for sub-ADIs is similar to those of an account, where any number of sub-ADIs can be nested under a directory that a user defines in their wallet as an identity. However, sub-ADIs can also be nested under other sub-ADIs. The format of an identity chain with multiple sub-ADIs is <prefix>://<ADI>/{< directory>/< sub_N-ADI>}_N where N refers to an arbitrary number of sub-ADIs each with the same identity directory. In the example below, different departments within a bank are represented by different Sub-ADIs. The human resources department is further subdivided into sub-ADIs that specify different roles within the department.

6. Combining Accounts and Sub-ADIs

Data and token accounts may also be nested within sub-ADIs. This offers an alternative strategy for organizing large numbers of data and token accounts without needing to create multiple directories. Using the example of an investment firm that manages different types of properties, we can imagine that a team specializing in residential homes may be given a different sub-ADI than a team specializing in commercial real-estate. For simplicity, we refer to these combined addresses as URLs below.

Since accounts are terminal, it is not possible to nest sub-ADIs within accounts. While acc://firm/i/residential/d/properties is permitted, acc://firm/d/properties/i/residential is not.

7. Development Timeline

For Testnet 1.0, users will only be able to create top-level ADIs and ADI token accounts. However, directories and sub-ADIs will be introduced in Testnet 2.0 to allow an organization to create identity hierarchies and manage keys held by sub-ADIs. Multiple accounts can be managed by a single ADI in Testnet 1.0, and multiple ADIs will be able to manage a single data or token account in Testnet 2.0. For example, a consortium of banks with different ADIs will be able to manage a tokenized asset like a bundle of real-estate.