Introducing Intent-Driven Interoperability via Orby and the Orb Stack

TL;DR Introducing Orby, an intent engine, and the Orb Stack, an intent-driven interop stack, to solve account fragmentation and enable a better way for apps and users to interact in a world of a million rollups.

You’ll be hard-pressed to find anyone in crypto who enjoys the multi-chain experience. Most would even agree that the current multi-chain UX sucks. The reason is that existing interop solutions are built for cross-chain apps, whereas the largest segment of apps are what we call single-chain apps.

Single-chain apps and the unsolved interop problem

Single-chain apps have all their logic and processes confined to one chain with no communication with other chains. Per design, they only interact with users, assets, and data on that chain. Cross-chain apps, on the other hand, have multiple components across different chains that communicate via messaging protocols. This subtle architectural difference makes their interop needs very different. Cross-chain apps primarily need interop solutions that address data and liquidity fragmentation, so the current environment of dozens of message-passing protocols and liquidity networks serves them well. Single-chain apps, however, primarily need interop solutions that address account fragmentation. Currently, there are no interop solutions that adequately solve this problem.

Figure 1: an example of a cross-chain app

Figure 2: a single-chain app

Account fragmentation is the inability for users to seamlessly access their collective assets in all their accounts on any individual chain. It is why users must actively manage and maintain tokens on accounts/wallets across different chains to use apps on those chains. It is also one of three problems that fall under the broader umbrella of interop problems, along with data and liquidity fragmentation. Account fragmentation is the least addressed of the interop problems despite being the most painful to users. There are two reasons for this. First, it’s perhaps the most challenging interop problem to solve since it requires developing a middle layer between users and chains. This middle layer must unify all user accounts while enabling those accounts and their corresponding assets to interact with any application on any chain. In building this middle layer, you will likely touch on all three interop problems. Second, since it touches on accounts, it’s mistakenly assumed to be a wallet problem.

Figure 3: Layout of middle layer needed to address account fragmentation

The world without interop for single-chain apps

Without interop solutions that adequately address account fragmentation, single-chain apps are forced to adopt makeshift solutions. At the moment, there are three options:

1. Option 1: Deploy copies of their apps across different chains so that users on those chains can use some version of the app. The likes of Aave and Uniswap have adopted this approach. It also has some issues: (1) It increases the administrative burden on devs since they must manage and maintain multiple instances of their apps; (2) Devs need to rebuild their app from scratch to access different execution environments; (3) Many crypto applications are networks and by deploying multiple instances of their apps across different chains, they fragment the network meaning that the apps are not as good or efficient as they could be.
2. Option 2: Become a cross-chain app. Deploy interconnected components on different chains. Let users on those chains use those components as entry points into the app. This approach has seen limited adoption. Conversations with devs reveal a laundry list of reasons, including: (1) Unwillingness to manage the additional security burden of going cross-chain, (2) Unwillingness to bog down the core app’s UI with latency introduced by cross-chain elements, (3) Counterproductive when building on a custom stack, i.e., app-chains or app-rollups; (4) The futility of cross-chain apps. Yes, you can deploy your app across a handful of chains, but what happens as the number of chains gets into the 100s, 1000s, or 10000s? (5) The effort required to build a cross-chain app makes it practical only if the app has PMF.
3. Option 3: Do nothing. Deploy their apps on chains they expect to give them the most users and leave users on other chains to adopt makeshift solutions to get to the app.

Most developers pick Option 3 partly because it has the best cost-to-reward ratio. It’s not reasonable to spend time, money, and effort to integrate several chains when there is little chance it will meaningfully increase app usage. The result is the nightmarish multi-chain we are familiar with. A simple multi-chain interaction involving two accounts on two different chains may look like this:

1. Go to the app you want to use, which is deployed on Chain A.
2. Connect your wallet on Chain A.
3. Realize your wallet needs more funds on Chain A to use the app.
4. Switch your wallet to Chain B, where you have some funds.
5. Go to an exchange (decentralized or otherwise).
6. Swap/Bridge your assets on Chain B for those needed on Chain A (multi-step process).
7. Wait for the swap to complete (3–5 mins on the lower end).
8. Switch your wallet back to Chain A.
9. Return to the app deployed on Chain A.
10. Finally, execute your transaction(s).

Figure 4: Using exchanges i.e. cex/dexs to access single-chain apps

For every additional chain or account in this process, the number of steps increases by 4–5, and the latency increases by at least 3–5 mins. For more aggressive forms of account fragmentation where a user must pool funds from 3 or 4 different chains, we are looking at ~20 steps and 10–20 mins of latency. Even if we build a system that allows us to abstract away the number of clicks/steps, as some liquidity networks do, and parallelize the swaps, we are still looking at 3–5 min latency. This is far from ideal UX for crypto natives, let alone new users expecting web2-like UX.

