What are App IDs?

Unique identifiers that separate and filter data submissions on Avail DA by application.

Introduction

As a general-purpose base layer, Avail is designed to support many modular chains at the same time, providing consensus and data availability to all of them simultaneously. How does this work? Avail headers contain an index that allows a given modular chain (or "application" in Avail terminology) to determine and download only the sections of a block that have data for that particular application. This has significant benefits, including:

Modular applications are mainly unaffected by other uses of the base layer at the same time.
Block sizes can increase without requiring applications to fetch more data because they don't need to fetch the whole block, only what's relevant to them.
This filtering is done using the "application id" (AppId).

Data availability sampling is still done on the entire block, however--this is the process where clients sample tiny parts of the block at random to verify availability.

Consider a random block on Avail DA

It might contain data blobs from a variety of different rollups pertaining to their different execution environments. Think of the EVM, the SVM, Stackr, ZKsync chains, OP stack, and many more.
If all of this data is randomly strewn about in a block, it would be tedious for a rollup to parse through all of it just to fetch the data it needs.

random block on Avail DA

Now think of the same data neatly arranged into its own sections

But what if all of that same data in the same block was organised into different sections, stored alongside its peers. Each of these 'sections' would be identified by an AppID.
A developer now does not need to parse through the entire block to find the data they need, they can simply query data from the AppID they are interested in.

random data arranged neatly in Avail DA block

These 'sections' are flexible

All of the rollups running on Avail DA probably won't submit data in all of the blocks. Thus, it is likely some AppIDs will be empty in some blocks.
On the flipside, some rollups might need to submit more data than usual in a particular block.
None of this is an issue on Avail DA, the individual block builds as needed in the moment.

AppIDs on Avail DA are flexible

Structure of an App ID

Each appID consists of 3 fields:

key: A string that is the name of the appID. Each appID should have a unique name.
owner: The address of the account that created the appID. A single address can create multiple AppIDs.
id: The unique integer index of the appID. It is incremented by 1 every time a new appID is created and is automatically assigned.

Spam and security

The key and id fields of every appID are unique. If you try to create an appID with the same key as an existing one, the operation will fail.
Anyone can submit any sort of data to any appID regardless of whether or not they created it.
This is not an attack vector. Avail DA is a DA layer, not an execution environment -- it is not concerned with the validity of the data being submitted, only with its availability. Any app or execution layer building on top of Avail DA can set up rules to filter out unwanted data submissions. For example, they could require that only data submitted with a particular signature is accepted, treating all other submissions as spam.

Note

Ready to create your own App ID?

Via the explorer: Follow our explorer guide to create one through the UI.
Programmatically: Use our SDK for programmatic App ID creation.
API reference: See the createApplicationKey API docs.

Data submissions to App IDs incur fees -- learn more about how transaction pricing works.

How is this guide?

How Avail DA Works

Using the Explorer

Introduction Consider a random block on Avail DA Now think of the same data neatly arranged into its own sections These 'sections' are flexible Structure of an App ID Spam and security

Edit in GitHub