Introduction
The blockchain industry has a terminology problem. Just as “zkEVM” once encompassed everything from high level language equivalence (with EVM) to full Ethereum compatibility before Vitalik’s type classification system (Type 0 through Type 4) brought clarity by distinguishing between different levels of EVM equivalence and security tradeoffs, “chain abstraction” has become an umbrella term that obscures more than it reveals.
Today, protocols ranging from cross-chain bridges to unified wallet interfaces all claim to deliver “chain abstraction.” Yet the user experiences they provide are fundamentally different. Some still require users to think about chains, while others truly abstract this complexity. More critically, the security models vary dramatically. A system where users simply transfer funds to a solver and trust them to perform actions can technically provide “chain abstraction,” but it’s fundamentally less secure than a protocol where user tokens remain in protected vaults while solvers must prove their actions through validity proofs.
This confusion isn’t just semantic, it affects user expectations, developer decisions, risk assessment, and the entire trajectory of multi-chain infrastructure development. Users may unknowingly expose themselves to higher risks when different “chain abstraction” solutions have vastly different trust assumptions and security guarantees.
This article focuses on classifying various components in a chain abstraction protocols, enabling meaningful comparison across vastly different architectures. By decomposing these systems into their fundamental building blocks and analysing each component’s security properties, we create the common ground necessary for rigorous evaluation, informed decision-making, and ultimately, safer multi-chain infrastructure.
Why Security Models Matter
While feature completeness determines whether a solution truly abstracts chains, security models determine whether users should trust it. Two protocols might both achieve “true chain abstraction” from a UX perspective, yet have fundamentally different risk profiles.
The critical question: What secures user funds during cross-chain execution?
Analyzing Protocols: A Comparative Framework
To understand and to systematically compare the security tradeoffs of the spectrum of solutions claiming to provide “chain abstraction,” we need to be able to group the different components in the architectures into common generalisations to be able to compare them effectively. I propose the following generalisations:
-
State Keeper: The component or set of components that are responsible for maintaining order details and their statuses. All stakeholders act on the assumption of this state being the state of truth.
-
Executor: The executor is the component that determines how funds should be settled based on the state keeper’s records. It acts as the protocol’s settlement engine, calculating who owes what to whom and triggering the actual movement of funds.
-
Cross-Chain Messaging: The component that allows for cross chain events to be verified by the statekeeper and the executor.
-
Escrow: The component that holds user funds until told by the executor to disperse.
-
Solvers: Off-chain entities that execute user actions
By examining how each protocol implements these components, we can map where they fall on the security spectrums.
Protocol Configuration Matrix
| Protocol | State Keeper | Executor | Cross-Chain Verification | Escrow |
|---|---|---|---|---|
| Across | On-chain | Off-chain oracle — with UMA dispute resolution. | Optimistic — UMA, ZK verification for ethereum L2s (In progress) | Part of protocol |
| Nexus MPC | Off-chain | Off-chain with MPC verification | MPC | Part of protocol |
| Socket | Off-chain | Off-chain with modular security | Optional (Depends on the app using socket) | Optional (Depends on the app using socket) |
| Nexus 2.0 | Off-chain | Off-chain — With validity proofs | TEE Nexus / ZK Nexus | Part of protocol |
| Everclear | Off-chain | Off-chain (Arbitrum Orbit) | AVS | Part of protocol |
| Particle network | Off-chain | Off chain | TBC | TBC |
Understanding the configuration matrix
State Keeper: The Foundation of Trust
On-Chain State Keepers
On-chain state keepers provide a consolidated source of truth where stakeholders (primarily solvers who front liquidity) can independently verify state by choosing their preferred fork across different chains.
This is critical because solvers risk their own funds when acting on order states; if the state keeper reports incorrect information, solvers could lose capital. By keeping state on-chain, the protocol gives solvers the autonomy to select which fork they trust, removing the need to trust a third party’s view of cross-chain reality.
Off-Chain State Keepers
Off-chain state keepers, in contrast, remove this choice from solvers. The state keeper decides which fork to use and what state to report, introducing dependencies on the keeper’s honesty and creating attack vectors like state manipulation, censorship, and selective reporting. However, off-chain state keepers can reduce these trust assumptions over time through light client constructions that allow solvers to independently verify the fork used for reported states.
Additionally, off-chain systems introduce data availability assumptions, users and solvers must be able to access the state to unlock their funds or challenge incorrect settlements. Data availability layers (DA layers) are the strongest solution for off-chain state keepers, ensuring state remains accessible even if the keeper becomes unresponsive.
The key insight: on-chain state keepers empower stakeholders with fork choice and leverage blockchain guarantees, while off-chain state keepers trade these properties for efficiency but can mitigate risks through light clients and robust DA solutions.
Executor: The Settlement Mechanism
The executor determines how funds should be settled. Given a set of verified filled intents or orders, it calculates who owes what to whom and issues settlement instructions. On-chain executors provide the strongest security guarantees, but they’re also the most expensive due to gas costs and computational constraints.
When executors operate off-chain, the correctness of settlement instructions depends entirely on the security model employed. Some executors (like Across with UMA) provide optimistic security with economic dispute resolution (where resolution relies on governance voting rather than mathematical verification when challenged) , with token-based dispute providing financial deterrence rather than prevention. MPC-based executors distribute trust among multiple parties, remaining secure only if the honest threshold is maintained. Modular executors (like Socket) offer variable security depending on configuration, while centralized executors rely purely on operator honesty and reputation.
Notably, validity proof executors (like Nexus 2.0) aim to require cryptographic proofs of correct execution, which would make incorrect settlements mathematically impossible without breaking core cryptographic assumptions, however, no currently deployed protocol using off-chain executors has implemented validity proofs in production.
The key insight: on-chain execution provides blockchain-level guarantees at high cost, while off-chain execution trades security for efficiency. Validity proofs represent the theoretical ideal for off-chain executors.
Cross-Chain Verification: The Bridge of Truth
Cross-chain verification is the component that verifies fill events from other chains, the foundational input that executors use to calculate settlement instructions. Even with a perfect executor that calculates settlements correctly, if cross-chain messages about fill events can be forged or manipulated, the system will faithfully execute settlements based on fraudulent information. The executor cannot distinguish between legitimate and fake fill events; it can only process what the cross-chain verification module tells it is true.
Different verification approaches offer fundamentally different security properties. Each approach represents different trade-offs between latency, cost, and security strength. Cryptographic approaches provide the strongest guarantees but add complexity and cost, while trust-based approaches enable speed but introduce potential attack vectors where false fill events could trigger incorrect settlements.
The nuances of cross-chain verification mechanisms warrant deeper exploration in a separate analysis, but understanding that protocols employ vastly different approaches, from optimistic to cryptographic to economic security models, is essential for evaluating overall system security.
Escrow: The Custody Question
Escrow implementation is perhaps the most critical security component, determining who actually controls user funds during execution. However, escrow is fundamentally an implementation concern rather than a distinct security model. The escrow’s role is to correctly enforce the security guarantees provided by other components. For example, a properly implemented escrow must verify both an executor’s validity proof and cross-chain validity proofs before releasing funds according to settlement instructions. The escrow acts as the enforcement layer that ties together the state keeper’s records, the executor’s settlement calculations, and the cross-chain verification outcomes.
Currently, most chain abstraction protocols implement escrow through smart contract logic that programmatically enforces release conditions, though this may evolve for chains with limited or no programmability like Bitcoin, where alternative constructions would be needed. We may be seeing TEE secured wallets acting as escrows.
The key insight: Strong escrow locks funds with explicit release conditions tied to the protocol’s security model. Perfect upstream security becomes meaningless if the escrow doesn’t properly verify conditions before releasing funds.
The Compounding Effect of Component Choices
Security isn’t determined by any single component, but it’s the product of all components working together. A protocol’s weakest link determines its overall security ceiling. Even if an executor generates validity proofs, an adversary can feed it false order states, and forge cross chain messages, causing the executor to correctly execute incorrect settlements.
Similarly, perfect state keeping and settlement calculation mean nothing if users transfer funds directly to solvers without escrow protection, then the solvers can simply disappear with the funds. Even when all components are individually strong, misalignment can create vulnerabilities: an escrow that releases funds based on the executor’s validity proofs without verifying the validity of events still makes the protocol vulnerable even with validity proofs.
This compounding effect means protocol security must be evaluated holistically. Marketing materials often highlight the strongest component while obscuring weaknesses elsewhere, a “ZK-secured” protocol might only use ZK proofs for one component while relying on trust assumptions in others. Users and developers must understand the full security chain, not just its strongest link.
Conclusion
This component-based generalization provides the foundation for creating a classification framework across the security spectrum, from trust-based systems relying on operator honesty to cryptographic approaches offering mathematical guarantees. However, a complete picture requires a parallel classification framework for the feature spectrum as well, distinguishing bridge abstraction (where users remain aware of chains) from true chain abstraction (where chains become invisible).
The path forward requires both honest communication about current trade-offs and continued innovation to achieve strong security without sacrificing features. Understanding these differences and having precise language to discuss them is essential for users making informed decisions, developers building responsibly, and the industry evolving toward genuinely secure and abstracted multi-chain infrastructure.