On Ordinals, Token Protocols, Interoperability, and Asset Layer
I’ve spent the past 18 months building and operating one of the largest token based platforms on Bitcoin SV (BSV), Asset Layer, as well as one of the largest apps utilizing tokens, Duro Dogs. In that time, I’ve learned some of the unique aspects surrounding token management and interoperability that may not be immediately apparent.
The hot topic today in the world of BSV tokens is 1sat Ordinals, an exciting new token protocol on BSV. I think the discourse around Ordinals has revealed a misunderstanding about the role of token protocols and their limitations. In particular, I think many BSV builders and users look at the token protocol as the key to interoperability, or lack thereof.
I wish just using the same token protocol would deliver interoperability, but unfortunately I’ve learned that it isn’t that simple. Look at the RUN protocol as an example. Amazing, cutting-edge apps like Crypto Fights, Haste Arcade, RelayX, and Duro Dogs all use RUN, but there has been very limited interoperability between them.
If a token protocol in isolation isn’t enough to deliver on interoperability, what else is needed? This complicated question forms the heart of our vision at Asset Layer. In this article, I’ll present some of these barriers and how we’ve addressed them through the Asset Layer platform. I’ll also discuss how our vision for and priorities around interoperability informed the features and architecture of our solution.
Token Protocols Don’t Address Data Standards
What is a token protocol supposed to do? Token protocols are responsible for determining when a token has been created (or destroyed), defining how tokens are owned/controlled, and providing ways of attaching data to tokens.
In order for a token to be useful for an application, the data associated with that token must follow some set of standards. In other words, you need a separate protocol for the data within a token in addition to the token protocol. That means we are dealing with three layers. The blockchain layer, the token protocol layer, and then the token data layer. Two apps using the same token protocol but a different data protocol will experience barriers to interoperability.
For example, 1sat Ordinals is solely a token protocol and does not address the token data layer. I think this is smart, since it enables maximum flexibility for developers. The 1sat Ordinals team makes recommendations about token data protocols to use in conjunction with their token protocol to better achieve interoperability.
Is the token protocol or the data layer protocol more important for achieving interoperability? It’s situational, and a big part in determining this has to do with the capabilities of service providers. For example, I can imagine a world where Asset Layer customers could use RUN and 1Sat Ordinals tokens interchangeably. This is because Asset Layer provides standards for the data layer through our platform design, while at the same time we abstract away the complexities of token protocols for our customers.
Interoperability is always a choice
Even if two apps are using the same blockchain, the same token protocol, and the same standards for organizing token data, this doesn’t mean that they will be able to use each other’s tokens. Interoperability always begins with a desire to interoperate. If two apps don’t care about one another’s tokens, not only won’t there be interoperability, there shouldn’t be!
Asset Layer makes sure that these three layers are standardized across all our connected applications. By doing so, we make it as simple as possible to interoperate once apps want to do so. Of course, there will still be work to be done at the application level, but we are extremely excited about how our generalized solution can streamline application development and interoperability.
Viewing a Token isn’t Using a Token
In today’s token environment, the dominant use case is trading collectibles. Very often these collectibles don’t have any use outside of being collected. This means that most applications dealing with tokens only need to be able to display a user’s tokens and facilitate trading. Because of the simplicity of this use case, the cost of implementing a token protocol is one of the largest barriers to interoperability. However, for applications that are using tokens in more sophisticated ways like Duro Dogs, interoperability becomes a more complex task than simply supporting the right token protocol.
Duro Dogs is using tokens in ways that no other application ever has, particularly with regards to interoperability. To meet this need, Asset Layer created our own data standards which are much more robust than what is needed by applications solely optimized around trading collectibles. We focused heavily on designing these standards in a way that is intuitive and lends itself well to being accessed through easy-to-use interfaces like our API and no-code tool.
Interoperability Means Tradeoffs
It’s easy to understand why a game like Duro Dogs doesn’t interoperate with Ethereum and Ethereum wallets. There have already been millions of NFTs minted through Duro Dogs. The cost of minting these on Ethereum would be cost prohibitive. Additionally, the UX that our users have come to expect from Duro Dogs is not something we could replicate on Ethereum. For example, we offer 0-conf transfers. This isn’t possible on Ethereum.
Most people in BSV understand why interoperating with blockchains like Ethereum isn’t always smart. But fewer people understand why interoperating between multiple BSV wallets can present similar challenges. Many people think that BSV should be the boundary of interoperability and that any wallets or apps on BSV should be interoperable with one another.
Asset Layer has drawn the boundary of interoperability around apps connected to our API. All Asset Layer token operations are initiated by a connected application with permission from the token owner, and then executed through our API. Our customers own their tokens, and they have the ability to take them off of our platform. But, while those tokens are accessible through Asset Layer, they are only accessible through our API.
The reason for this is because we can offer a far superior UX to app builders and users. We initiate all of the state changes for our tokens. This means we don’t have to follow the blockchain for state changes to tokens on our platform.
We are thrilled with the rapid advancements in transaction indexing. However, we remain cautious given the newness of the challenge of indexing a blockchain that is already growing exponentially. By controlling our own state changes, we best ensure our ability to provide a service which is fast, affordable, and reliable.
Another feature that can clash with certain types of interoperability is permissioning. Asset Layer is a permissioned platform. In order for an application to view a token on Asset Layer, it must have permission from the owner of the token as well as permission from the application from which the token originated. We think permissionability is a very powerful feature that can be essential for some applications. It’s also easy to operate permissionlessly within a permissioned system, but not vice versa.
It is easy for us to enforce permissions through our API, but it would be much harder for us to enforce our customer’s desired permissions if tokens were easily accessible outside of the Asset Layer platform. By architecting Asset Layer in the way we have, we are able to enforce permissions across all of our connected applications. We think this provides the best possible experience for our customers.
The Token Protocol Layer May Not be the Right Layer for Builders
When we chose to build Asset Layer using the RUN protocol, we understood that RUN might not always be the best choice for us or our customers. For this reason, we decided to abstract the notion of what a token is on Asset Layer away from the underlying protocol. This meant that we could change the underlying token protocol while preserving all of the higher-level logic that our customers were interfacing with when they used our API or no-code tools.
This is analogous to Python, a programming language notable for its simplicity. Python is converted to bytecode using the lower-level language, C. In theory, if a better language for converting Python to bytecode was created, C could be replaced. Many Python developers wouldn’t know or care that this change had been made beyond experiencing the performance benefits.
Building at the token protocol layer forces developers to simultaneously take on more complexity than what is necessary, while also lowering flexibility by committing to a specific protocol at an extremely early stage. By building on a platform like Asset Layer, one can bypass this complexity while resting assured that if a better token protocol comes along, this change will be made without needing to make changes to one’s apps.
Interoperability for Functionality or Resiliency?
Asset Layer has made a number of choices that are very different from what others in the BSV or crypto spaces have done. I think that the number one reason for this is that we are prioritizing interoperability for functionality over interoperability for resiliency.
Asset Layer is focused on enabling amazing new use cases for our customers. This has forced us to draw the bounds of interoperability differently. In order to provide maximum functionality + performance, we’ve set the scope of interoperability for Asset Layer tokens to applications connected to our API. We think this is the best way to facilitate the creation of amazing new apps and to help our customers be successful.
However, not everyone focused on interoperability does so to unlock new functionality. Many prioritize interoperability to avoid being reliant on a particular service provider. In other words, by having tokens be interoperable, it enables token owners and/or applications to not have to trust individual applications or service providers. Hypothetically, if a user doesn’t want to use a specific wallet any more for some reason, that user can switch to another because both wallets support the user’s tokens.
We see the value in this type of resiliency, but we don’t think the associated tradeoffs are worth it today. Accordingly, our customers will have to put a good amount of faith in our team. We understand that not everyone will want to do this, but we think that if we can offer the best product, then we will have plenty of customers to sustain our business.
—
One of the biggest differentiators for Asset Layer is that we view our role as a company differently than many others who are also focused on interoperability. A lot of interoperability initiatives are focused on making the whole world interoperable. They want to connect applications, wallets, blockchains, and everything else.
This is an admirable goal, but at Asset Layer, we are focused on making sure that our customers have the highest quality interoperability experience possible with one another. By limiting our focus in this way, we’ve been able to achieve forms of token interoperability that no other company has ever done before.
Our promise to our customers is that we will do everything in our power to make building high performance token applications as simple as possible. And, we will continue to make it as effortless as possible to share tokens across connected applications and to achieve powerful new functionality through interoperability. If you are interested in learning more about how Asset Layer can help you build amazing applications that leverage tokens which are easily shareable with other connected applications, head to assetlayer.com and click “Get Started”.