This article is co-authored by Domo and the ALEX Lab Foundation.

Bitcoin has long provided the most secure and decentralized blockchain, and the Ordinals protocol that enabled BRC20 tokens has captured the community's attention like nothing else in recent memory.

Bitcoin has transcended being a pure “money layer” into also becoming the ultimate “data layer” on which hundreds of millions worth of BRC20 tokens are inscribed and settled.

Barely three months old, BRC20 is still an emergent token standard, which currently relies on centralized indexers to maintain the global state of balances.

What is a BRC20 index?

A BRC20 index is a database that keeps track of the wallets & amounts of BRC20 tokens held. Those who build and maintain this database are indexers. Although all BRC20 inscriptions are on-chain, it’s important to understand why the global state of balances is not self-evident.

Bitcoin is not a “virtual machine” L1 such as Ethereum. Bitcoin smart contracts are limited in scope to “send” and “receive” transactions. The fully expressive smart contracts that enable decentralized applications on-chain aren’t possible on the Bitcoin core protocol.

These same limitations carry into BRC20 tokens which are simply JSON text files, or 5 lines of javascript inscribed on a satoshi. As example, let’s take a look at the very first BRC20 inscription, inscribed and tweeted on March 8 of this year:

The inscription deployed, which means it established that $ORDI token exists, its max supply is 21M and a limit of up to 1,000 can be minted per inscription.

Note that creating $ORDI does not provide the creator any $ORDI token. To hold $ORDI an inscription with “mint” rather than “deploy” was required, which provided up to 1,000 tokens per inscription until the max is reached.

And once minted, to transfer your BRC20 requires inscribing a “transfer” transaction, and this transfer inscription is what is sent to a different wallet address.

If this seems a bit rudimentary, it is because BRC20 is a token standard operating without smart contract capabilities. The Bitcoin protocol does not “see” the deploy, mint or transfer transactions as it does not read the data. There is only the transfer of satoshis from one wallet to another, no different than any other Bitcoin transactions.

No Indexers, No Market

At the time of publication, $ORDI has a market cap close to $200M. If an inscription is just a text file, what prevents a malicious user from attempting to deploy and mint $ORDI again?

This is the reason why indexers are critical to BRC20 infrastructure. If there isn’t on-chain code running that will create an “error: $ORDI already exists” then it is up to the indexer of a BRC20 marketplace to determine if $ORDI is authentic or a copycat.

This requires a database that does “read” and register all of the BRC20 transaction data to check which inscription was the first to “deploy” a new token name. The indexer must keep track of which wallets minted the original token supply up to the maximum limit, where the cut off for minting occurred, and are the tokens being “transferred” in the secondary market traceable to these wallets.

Without indexers a BRC20 market isn’t possible, there’s just the chaos of nearly indistinguishable text files.

The Challenge of Indexing

Although Bitcoin itself is immutable and decentralized, the fact that the BRC20 ecosystem is reliant upon off-chain indexers is a major vulnerability. Centralized entities are an inherent point of weakness, especially considering that the state of indexers is in flux.

Inscriptions that currently aren’t indexed or identified have been termed “cursed” and assigned negative numbers (some users create these “cursed” inscriptions on purpose for novelty). Another challenge is the recent introduction of P2WSH inscriptions.

Summarized briefly, P2WSH is “Pay To Witness Script Hash” that uses Segwit (witness data) just like normal inscriptions, but doesn’t use Taproot (P2TR). Further P2WSH uses ECDSA signatures instead of Schnorr.

The result is that after inscription, 10366012, some BRC20 indexers recognize inscriptions that use this new script, and others do not, causing divergence among BRC20 indexers.

These divergences caused by technicalities underscore that if a major indexer were to act maliciously, either by intent or by exploit, the potential fallout would be profound.

Moving Towards Decentralization

To ensure the long term viability and growth of the BRC20 community, it’s essential to focus on building a decentralized indexer that can be used universally and with immutability in mind.

Such a decentralized, on-chain, indexer can work with off-chain indexers to provide a single source of truth based on immutable attestations and verifiable smart contract logic.

The ALEX Bitcoin DeFi team has built B20, the first and fastest BRC20 Orderbook DEX, by utilizing L2 scalability to allow for fast transaction confirmation with the security of assurance of final settlement on Bitcoin.

The success of B20 demonstrates the potential of L2 solutions to complement the security of Bitcoin as well as its lack of smart contract ability. L2 solutions, that enable smart contracts on top of Bitcoin, provide a path to building a decentralized on-chain indexer.

The Stacks smart contract layer is unique in sharing consensus with Bitcoin and in directly reading the Bitcoin state. The ALEX team along with Stacks thought leaders, are actively working to build a universal and immutable indexer.

The ship date of the first version will come in the next months, which will be able to utilize the input from off chain indexers, making it possible for a diverse set of off chain indexers to arrive at the same source of the truth.

Through transparent smart contracts the need for “trust” in off-chain indexers can begin to be minimized, as the BRC20 standard matures and grows to realize its full potential.

Bitcoin revolutionized the world through a trustless system for financial transactions without a need for intermediary. It is the ethos of Bitcoin that inspires building toward a global state of balances for BRC20 where the need for “trust” is removed.

‍