Many Words On Trac Network

The Ordinal and BRC20 ecosystem had a unique birth. Instead of developers releasing comprehensive, well-thought-out protocols backed by academic whitepapers and years of in-depth research – Ordinals began as a few posts on a website and BRC20s as an idea on Twitter. What followed the release of both Ordinals and BRC20s was an explosion in meme coins, money grabs, and fly-by-night projects. However, such was a demand for new Bitcoin use cases that the first BRC20 hit a $1B market cap within a few months, and a Bitcoin Punk Ordinal recently sold for $53K. 

Now, things in the ecosystems are beginning to change. We are starting to see the emergence of more legitimate, long-term projects that leverage Ordinary tech – and it’s about time. There is some low-hanging fruit that protocols could capture if they are first to market on them – decentralized indexers, scaling, functionality, and more.

I want to hightlight one of these projects in this AF post. Trac Network has been on my watch list for a while, but I have only recently begun to look into it more in-depth. 

What Is Trac Network?

The Trac Network is a network of protocols and platforms under the aegis of their parent company, Trac Systems. Trac Network aims to release a set of tools for Bitcoin users, developers, and holders to leverage Bitcoin’s new Ordinal tech. Trac Network has announced three core projects: Trac Core, TAP Protocol, and Pipe Protocol.

Trac Core

Trac Core is by far the most interesting Trac Network project to me. As readers are probably aware, Ordinals and BRC20s require indexers to work. An indexer indexes inscriptions and ensures that everyone participating in the Ordinal protocol reaches a consensus on their state. Ordinals need their indexers for inscription discoverability and to order the Ordinals. For example, if people exchange inscribed sats, they must run the same indexer to ensure they exchange the proper sat. As such, indexers and whose indexer you are running are key infrastructure questions for the entire Ordinary ecosystem. 

The most common indexer is ord v0.9. However, if you read my last AF post on BRC20s, you will remember that the new version of ord v1.0 breaks BRC20s, so much of the market has decided to freeze their indexers on the prior version of ord. This situation highlights the importance and challenges around indexers. Not only is the version of the indexer important but so are other indexers. Unisat, for example, has its own indexer, as does Hiro wallet. It is not out of the realm of possibility that other indexers and even entirely different indexes of inscriptions emerge. Questions around indexers highlight issues around the entire BRC20s, ord, and Ordinals edifice. Right now, everyone only uses ord because everyone uses ord – its popularity is due to network effects, and that could change.

The Ordinals team is the one that manages ord and releases updates for it. In a way, the Ordinal team controls the Ordinal market because their software, ord, sits at the center of it. I am not ascribing any ill intent to the Ordinal team. By all accounts, the Ordinal team is honest, open, and good at what they do. But having an entire sector of Bitcoin’s ecosystem built on software controlled by a single entity is a recipe for disaster. As such, to me, for Ordinals to reach their potential, they need a decentralized indexer. 

This is where Trac Core comes in. Trac Network is advertising Trac Core as a decentralized indexer and oracle governed by $TRAC holders. As a decentralized indexer, it puts control of the Ordinal protocol into the hands of governance token holders while also helping to ensure that the Ordinal ecosystem gravitates around a canonical inscription index. This is all theoretical, however, as I have yet to see a working indexer from Trac. However, the value proposition of Trac Core is a strong one – especially if they decide to support more chains. Trac announced its intention to support DRC20s, the Doge token standard.

TAP Protocol

Trac Networks’ second product is the TAP protocol. I admit I am much less excited about this offering than Trac Core. There isn’t much information on what exactly TAP is and how it works, but the articles call it a ‘multi-asset metaprotocol for Bitcoin Ordinals.’ Ordinal metaprotocols generally denote an inscription standard. Bitmaps are a metaprotocol, as are BRC20s, BRC721s, ORC20s, etc. 

TAP protocol mentions OrdFi a few times, suggesting that TAP will focus on leveraging Ordinal tech for DeFi. Articles on TAP indicate that it will be a token standard with many DeFi-adjacent functions like staking, LP pools, NFTs, etc. 

I am less than excited about this because, although I am sure the TAP protocol will work well, the network effects around BRC20s are powerful. I have trouble seeing any metaprotocol, except Runes, when they come out in April, supplanting BRC20s. The market around BRC20s is super strong, and getting people to adopt a new metaprotocol will be tricky. As an example, this would be somewhat like someone releasing a new bunch of DeFi protocols on Ethereum that use a separate and non-composable token standard to ERC20s – it would just not take off. That being said, there may be some sort of composability between TAP and BRC20 – maybe allowing migrations between the two, but it’s too early to tell. Regardless, my hunch is that Runes and BRC20s will overshadow this. 

