Chain Abstraction and Intent-Centric solutions are two architectural approaches aimed at solving the same fundamental problem: helping users do stuff across different chains.

Either approach has to answer the questions of "who to trust" and "how to prove that something happened on a different chain", but they differ significantly in how they construct their systems.

Chain Abstraction

Chain-Centric Worldview: Here, the user trusts a single blockchain and uses it as their "universal remote control" for all other chains.

User Interaction: User just interacts with the "Chain Abstraction" chain.

Obligations: The "Chain Abstraction" chain is responsible for producing the desired outcomes for the user.

Proof flow: User starts with their assets on the CA chain, therefore it's up to the CA chain to prove to the other chain what the user wants, to cause a transaction on the destination chain. Typically this type of transaction would first mint or unlock assets that the CA chain owns on the destination chain.

User Abstraction: Users are typically prompted to sign a transaction to land on the CA chain, and then eventually it will land on the destination chain.

Scaling: Scaling this system requires the CA chain to come up with a generic way to prove to other chains that "the user told me to do THIS on your chain". Because this has to be verified on-chain on any supported chains, practically this is usually an MPC solution, because it's easier to on-chain verify.

Latency: for users to use this CA chain, they'll typically have to deposit their funds into the chain. The deposit may take some time to confirm, depending on which chain the user deposits from. The CA chain needs to have an opinionated view on how many blocks to wait for each integrated chain. The CA chains themselves are typically fast finality chains and MPC solutions are typically fast to prove something has happened. So once the user's funds are on the CA chain, it's typically fast for the CA chain to spend it on the destination chain.

Intent-Centric Solutions

State-Centric Worldview: In this model, the user doesn't have to explicitly trust anyone or any chain, but they allow an open network of service providers to work for them based on the condition that they can prove to the user that what the user wants is accomplished on a remote chain.

User Interaction: Users interact with a service provider that's selected by the user's own rules.

Obligations: The selected service provider, whether through a reputation system or putting their own money at risk, is on the hook to deliver the desired outcome for the user.

Proof Flow: The service provider has to prove to the user that they delivered what the user wants on the destination chain, in exchange for the user's asset and fees on the user's host chain. This "proving" is always from the destination chain to the user's host chain.

User Abstraction: The user is prompted to sign an "intent" on their expected outcome on the destination chain.

Scaling: Scaling this approach requires a flexible way to verify however solver can prove to the user that their wish is fulfilled on the destination chain. This is because each destination chain is different, and we may have to use different ways to prove outcomes on different chains. This is mostly done with a "programmable custody" approach that escrows user's funds before they can be claimed to pay out to solvers.

Latency: Solvers can start working for the user as soon as they're willing to believe that the user's fund is in the "programmable custody". For chains where "finality" is subjective, each solver can make their own decision on how soon they can start working, and this can be even a dimension that users can use to choose solvers in the first place.

Opinion

We believe that the intent-centric approach offers a better architectural direction. It provides users with guaranteed outcomes, and the user gets to pick whether they want cheaper or faster execution. It's also easier to scale, because for each new destination, service providers could use whatever proving system supported on that chain to unlock the user's funds in custody.

However, achieving this requires that we start thinking about how to prove "what happened" on a remote chain to the user's host chain. Instead of thinking about how to build universal remote controls, we need to think about how to build different, per-chain crystal balls.

In other words, while onboarding each new chain to this system is still messy, we're not relying on a single "universal remote control" builder, but just require each service provider to bring different "crystal balls", as long as users are willing to believe those crystal balls are good.

In situations when we may need to do a special "button combination" on the remote control to express complicated app logic, now we need to do a "combination of crystal ball results" to believe something happened on a remote chain.

Intent Abstraction

If Chain Abstraction gives users a "universal remote control" to execute transactions everywhere, then Intent Abstraction gives service providers a "universal task description language" to describe what user wants. In Khalani's system, this also doubles as manufacturer manuals for crystal balls!

For more insights into Intent Abstraction and why it's crucial for solver integration to achieve collaborative solving, read the original thread from our co-founder and CTO.

Just as developers need to build apps to conditionally move funds across chains in the Chain Abstraction world, they need to also build apps to help users describe what they want in a specific way so service providers can build crystal balls to work with users!

Note: The concept of "Chain Abstraction" is still evolving, with various approaches spanning a spectrum from "chain-centric" to "state-centric."

For simplicity and comparison, "Chain Abstraction" is framed here as "chain-centric," which aligns more closely with the architecture of some of the original Chain Abstraction proponents. However, in reality, many newer architectures blend elements from both "pure chain-centric" and "pure state-centric" models, as seen in frameworks like CAKE.

Chain Abstraction (CA), Intents, and Intent Abstraction (IA)