<aside> 💡
Some of the contents is already repeated in the page below:
</aside>
Every transformative technology in history began as a powerful tool for a few. They became ingrained with civilization only after the onboarding friction was removed for everyone. The PC was a nerd’s magic tool until the OS unified hardware and software, turning it into a platform for all software, ranging from entertainment to productivity. The internet was a communication channel for academics until browsers removed the barrier to access, giving rise to the digital economy we live in today. Smartphones only became dominant when the App store turned the clunky multi-step, multi-platform app installation process into a single tap action. This gave rise to the application era in the early 2010s and made apps the default interface for digital society.
In each of these cases, the breakthrough moment wasn’t another incremental feature in technology, but rather a platform that removed the highest barrier in the usage: getting started. These platforms unified fragmented demand and supply into shared pools, enabling effortless cross-interaction. When you remove that wall of onboarding friction, the latent demand floods into the system, adoption accelerates, and the technology becomes the default.
Crypto today is in its pre-onboarding layer phase. We have many chains with valuable assets on them. Eventually, at least multiple chains are going to exist and they aren’t going to be valuable for their programmability, but for their valuable native assets and existing userbase since these are the hardest to replicate. Each of these chains have a set of users who have native wallets installed, native assets loaded, and familiar with the UX quirks. So, for a new app on a particular chain, the onboarding cost for the existing users of that chain is close to zero. Therefore, at their core, these blockchains are “isolated distribution channels.” How does an app choose the right chain? It’s an existential question for an app. This leads to another question: Why do they have to?
Building your app on a chain comes with some serious problems: It not only means inheriting distribution, but also the chain’s technical constraints and giving up a major portion of revenue as a tradeoff. On top of that, distribution on these chains isn’t guaranteed to be persistent. The hot chain of today may become yet another zombie chain tomorrow due to the simple fact that no chain has found PMF yet. So building your app on a chain limits your app’s potential in two dimensions: the potential features of the application due to the technical constraints and a ceiling on the app’s distribution limited by the number of users on that chain. In some years, we’ll look back and find it stupid that the industry was hyperfixated on the chain choice to build a user facing application.
There’s been attempts to solve the technical and revenue constraints with appchains, where apps control the execution and sequencing with extensive features. However, they need to bootstrap distribution from scratch since they don’t have a venue to tap into the existing user distribution like apps on a single chain. How many times have you gone into an appchain or an app on a new chain wanting to use it, but realized you need to download a new wallet, create an account, find the right bridge, send the funds, and then finally try the app? Midway through thinking, you just say, “ah maybe later!” and never go back again.
The first time user onboarding experience is horrible, so apps that may have revolutionized the category never reach the critical mass. This is only for the crypto-native users, new crypto users are not even in the picture yet. Only when distribution is taken care of, rapid experimentation at the app layer can happen, leading to higher and faster chances of a good app succeeding. App Store unlocked Instagram, the browser unlocked Google Search, and Windows unlocked Excel. In each of these cases, it wasn’t only because they were a great product, but it was the distribution layer underneath that gave these great apps the chance to explode. Imagine if Uber and Instagram came in the pre-App Store era. They were technically possible, but they would not only have to create the best product, but also find as many shady websites to publish their apps to, and hope that users would go through the clunky app installation process to download their apps. With App store, both the user force and developer force converges into one platform allowing these good apps to flourish. Hence, if appchains are the solution to the technical constraints for apps, then a distribution layer must exist underneath so that these apps explode by expanding the number of accessible users for them.
This missing distribution layer is where Twine comes in. Twine starts by asking two questions: Why is it preferable for apps to launch on existing chains? Why do users use apps on the chain they’re on? Only by going to the core of these two questions, we can make the right design choices for Twine. Existing approaches like bridges and cross-chain messaging protocols provide a way for existing chains to communicate with each other, but still forces developers to operate individually with these chains. Our goal primarily isn’t to connect, but to eliminate them from developers and users experience, making all on-chain and off-chain venues feel like one unified distribution channel.
For the first question, the crypto industry has long thought value exists in synchronous composability. However, there hasn’t been any concrete evidence supporting this claim. It is also true that these apps haven’t been able to thrive in isolation. Hence, the truth is somewhere between. If you see a blockchain as a platform for a new app to permissionlessly integrate/compose with another application with ease, what makes their life easy isn’t whether the transactions execute at the same time or not. It’s that the development complexity (number of possible cases to handle) doesn’t increase exponentially, and rather stays constant regardless of the number of other apps your app interacts with. This property is atomicity and concretely solves a big developer experience problem at scale. Atomicity can be achieved in both synchronous and asynchronous settings. Hence, if we enable atomicity across appchains on Twine, we can provide the equivalent developer experience of building on an existing chain for any number of appchains on Twine.
For the second question, the insight here is that users use apps on the chain they’re on, not because they’re on the same chain, but because of the fact that the hard onboarding process (downloading wallet, creating an account, loading assets, etc.) is already done and users can just directly go use any app on that chain in one transaction. So, if these appchains can allow users to transact on their app in one transaction (bridge + create account + execute) from the chain a user is on without any significant delay, the user experience is indistinguishable from using an app on the same chain. An interesting insight here is that since an appchain is decoupled from a particular chain, the above solution is expandable to any number of chains, which means appchains can additively increase their distribution by enabling this feature on as many chains as they want. Meaning, the appchain that was struggling for distribution initially now can bootstrap distribution from not one chain, but as many as it wants.
Now that we’ve nailed down the most important properties of a monolithic blockchain and how that can be translated to appchains with the same developer and user experience, we can define how Twine would look like. Twine has its settlement contracts on multiple chains. These contracts act as an entry point for users from an underlying chain to the appchain. This is where the users would send the transactions for appchains to execute. A Twine node monitors all these contracts and publishes these transactions for appchains to pick up and execute. Each appchain sequences and executes its transactions and periodically posts state updates on Twine. The complexity for the appchains stay constant since they only have to interface with Twine (and not the underlying chains). Twine aggregates the state updates and posts them to the settlement contracts in underlying chains for finalization. So an appchain developer only focuses on building the best product and a user can use this appchain from whichever chain they’re in. All enabled by Twine, but invisible to the users.
Even though this covers existing onchain users, it only represents fractions of what can be covered. There is a huge pool of users and liquidity on centralized exchanges (CEX) waiting to be tapped into. One of the benefits of building your app on an existing popular chain is that your app can reach CEX users since they can onboard on your underlying chain, withdraw their funds from CEX to that chain and start using your app. This still is clunky, but there is a path and is at least much smoother than with appchains today. For appchains, the flow for CEX users today is to first onboard on a chain the CEX supports, withdraw funds there, find the right bridge to go from that chain to the appchain, onboard to the appchain, bridge the funds, and finally use the appchain. This, again, kills conversion much before it starts. Hence, for a serious flow of users and liquidity from outside the tiny onchain land, this clunky flow must be fixed. This is why Twine also supports one click onboarding from CEXs for appchain users. Twine’s SDK generates a unique deposit address on a chain widely supported by CEXs (eg. Ethereum, Solana, etc.) per user which they can deposit to and directly get credited on the appchain. This collapses the multi-step multi-platform flow into a couple clicks in the appchain and the CEX.
Now, an interesting insight here is that this mechanism doesn’t stay limited to CEXs. The same unique address can be used to onboard from any on-ramp services on existing chains. Meaning, if a user doesn’t even have a CEX account and funds loaded there, they can still easily onboard from fiat to the appchain within a few clicks. If a user has their funds in Venmo, they can onboard from zkp2p to the appchain, if they have funds in their bank account, Apple Pay, credit card, etc., they can onboard from MoonPay to the appchain. These services provided by Twine, not only allows appchains to onboard on-chain users, but all imaginable digital users. All without the appchain developer having to write a single line of code for it.
The story doesn’t end with covering all imaginable onboarding venues. Quite literally, it’s the beginning. Even in the absence of a network effects enabled platform, Twine as a product is already valuable for developers. However, the next phase of growth when onboarding is solved comes from retention. In other words, when a user enters the Twine ecosystem, how do we maximize the chances of that user and liquidity not leaving. Lets think about why users stay on an existing chain. It’s for two reasons: They have all kinds of apps they need on that chain and they can frictionlessly move their funds from one app to another on that chain. The first property is independent of Twine's protocol since it relies on external developers building user facing services, however the second property can be achieved at the protocol level. We allow a user who deposited on Appchain A, but wants to use Appchain B to pull funds from Appchain A and execute the action in Appchain B in one transaction, as if these appchains were on the same chain. This is a special case of atomicity property like we talked about above. The technical specifications for this can be found in the technical paper and are out of scope for this paper. However, the second order consequences this property enables is fascinating. These users don’t have to “sign up” to this new appchain, they just “log in.” Every new appchain on Twine has day one access to all existing users on Twine. Meaning, as the number and users of Twine appchains grow, there’s compounding incentives for new appchains to join Twine to tap into the existing userbase until Twine becomes the default Application Layer.
Finally, true network effects cannot be achieved without cross-application collaboration which leads us to the next phase: Discovery. When application development, onboarding, and retention is solved, there’ll be too many apps to comprehend. Both good and bad in quality. Hence, the next bottleneck becomes the user discovery for quality apps. Just like how browsers led to the explosion in the number of websites and Google Search helped users discover the highest quality websites for their needs. Or how the App Store led to the explosion in the number of apps and App Store’s discovery feed made sure users discovered the quality applications according to their needs. Twine also builds for this, but in a different and stronger flavor.
Instead of just building a dedicated frontend for discovery, we are building an SDK for appchains to integrate in their frontend to provide a better overall cross application user experience in the Twine ecosystem. Depending on the user's past actions and the current appchain it’s using, it would suggest a few actions to take on other appchains in Twine. For example, a user who swaps from BTC to USDT on an appchain would be prompted with options like “Earn 8% yield on your USDT” or “5X long ETH” in the same frontend leading to action on another appchain. This increases their own retention while feeding users back into the ecosystem. Over time, the accumulated data points would help the discovery algorithm to be more efficient, prompting tighter retention and usage across the ecosystem.
With onboarding, retention, and discovery solved, Twine pushes crypto into its dominance phase. Suddenly, developers just build powerful applications, with the idea of existing blockchains, its fragmentation and limitations completely gone and just Twine as a frictionless interface between apps and users. We’ll see an explosion in experimentative applications which leads to applications nobody imagined before. At first, we’ll see familiar apps like trading, lending, yield, games, etc., but over time, as the users and builders flow in, we’ll see new categories of apps that we hadn't imagined before. Over time, it becomes irrational not to launch your app on Twine since the benefits of launching your app on Twine would far exceed the benefits of launching your app elsewhere in all aspects. Even if you don’t want to build an appchain and just want to build an EVM app, it’s still strictly better to launch your app on an EVM chain on Twine instead of other chains. Hence, Twine doesn’t end up as just another blockchain (it isn’t!). It exists as the distribution layer where apps launch by default and where users from anywhere interface to use these powerful applications.