Intents for everyone, with everyone.
Nomial is proud to support the Open Intents Framework
We're building the future of a unified Ethereum, alongside 30+ teams working toward this shared goal
Say hello to true interop for @ethereum.
In collaboration with many teams, we're building a universal intents engine.
The goal?
Seamlessly connect @arbitrum chains and other Ethereum L2s with < 3s crosschain swaps and transfers to achieve flawless UX. 🧵
Intent-solver systems are the silent engine behind Chain Abstraction
I studied 10+ Intent-Solver-Systems and created strong Mental Models for:
a. how they work,
b. their core components,
c. different zones in these system,
d. important players & their positioning
Grab your popcorn🍿
Enjoy the Short Summary Below.
Read the full article for an extensive overview. ( Link Below 👇)
---
An Intent-Solver system typically has 5 core components:
1. Intent Expression
2. Solver Selection
3. Intent Fulfilment
4. Proof of Completion
5. Solver Settlement
A system's approach toward implementing these components decides its overall efficiency, decentralization, speed & liveness.
Let's dive into each component
---
1. Intent Expression
The core responsibility of this component is to:
- Accurately capture the user’s intent.
- Allow users to authorize their funds required for this intent,
- Organize captured intent for solvers to interpret accurately.
---
2. Solver Selection
Solver selection involves specialized on-chain actors (solvers) competing to fill the user's intents.
Ideally, the system should have a fair mechanism to select the right solver for the job.
2.a Who is The Right Solver
It varies based user’s need and systems design but the most common metrics include:
- Faster Solvers: Solvers who can fill your intent quickly.
- Efficient Solvers: Solvers who can provide efficient results, i.e., better rates for cross-chain swaps, for instance.
2.b Why a Fair Mechanism?
- Ensures healthy competition, preventing a few solvers from dominating.
- Avoids monopoly risks like high fees, delayed executions, and order manipulation.
- Reduces liveness risk by not relying on a few solvers, preventing system halts.
- Improves user experience with better rates and fairer fees.
- Keeps the solver network decentralized, benefiting users and the system.
2.c Ways of Selecting a Solver?
- First Come, First Served (FCFS)
- Request for Quote (RFQ): Users submit orders, solvers bid within a timeframe, optimizing for price
- Batch Auctions: Orders are batched and processed together.
- Dutch Auctions: Starts with a high price, decreasing until accepted.
Quick Byte: Unfortunately, most systems currently fail to implement a fair selection mechanism and this is primarily due to a lack of solvers in the ecosystem. Operating a solver is hard but with standardizations, efficient settlements, permissionless solver entries, etc, the solver competition and selection should become fair and better.
---
3. Solution Generation/Intent Fulfillment
This component is primarily about how quickly and efficiently the selected solver can:
- Generate solution for user’s request
- Execute the user’s intent.
Solvers use different techniques to prove their efficiency in the system such as algorithms to find the best route for swaps, mechanisms to protect users from MEV, implementing optimized mechanisms to save gas, etc.
However, the crucial aspect is the access to liquidity to fill the user’s intent as solvers often front-liquidity using their own inventory without waiting for finality.
Therefore, The easier the access to liquidity, the faster & more efficiently the solvers can fill the orders, resulting in Better UX for users.
3.a Accessing Liquidity
- The common sources are AMM, Dex Aggregators, Private Market Makers, etc.
Some Innovative Solutions for this are:
a. Direct P2P Order Match - The “Coincidence of Wants” Way ( @CoWSwap , @EverclearOrg )
a. Borrowing Liquidity - The @nomial_io Way
b. Solver Co-Operation instead of Competition - The @khalani_network Way
c. Settlement via Netting ( and also CoW) - The @EverclearOrg Way.
All of these approaches are explained in detail in the article. Check it out.
----
4. Proof of Fulfilment
After successfully filling the user's intent on the destination chain, the solver must to provide some proof to the system to prove that the intent was accurately filled.
This is crucial because the solvers have risked finality and used their liquidity to fill user’s intent.
However, without proof of their work, the system cannot settle ( reimburse) the solver
There are different proof systems available currently that these systems leverage:
- General message passing
- Oracle Based Systems:
- Storage Proofs
- Light Clients
- ZK proofs
Quick Byte: While some proof systems are trust-based, some are trustless ( like storage proofs, zk proofs or light clients ).
With the use of trustless proof systems, however, the reliability and security of the system increase.
----
5. Settlement
The Final Component. This is where solvers are reimbursed/settled for all the liquidity they fronted or intents they executed with their funds.
5.a This component must ensure:
a. Reliable Settlement: Solvers must be paid accurately and promptly to maintain trust.
b. Fast & Efficient Settlement: Quick settlements help solvers maintain liquidity, enabling better execution and pricing.
c. Fair & Secure Settlement: Ensure solvers are fairly compensated and prevent system exploitation, with mechanisms to penalize bad actors.
5.b Settlement Techniques
a. Cross Chain Messages and Smart Contract Based Settlements: Chain A uses a smart contract to receive messages from Chain B and execute settlement logic when conditions are met.
Examples: @Uniswap's Reactor Contract, @deBridgeFinance 's DLN Bridge, CowSwap
b. Optimistic Settlement: Assumes transactions ( intent fulfillment) are valid unless their accuracy is challenged, reducing verification time and resources.
This significantly reduces the time and resources needed for verification.
Examples: @AcrossProtocol , @mach_exchange
c. Netting-based Settlements: @EverclearOrg addresses this by allowing most of the rebalancing activities ( approx 80% ) to be netted against one another, leading to a potential tenfold reduction in costs.
Now, the crux of Everclear is the fact that it allows solvers, or fillers, to socialize the costs of rebalancing by netting settlements against each other, significantly reducing the financial burden associated with moving funds across chains.
---
That was a brief glance at how Intent-Solver Systems work.
Read the article to get a clear understanding of each of these components in detail as well as the concerns and improvement scope in some of them ( which I couldn't cover here ). Link Below 👇
Before I wrap, Special thanks to:
- @knwang from @khalani_network
- @MikeCalvanese from @MikeCalvanese
- @hrojantorse from @intheanera
- @Innovictor from @AcrossProtocol and @UMAprotocol Head of content
- and, @manankpatni from @0xEpochProtocol
for all the review and feedback on this article.
Thanks to open-resources/technical-docs from @ParticleNtwrk , @SocketProtocol, @anoma, @BrinkTrade and @lifiprotocol. They were super helpful for anyone researching on these systems. Highly Recommended
Stay tuned fam.
Next Parts coming soon.
Cheers 🍷
❓How has the Chain Abstraction evolved?
❓What drives demand?
❓Are there liquidity challenges?
@MikeCalvanese and @andrew311, co-founders of Nomial, have a conversation with @ethanfr, Head of Developer Relations at @ParticleNtwrk, on these questions and more. Check out the full conversation on the evolution and impact of Chain Abstraction on Youtube:
https://t.co/3k8s8OL759
#Web3 #ChainAbstraction
Filling cross-chain intents is capital intensive
Fillers are constrained by the amount of capital they have available. Filling an order for $100k requires the filler to front $100k of value. Filling 10 orders in < 1hr requires the filler to front $1m
Fillers also need inventory available on every chain they support. Filling 10 orders for $100k each on 10 chains in < 1hr requires the filler to front 10 x 10 x $100k = $10m
When more users interact with more chains, number go up
For Chain Abstraction to work, we need to fix this problem
Where is the liquidity coming from for chain abstracted accounts?
Enabling users to have a single wallet across every chain and pay for gas in any token is key to chain abstraction. Making this work means finding mechanisms to execute actions on one chain while paying for those actions on another chain. This almost always means relying on paymasters/fillers/solvers which front capital.
This leads to a big problem for chain abstraction: protocols rely on fillers which in turn rely on lots of capital spread across many chains. There aren't many fillers out there with both the capital and the sophistication to manage large sums of assets spread across dozens or hundreds of chains. The trend toward modular rollups and app chains is only making this harder. Consequently, it's hard to bootstrap protocols.
What if there was a layer that allowed you to access capital across many chains effortlessly? Would it suddenly become much easier to build fillers for chain abstraction?
These questions inspired us to build the Nomial Inventory Access Layer. With Nomial, fillers can programmatically access capital across many chains. There is no need to raise or manage private capital.
For example, Universal Accounts on @ParticleNtwrk are one such chain abstracted account system that can benefit from Nomial's Inventory Access Layer. Particle Network relies on a network of Liquidity Providers (i.e., solvers or fillers) to move intermediary tokens between chains.
The attached diagram shows how this flow would work between Particle, Particle Network's Liquidity Providers (i.e., 3rd party solver), and Nomial. The flow is:
(1) A user with a Universal Account on Particle Network wants to perform an action. The user may or may not be aware that the action requires an asset ("Desired Asset" in the diagram) on a specific chain ("Chain 4"). The solver needs the Desired Asset on Chain 4 to perform the action on behalf of the user.
(2) Instead of maintaining their own balance of Desired Asset, the solver uses the Nomial Inventory Access Layer to tap into a reserve of Desired Asset already on Chain 4. They perform the action on behalf of the user.
(3) The solver executes the action on behalf of the user.
(4) The Particle Network repays the solver from the user's Universal Account using a mix of assets on miscellaneous chains (shown as Chain 1, 2, 3).
(5) The solver repays the Nomial Inventory Access Layer using the miscellaneous assets on Chains 1, 2, and 3. The solver doesn't need to perform any bridging.
This flow is much more convenient for the solver. It eliminates the need to maintain assets on Chain 4 or bridge assets from Chain 1, 2, and 3.
#Web3 #ChainAbstraction #crosschain
The problem that Nomial solves is simple - interacting with multiple rollups in a Chain Abstracted environment requires users to fragment their capital. This is costly and inefficient
The solution? Users can deposit on one chain and borrow on many chains
What about cost? The cost to borrow becomes exponentially lower compared to the cost of fragmentation as users interact with more chains. This holds true whether you are using ETH, stables, or any other asset
What about latency? Nomial allows collateralized users to borrow with near zero latency by validating actions through an off-chain service. Think about this like an EigenLayer AVS - a service that can come to consensus for actions taken in the Nomial protocol, backed by the security of ETH, without maintaining any on-chain state 🧠
Think this problem doesn't apply to you? Consider:
- the costs you've incurred using bridges. Both hidden and transparent fees apply here
- the gas tokens you hold on multiple rollups
- the opportunity cost of holding assets on one chain when your yield could be maximized on a different chain
Whether you are an end user interacting through a wallet, an advanced MEV builder or solver, a liquidity provider, or a market maker, you're incurring the cost of capital fragmentation
Let's solve this problem together 🚀
Liquidity scaling is critical for Chain Abstraction
In order for Chain Abstraction to scale to the entire ecosystem, new rollups need liquidity rails from the moment they're deployed. The cost of deploying and running rollups is negligible, but adding liquidity for bridging on rollups is extremely costly and complex
Newly deployed rollups need to pay bridges to support them. This dynamic should be completely flipped: rollup communities should get paid for supporting their own bridge liquidity
@nomial_io is the first bridging solution to prioritize scalable liquidity. No other solution allows a new rollup to deploy community provided capital for bridging starting at block 1 and get paid for doing so
We're seeing insane UX gains toward Chain Abstraction from @klaster_io, @ParticleNtwrk, @SocketProtocol and others. But in order for abstracted UX to work across all rollups, we need ultra-scalable, realtime liquidity that meets the pace of modular rollup deployments
Nomial helps enable Chain Abstraction through scalable liquidity. This is huge. Feeling bullish today 🐂