Introduction
In June 2023, Paradigm published an excellent blog post describing the ideas behind existing intent-based blockchain solutions, exploring benefits and challenges related to these, highlighting potential fixes, and mentioning several projects along the way.
In this post we hope to demonstrate that most (if not all) of these problems are not related to the general idea of intents (users declaratively expressing what they approve), but rather consequences of implementation choices. By providing a universal intent vocabulary that covers every need, from single and multisig to generalised orders, AMMs, derivatives, and trustless lotteries. Saline even provides a path to removing Smart Contracts altogether and fully relies on intents and on-chain data to empower users and developers and make liquidity more decentralised and accessible than ever, without jeopardising the safety of the assets at any point.
A spectrum of intent abstractions
In all Intent-based blockchain platforms, the intent is considered to be a declarative specification of a desired outcome published by a user that other parties, usually called matchers or solvers, will work on satisfying. Fulfilling an intent typically involves submitting a combination of transactions on one or more blockchain networks when suitable conditions are met. Thus, orchestrating potentially several seemingly unrelated transfers to provide the user with the result they want.
While the declarative nature of intents has always struck us as best-in-class in terms of user experience, the existing (proposed) solutions seem to focus on one particular subset of "desires" at a time (e.g. Anoma and Brink) or arbitrary application-specific subsets (e.g. Khalani). What felt missing to us, was a unified, universal vocabulary to declaratively specify under what conditions a user is willing to let third parties touch the user's assets. From the very conservative "I need to approve every single transaction" to "please take any amount of ETH from my wallet, up to 10, in exchange for either BTC or an unleveraged long BTC perp position".
Saline Intents provides exactly such a vocabulary
They allow users to specify a list of rules that guard their assets. These rules range from signatures, to conditions on prices, and to ZKPs: they can go way beyond simple trades or swaps, and can dictate complex requirements between a set of related transactions that constitute a single atomic bundle. You can enforce that a wallet may only be used as e.g. a decentralised, fully determined and autonomous AMM, a fully trustless lottery wallet, or any other transaction-based-application-built-on-modular-conditions that the user's imagination can conjure. The key idea resides in the change of perspective, away from Smart Contracts as a common, neutral place for parties and assets to interact, and towards users and their rules, that the Saline blockchain then proceeds to enforce on any transaction touching a user's wallet.
The decentralised Saline Network is then responsible for validating transactions touching assets guarded by such rules, allowing users to onboard and offboard assets from a variety of networks, and more. Intents can be installed on-chain or, as is already the case in existing intent-based tech, be passed around to external parties and services who will look for suitable counterparties, liquidity, or other resources to fulfil them and get a reward for their service to the network and its users.
If you want to read more about the Saline Network, you can head to our first blog post introducing the project, as well as the second post covering specifically our new intent abstractions.
Pools, permissions and scalability
The biggest challenges in intent-based systems revolve around what Paradigm and other actors call "intent pools". Intent pool is the generic term used to designate avenues where user intents go and propagate, and where solvers/matchers are listening to help fulfil them, with the whole ceremony having to follow some rules that vary from a system to another.
In some systems, the intent pool is permissioned. Some special trusted entity is in charge of running the service and treating all requests (hopefully) fairly, with respect to both users and matchers. This goes against the general trend in the crypto space; of relying increasingly less on centralised services and trusted entities. Other projects like Anoma and Khalani designed their system so that the intent pool is effectively permissionless, decentralised, made up of nodes that receive and propagate intents, very much like blockchains do with transactions propagating through mempools before landing in blocks.
The Paradigm piece highlights various issues and attack vectors resulting from both types of intent pool designs, reproduced below. Such problems prevent Intent-based solutions from scaling in regards to both complexity and volume.
The next section looks at some of Saline's features and how they impact the above problems.
So, how is Saline different?
At a glance, the main differences between Saline and other intent projects are:
Universal intents that can express any conditions or complex interaction patterns for guarding your assets or, on the flip side, making them more easily accessible, with just one vocabulary known and shared by all actors.
Intents are a precise spec for validators to follow when verifying transactions, combining various building blocks, from signatures, to conditions on prices, and to ZKPs.
Ease of use: from onboarding to custody and use, to offboarding, intents can help users and developers secure and use assets across the whole journey, through our intent UI or simple client SDKs in various standard programming languages.
Decentralised and trustless intent matching and validation, inviting users into the entire process while rewarding them for it, as opposed to centralised or solver-auction based solutions.
Khalani is most likely the closest project to Saline, but leaving the choice of "intent vocabulary" to applications provides more flexibility at the cost of complexity. Saline on the other hand has one well-defined intent vocabulary and grammar, which in practice handles all the use cases previously listed and more, and might evolve to offer new building blocks as the industry develops new technologies. This universal story also allows us to build general SDKs and a dedicated intuitive UI, allowing users and developers to more easily express what they want to do with their assets. In a world with thousands of Khalani intent theories floating around, powering millions of transactions every day, such a unified view of all the possibilities would not be possible, making the whole system less accessible to users and matchers alike, maintaining unnecessary silos.
We believe the particular design proposed by Saline empowers users by being designed for simplicity while enabling the best-in-class user experience of intents, all with the censorship resistance of modern proof-of-stake blockchain protocols. There is no need to sign transactions all the time with the right intents in place. No need to trust or audit smart contracts maintained by third parties, or maintain a complex web of permissions. You can just focus on your assets and your rules.
Mitigating the risks of intent-centric ecosystems
The main concerns of intent-centric ecosystems as highlighted by Paradigm:
The ecosystem should be permissionless, such that anyone can match and execute intents without large tradeoffs in execution quality.
General, so that new applications don't require new mempools or changes to the intent system
Transparent
The Saline Network is inherently permissionless and general. Intents can be attached not only to Saline wallets but also to existing wallets on existing networks. This essentially allows you to use Saline intents to reason over whatever L1 you normally interact with and enforce your Saline rules there.
The issue of opacity
One of the biggest fears of various other intent-centric systems is the lack of visibility. You submit your intent to some network and then it gets lost in the ether. Then after an arbitrary amount of time, this intent "materialises" as a transaction with little clarity on how or by whom the transaction was created. This makes it difficult for the community to observe and audit the intents-to-transactions ecosystem for threats or collusions.
Saline has no intent layer floating above existing chains or a dedicated one. The intent layer is the chain itself, thus making it trivial for users and builders to monitor intents installed on the chain. They can also receive intents from third-parties through other channels, and help fulfil them, with the user intent only being revealed to the rest of the world right when it gets fulfilled. On-chain transparency in Saline is thus guaranteed. The user doesn't need to care about how or by whom intents are matched. This "dark forest" scenario, as described by Paradigm, is thus not an issue in Saline.
There is no Order Flow Auction (OFA) process in Saline. If the party handling the auction is centralised, they might prioritise some solvers/matchers over others. In Saline, however, the first to get included in a block wins, and block proposers rotate as per the usual Proof-of-Stake dances. The security of intent validation is therefore derived from the security of the Saline network itself. However, this does not prevent third parties from building matcher services that accept intents and match them off-chain, or even from building auction-based intent processing with a distributed pool of solvers, using Saline as a "mere" settlement layer.
We therefore believe that our design empowers intent matchers and builders by having a low barrier to entry. Anyone can start earning matcher rewards by clicking around in the wallet application and submitting transactions that fulfil other people's intents through the use of filters on a big table they can scroll through. More tech-savvy users can whip up a quick script that scans for intents and tries to find matching pairs, to earn matcher tips with a few spare hours and a Raspberry Pi.
Experienced teams can even build their MPC wallet services, market-making logic, swaps, and spot or derivative exchanges on top of our platform, where intents are primarily applied to get rid of counterparty risks. And this just covers an obvious set of use cases that are the current mainstream of blockchain applications.
Conclusion
Our ambition for this post was to provide a modest extension to Paradigm's reference article from last year under the lens of Saline's intents, revisiting many assumptions and conclusions along the way, while contrasting some of our ideas with alternatives in the same space. We will be discussing more aspects of Saline in future blog posts, stay tuned! 🚀