Also, as an FYI, TAP will have a token called $TAP, but it is not yet released.

Protocol Piping

The third and final product from Trac Network is Pipe Protocol. The Pipe protocol extends Bitcoin’s UTXO system and focuses on art and collectibles. There is barely any information on this, but based on the description, this seems a lot like Bitcoin Stamps. Stamps store up to 8KB of data in Bitcoin tx outputs. Unlike Ordinals, which store data in the witness, Stamps are unprunable, and people criticize them for bloating the UTXO set. However, as I can find so little info on the protocol, I will hold off on any sort of analysis for now. 

Like Tap Protocol, Pipe Protocol will have its own governance token.

Chained Governance

Trac Network is also experimenting with an odd governance method called chained governance. There is no complete explanation of how this model will work, but each protocol governance token can vote in the other protocols’ governance. Some of the images in their articles suggest that the voting will only flow like a waterfall. $TRAC can vote in TAP Protocol, $TAP can vote in Pipe, and $PIPE can vote…somewhere. 

However, this process makes little sense because $TRAC seems like the only token one would want to hold as it gives the best exposure to everything in the ecosystem. But, like much of this project, my analysis will have to wait as there is so little information on this.

It seems obvious to me that holding $TRAC could qualify one for airdrops of other tokens in the ecosystem. The articles mention airdrop mechanics a few times. I would not be surprised if they used the launch of their other governance tokens to highlight their airdrop functionality by airdropping tokens to $TRAC holders.

A Note On Token Dynamics

One thing to note, a new development, is that there is a company over all of this. Trac Systems, the parent company of the Trac Network, will likely control a large amount of tokens for these protocols. And as a company, they also potentially have some equity they have sold to various investors. And then, if each product also has its token, token dilution could be a real issue. 

A parent company also raises some tough questions around who owns these protocols or revenue from them – is it token holders or Trac Systems? At this point, I just don’t know. But people should be aware of how this mini-token ecosystem is shaping up. 

Wrapping It Up (Christmas Pun)

Undoubtedly, Trac Network is a project to watch – even if just for their decentralized indexer. I have been waiting for a team to build one of these for a while now. Ordinals and BRC20s need some sort of decentralized ownership/governance of their indexer layer. With one team controlling the development of it, it adds a lot of risk to the system. Entities could lean on ord developers to censor some inscriptions by making them undiscoverable by removing them from the canonical index – even new indexes could theoretically emerge. Decentralizing this layer and making it more robust is a critical step for Ordinals as a whole.

There are some dynamics I am on the fence about, like chained governance, TAP protocol, and Pipe Protocol. But these projects are so new that my opinion could change as new information emerges. I would like clarity on how Trac Systems integrates with these protocols, for example. However, Trac Network should be on your watch list if you’re an Ordinals enjoyer.

Leave your comment...

Thanks for the article. Very informative.

A few questions:

  1. It seems that BRC20 decentralization can also be achieved by better adoption of different open-source indexers (Ord, Hiro, Unisat, Trac) in a similar to Ethereum clients way, so different services use different indexers following some standard. In this way, it is not so important for Trac to be decentralized because decentralization will be achieved by mixing many centralized indexers. What makes you excited about the decentralized vision of Trac? Do you expect it to become the standard that will be followed by other indexers?

  2. What is your vision of TRAC's team's ability to deliver products? The company works on 3 complex products in parallel, the dev team looks centralized around Benny, and roadmaps and deadlines are pretty opaque. We are waiting for the TRAC indexer while Unisat and Hiro have their products in production.

Sorry I am late on this, just getting back from Christmas!

  1. Regarding decentralized indexers, I just think its the next stage of whats needed for Ordinals to really take off. Having a bunch of disparate centralized indexers reaching a soft consensus is probably sub-optimal. In my mind a decentralized canonical indexer is probably better in terms of censorship resistance, permissionless etc.

  2. This is a huge red flag for me with the project. I am not a huge fan of fat protocols as it splits effort, focus, and liquidity into all these separate areas. Sushi 2 years ago was a good example of the challenges around building a bunch of things at once. I don't know the team at all tbh, so can't really comment on their ability to execute - other than it will be hard to pull it off.

nice! This AF was very helpful for me, thanks a lot!

Happy to help!

Thanks for this Christmas Gift. And thanks to the entire Delphi Team for your fantastic Alpha Feed posts and research articles. You really nailed it. 2024 will be epic. Enjoy Christmas with your family and friends!

Thanks for the kind words ser! Its a pleasure to write and explore this space with everyone. I really appreciate all the comments and back and forth here.