Indexing general discussion

Thread for general meta-protocol indexing discussion

Any news for the decentralized on-chain Indexer you’re working with Alex team, domo?


I’m gonna need an ORC-CASH Protocol Channel~


Soon sir. Plan is to slowly open up to new topics. Thanks for patience

1 Like

There was a great discussion on the ordinals show last week! The ALEX oracle initiate is the second segment of the show.

1 Like

im really excited about the oracle!

having more secure brc-20 data validation is needed for others to build on top of brc-20

another thing that i would really like to see is brc-20 data verified and stored onchain where applications can access the data without needing any api keys or running an indexer themselves

i think it would accelerate the adoption of brc-20 and it would catch up with erc-20 when developers can query unlimited brc-20 data with just one line of code, for free


additionally, in regards to issues that would arise because of changes to ord see topic brc-20-cursed-inscription-content

having an onchain, transparent, single source of truth for all brc-20 data that has been verified & ‘blessed’ by domo and major indexers, we avoid confusion

newcomers wouldn’t have to worry whether cursed inscriptions are recognized and we wouldn’t have to run debates for years around the social consensus of brc-20 due to ord changes

most importantly, instead of developers focusing on creating and running indexers, they would focus on creating applications around brc-20 that end-users would use

Can someone explain what a “decentralized” on-chain indexer is? Is that different from an open-source indexer?

I’ve been looking for software I can personally run to index BRC-20, like I’d run Bitcoin Core, but I’m having trouble finding something that works out of the box.

Hi Josh, it’s a good question. The current phase of the project, which ALEX have termed the “Bitcoin Oracle,” is envisioned as the initial move towards the ultimate goal: a decentralized on-chain indexer. Another step in the right direction will be the release of a reference client that you can run similarly to bitcoin core. This is hopefully coming soon.

1 Like

Thanks @domo! Perhaps this is a dumb question, but why is the “Bitcoin Oracle” necessary? It seems to me that a reference client with regular, consensus-driven hard forks is a more transparent way to upgrade the protocol? At least until it ossifies.

Posting here because I don’t think I have permissions to create a new topic.

TLDR what prevents ticker squatting?

The docs specify:

The first deployment of a ticker is the only one that has claim to the ticker. Tickers are not case sensitive (DOGE = doge).

  • There are only $26^4 = 456,976$ different 4-letter tickers available. Increase to $36^4 = 1,679,616$ if including digits. Let’s assume none of those tickers are currently deployed yet.
  • It requires about 200 bytes of witness data to create a BRC-20 deploy inscription.
  • One can render a ticker useless by deploying it with a very low limit (e.g. a limit of zero), unless there is some minimum limit i’m not aware of.

What prevents someone from simply spamming BRC20 deploy inscriptions to squat on ticker symbols?

Let’s assume a pretty high fee rate of 400 sat/vbyte. Each witness byte thus costs about 100 sats to submit (since a witness byte is $\frac{1}{4}$ of a vbyte).

100 sats per witness byte * 200 bytes per deploy * 456,976 deploys = 91.39 BTC.

You could reduce that number significantly by prioritizing pronounceable tickers and common acronyms.

The current design doesn’t specifically discourage squatting, except for the restriction on users issuing tokens themselves. So far, there have been about 60,000 deployments, and there doesn’t seem to be an immediate issue with this. However, we are considering expanding to include 5+ (possibly even 3) in the future, which should help mitigate squatting concerns. When that happens, we’ll likely implement additional measures to further prevent squatting to these new namespaces.