Single-chain apps need a new system for interop that allows them to provide multi-chain users with UX on par with web2 apps while addressing the issue of account fragmentation. Furthermore, this system should not significantly burden users, app developers, or wallet providers. Building a system like this is critical to many developments in web3, ranging from Ethereum scalability and modular chains to app-chains. All these developments will increase the number of chains, and new chains mean more accounts for users to manage. There is no world where users actively manage accounts on dozens of chains, let alone thousands or millions. This means users can only leverage these developments if a better interop system that addresses account fragmentation emerges for single-chain apps. Without it, they will likely continue aggregating around a handful of chains. In turn, developers will be forced to build on these chains instead of chains that are the best of their apps, leading to many apps with poor UX. Ultimately, this poor UX will hinder web3 adoption.

Intent-driven interop via Orby and the Orb Stack

At Orb Labs, we believe the key to improving multi-chain UX is building an interop solution that specifically caters to the needs of single-chain apps. Our vision is to empower developers to build on any chain that best suits their app while allowing them to access any users on any chain. This means building an interop solution that solves account fragmentation. That is easier said than done. A lot needs to be done to ensure that the solution maintains the highest standards regarding security, cost, and speed so as not to dissuade users from using apps on other chains. After several months of working on the problem, we are happy to introduce intent-driven interop via Orby and the Orb Stack.

In order to understand the essence of Orby and the Orb Stack, it’s essential to have some knowledge of intents. Intents have been spoken about at length in the context of MEV but not a lot has been said about them in the context of interop. Intents are a type of request, just like transactions. In some ways, you can think of transactions and intents as twins. Transactions are the strict older twin that insists that a request follow a specified path from one point to another. So, if you want to get from point A to point E, a transaction will insist you go from point A->B->C->D->E. Intents, on the other hand, are the easygoing younger twin who doesn’t care about the path as long as you arrive at the destination. This slight difference makes intents more versatile and better suited for multi-chain interactions. Whereas transactions draw from the knowledge of a single caller for the best path when creating a request, intents can draw from the collective knowledge of solvers to find the best path at the point of execution. This is invaluable for multi-chain interactions where there are typically several moving parts, including latency across different domains. More importantly, it enables the creation of a middle layer between users and apps where funds can be swiftly and seamlessly moved between accounts to interact with apps without significant changes to the security of user accounts. For example, the same multi-chain interaction we described earlier that involved 5+ accounts across 5+ chains can be executed in a number of seconds as opposed to 20+ mins.

Orby is an intent engine. It’s a stripe-like integration that can be embedded into any app frontend, enabling users from any chain to access the app. It can also be embedded in a wallet to enable users to interact with any app on any chain without fragmenting user accounts. Orby works by taking in a multi-chain interaction and converting it into an intent that can be executed on any chain via the Orb Stack.

Figure 5: Layout of Orby and the Orb stack

The Orb Stack is a modular stack of protocols that work together to enable users to issue cross-domain intents. It consists of 5 layers. On the lowest level of the Orb stack are extensible light clients that provide the security foundation of the system. On top of that is a messaging framework designed to optimize for speed, cost, and configurability. Right in the middle of the stack is a token-wrapping protocol that allows us to pass value from chain to chain. Above that is a cross-domain intent protocol that allows us to verify the execution of an intent. At the top of the stack is a universal account system that allows users to custody assets on different chains and occasionally serves as the entry point for intents.

Figure 6: Deeper dive into the Orb Stack

The combination of Orby and the Orb Stack allows us to take the burden of interop — specifically regarding accounts — away from users, app developers, wallets, and chains:

• Users no longer need to be bridge experts. They can simply focus on interacting with the apps they like.
• App developers no longer need to deploy on the chain with the most users or unnecessarily go through the hassle of making their apps cross-chain. They can simply build on the chain that’s best for their apps.
• Wallets no longer need to add new chains or expand to become cross-chain. They can be universal from day one and automatically expand to new chains with every new deployment of the Orb Stack.
• Chains no longer need to worry about attracting users. They can focus on attracting developers, and with a single deployment of the Orb Stack, those developers will have access to all users in web3.

It is important to note, however, that Orby and the Orb Stack are built specifically to address account fragmentation. For that reason, they do not eliminate the need for cross-chain messaging protocols or liquidity networks that address data and liquidity fragmentation respectively. Cross-chain messaging protocols will still be used by cross-chain apps such as cross-chain exchanges, lending protocols, governance systems, and token standards. Similarly, liquidity networks will be used by apps and intent solvers to balance their liquidity across chains.

Both systems, along with Orby, will exist in the ecosystem of tools working together to enable the best multi-chain experience for users.

In the coming weeks, we will publish additional blogs and other material explaining the individual layers of the Orb Stack and show how they all come together to power Orby, our intent engine.

Work with us

We are always excited to chat about many of the ideas mentioned in this blog post. If you want to chat or learn more about what we are building, checkout our website/docs, follow us on X (Twitter) at @0xOrbLabs. If you are curious and want to ask questions, join us on Discord.

Acknowledgments

Special thanks to all the people we worked with and people whose conversation helped us articulate our goal and vision, specifically James Ho (Modular Capital), Carl Hua (Shima Capital), Alex Evans (Bain Capital Crypto), Hazel Chen (Shima Capital), Carl Vogel (6th Man Ventures), Ekram Ahmed (Celestia), Louis Song (Seven X Ventures), Adrian Lai (Newman Capital) and Anthony Cheng (Newman Capital).