Blockchains are but the substrate for building awesome things, and their permissionless nature makes it such that there is hardly a perfect solution to any one problem they face. This was first expressed using the “blockchain trilemma”, which loosely defines that every monolithic blockchain has to make tradeoffs between decentralization, security and scalability.

The realization of this problem and its understanding has ballooned since its conception, with various designs concurrently proposed as solutions.

Besides the optimizations in particular verticals, there are also solutions which have risen to address particular issues.

All these developments have led the crypto industry to what we are today; a discordant network of siloed development where the wheel has to be reinvented over and over again across traction-seeking chains.

In this article, we intend to present the problems that have surfaced over the years due to the unending quest to produce the “ultimate blockchain”, examine the source(s) of these problems and present the relatively recent design philosophy of chain abstraction that seeks to solve crypto's fragmentation problem. We then go over the design choices of the SOCKET Protocol and examine how their tooling propels crypto UX towards unification and simplification.

Ethereum and the EVM's coveted Turing-completeness

The emergence of Ethereum as the first smart contract chain enabled by the EVM led to the ideation and development of decentralized applications (dAPPs), which seeked to offer various forms of financial and social services in a censorship-resistant manner.

However, it was obvious from the start that there was still a lot of work to be done so that applications aren't constricted due to the chain's own limitations. The initial approach to this was the introduction of primitives which were flexibly compatible in this context— AMMs in their various forms and pooled lending markets are some of the more recognizable of such primitives which were pursued due to the limitations of existing infrastructures’ execution and consensus gadgets.

Due to the EVM's incumbency, most projects at the time seemed to focus on the limitations of Ethereum's consensus gadget thus offering higher TPS values, faster block times and larger block sizes relative to Ethereum. However, the EVM remained the standard for execution in smart contract chains. This led to a period of stagnation where lots of barely distinguishable alternative L1 blockchains were launched, with increasingly diminishing returns and to widespread criticism. However, they mostly copied the EVM's design and were consequently EVM-equivalent to different extents.

Eventually Alt L1s became differentiated by implementing new virtual machine designs, commonly referred to as altVMs, that offer a different set of tradeoffs relative to Ethereum. This led to a new approach for alt-L1s; optimizations in both the execution and consensus areas.

Ethereum's rollup-centric approach to scalability concerns

There is hardly any doubt that Ethereum's sustained success is primarily due to the EVM. Its consensus gadget isn't exactly optimal for applications due to its greatly limited scalability, and so has been a major area of research and development as evidenced by achievements such as The Merge, Proposer-Builder Separation (PBS) and other continued research efforts.

While alt-L1s have continued on their rampage from the previous cycles with relatively less success, Ethereum pivoted its approach to scaling concerns from sharding to rollups and other L2 designs. This approach allowed specialized blockchains to benefit from Ethereum's security and censorship-resistance, while maintaining the ability to optimize their platforms for specific applications or features.

The underlying point of L2 networks is that they offset some portion of the work to an underlying L1 network (Ethereum in this case), so that they can easily optimize in specific directions, be it speed, state management, consensus mechanism, or more user-focused objectives (dYdX v3, LAST network, Unichain). This essentially allows a radical distribution of efforts in a cohesive manner and is now commonly referred to as modular scaling.

Following the pivot to a rollup-centric approach, some alt-L1s whose execution gadgets are EVM-equivalent have decided to become a rollup on Ethereum and benefit from its security guarantees, thereby joining hundreds of other teams building both general-purpose and application-specific rollups on Ethereum to build towards a composable future with lower trust settings.

The problem with the rollup-centric roadmap is that “state” is still dynamic across each rollup, and most general-purpose rollups offer marginal improvements relative to their peers. This would probably be a non-issue if rollups weren't siloed away from each other at the start and didn't have to justify burning through cash to find (and retain) some traction, because in such settings it mostly comes down to who has the best marketing team.

[PS: this ties into the topic of the extractive nature of some recent token launches; bootstrapping is a hard job and there are many mouths to be fed in order to even have a shot at gaining some attention]

The common design of existent rollups are such that they are only composable with the L1 to an extent and aren't interconnected with each other, leading to understandable but misled claims that they aren't very different from alt-L1s.

The difference is that there are backwards-compatible approaches to enforcing composability across Ethereum's rollup ecosystem, due to their implementations of the EVM or EVM-compatible gadgets. This can't be enjoyed by radical altVM implementations.

The outstanding proposed designs being researched as mechanisms for enforcing ecosystem-wide interoperability are:

• rollup clusters

• shared sequencing

• account abstraction

We will now briefly elaborate on these below.

Rollup clusters

Recently, most of the initial general-purpose rollups have independently designed frameworks for other rollups (be it an L2 or L3) to launch and immediately be composable with their established ecosystems. In this way a network of rollups which are designed with similar trust assumptions and thus homogeneous with each other and Ethereum is easily established.

Optimism currently leads the charge in this aspect with their conceptualized Superchain, which features rollups launched using the OP-Stack framework. Other examples which follow closely are Arbitrum with their Arbitrum-Orbit framework, and Polygon with Agglayer.

However this approach still leaves much to be desired, as existing rollups cannot readily take advantage of this cluster approach without a near-total overhaul of their current mechanisms, which is a huge ask. What is needed is a solution that empowers the already existent ecosystem while providing a platform for new rollups. Agglayer's design choice bears this in mind but is still in the conceptual stage, and support for L2s launched without their zk-EVM is even farther along the roadmap.

Shared sequencing

Sequencers in rollups are responsible for running the execution gadget adopted by the chain, and so are responsible for executing transactions on the rollup and consequently giving users a guarantee of execution on the L1. This guarantee is referred to as soft finality as it could still be reversed on the L1 in extreme cases. For more on sequencers please refer to our in-depth report on the topic here.

Shared sequencing networks seek to provide a flexibly adaptable execution gadget for blockchains under specific conditions. They are state-agnostic implementations that seek to allow an established set of executors (block builders, validators, attestors etc.) to provide execution or ordering guarantees to blockchains which integrate their offerings, by building partial or full blocks which are executed across the relevant chains in an asynchronously atomic manner.

They are proposed to allow rollups to adopt an existing sequencer set, and depart from the single sequencer model, thus achieving greater levels of censorship-resistance without having to take on the relatively greater cost of bootstrapping an effective sequencer set.

Thus, shared sequencing models seek to provide a superset state of the individual states of any set of blockchains which opt into their implementation.

Notable examples of designs in this category include: Espresso, Anoma and SUAVE.

Account abstraction

Account abstraction was initially proposed as a means to simplify and unify interactions for accounts within Ethereum, but it is now recognized as a potential solution to its rollup ecosystem's fragmentation problem.

Enshrining standards for transaction formats across Ethereum and its rollups means that an “alt-mempool” structure can exist and be used for atomic cross-chain transactions. This doesn't affect any specific network's manner of processing normal transactions as the alt-mempool simply serves as an alternative.

Account abstraction is the removal of enshrined constraints on the manner in which accounts can interact with the network. It generalizes the account model of a chain in a bid to unify and simplify UX and DevEx, while unlocking benefits such as gas payment abstraction, conditional access policies and execution batching.

Account abstraction in its current form is designed to serve only EVM and EVM-compatible execution gadgets, so that altVMs remain siloed. The intuitive reason for this is that altVMs are designed to be radically different from the EVM, so that designing a mechanism to handle operations from accounts in either context is an intensive task that neither ecosystem is currently concerned with solving.

These outlined designs mostly seek to serve Ethereum and its rollups, providing varying degrees of interoperability with different security guarantees and trust assumptions. The economic aspect of interoperability is a nontrivial research space and has been the major deterrent for most approaches, however progress is being made. What we do believe is that the existence of multiple approaches (with new proposals such as RIP-7755 emerging) exhibits Ethereum's strong research base and will prevent overindexing on any one approach in the case that it leads to problems in the future.

While Ethereum leads the interoperability discussion with designs seeking to cater mostly to systems with varying degrees of EVM-compatibility, there are still existent and upcoming altVMs which users and developers will definitely seek to use, and there should be mechanisms to allow EVM-altVM interoperability. The common approach to this is the use of cross-chain communication protocols which we will now discuss below.

Cross-chain communication protocols

Cross-chain communication protocols are typically designed to serve as guarantors of cross-chain execution on any networks they steward, whether EVM-compatible or not.

Commonly referred to as bridges, this family of protocols enable one or both of the following:

1. cross-chain asset migration

2. cross-chain asset swaps

They are able to do this by establishing and maintaining a transport layer between distinct networks, verifying the data passed across said networks using their transport layer and updating the state of the relevant networks to reflect the changes made due to the data communicated across them.

The transport layer is typically stewarded by offchain agent(s) who “watch” supported chains and post data from an origin chain to the specified destination chain without examining/verifying the data's authenticity. A verification layer handles the function of proving data integrity using any number of methods, in order to ensure that the data they receive is consistent with the data that was originally sent as recorded on the origin chain. An execution layer then implements a state transition function (STF) on the destination chain using the communicated data. It achieves this by employing a different set of offchain agents who receive authenticated data and use its variables to trigger specific operations as defined by the constructor of the message on the origin chain.

Thus, cross-chain communication protocols keep record of the state of heterogeneous networks, and in the basic case they either

1. provide users with mirror assets of their choice from an originating network to the destination network,

2. trigger specific operations, as defined by a user on the origin chain, on the destination chain.

Therefore, they serve as a singular source of trust to users who seek to move across networks with heterogeneous trust assumptions.

While undeniably useful, cross-chain communication protocols are for the most part a necessary evil. As shown by the results of Zamyatin et al., cross-chain communication is impossible without a trusted third party, or mildly– a single source who provides guarantees across all the networks being considered during an operation. The economics of most existent CCC protocols –relative to the networks they traverse– simply aren't encouraging enough for them to be this source.

Any bridge that doesn't benefit from or share the security guarantees of the networks it helps communicate bears significant risk as has been shown over the years. Be it a lock-and-mint model, intent-based model, or liquidity pool model, any “non-native” bridge is a potential honeypot due to the security risks stemming from both their technical and economic designs (no disrespect to our bridge friends). So now you may wonder, what makes a bridge native and why is it more secure? We'll see below.

Native/Enshrined bridges

Native bridges are referred to as such due to their enshrinement within a host network's execution gadget. They are commonly implemented by smart contract rollups to enable trust-minimized cross-chain communication between the rollup and Ethereum via cryptographic proofs, which provide the latter with a non-intensive method for verifying state transitions on the former.

In this mechanism, the rollup gives up its sovereignty to the parent chain and thus is almost as secure as the latter is, so that there is no need to introduce a third party who is responsible for providing such guarantees as is common in other designs of cross-chain communication protocols.

For more on the topic please refer to the comprehensive report here.

Bringing the conversation back to the context, native bridges can overcome the problems that come with the necessity of a trusted third party by adopting a third party with trust-minimized frameworks (such as blockchains) as their source for guarantees. This comes with its own unique risks and tradeoffs, but reorgs and 51% attacks are less likely than bridge hacks.

Decentralized networks and the valley of tradeoffs

The interoperability goal is technically hampered by the heterogeneity of trust assumptions and security definitions across networks. This technical roadblock can be considered a result of various tight definitions being the accepted standard of siloed social circles with almost incompatible incentives. For example, it isn't inaccurate to say that Ethereum prioritizes security and censorship-resistance over “shipping”.

This social factor has become more obvious in the last year following the increased hype around altVMs which is mostly narrative-backed. The Ethereum/EVM approach of prioritizing decentralization, censorship-resistance and security over L1 scalability for applications and application developer- and user-experience has been criticized greatly; but this is a deliberate design choice to strengthen the foundations of an envisioned interoperable multichain future.

Thus, we can reductively ascribe the lack of a standardized definition for trust across execution environments as being due to different levels of its understanding within the industry, and thus as responsible for the fragmentation that crypto users and dAPPs suffer from. This problem would probably be best solved by a backwards-compatible design whose assumptions are a superset to any set of trust assumptions made by the networks it serves, but this solution is no small feat and will likely see little traction if the networks in question have to actively opt-in.

As an industry, we've spent too much time obsessing on vain metrics and definitions that don't immediately translate to the primary objective that should be satisfied by any user-facing application built atop these networks— usability.

This isn't to say that these arguments or the points being made are not important, or that existent applications are any less important or unusable (their ideality is an entirely different argument though); but the primary point of blockchains is that they are immutable and censorship-resistant foundations for various forms of applications to be erected.

The explosion of smart contract chains, each one offering optimizations in certain aspects relative to others or even directly copying existing implementations, has caused the frequently cited problem of liquidity fragmentation. But it's not just liquidity being fragmented, it's also developers, users, applications and DevEx/UX. All this (reductively) stems from a single problem— state fragmentation.

Tradeoffs are normal and aspect optimizations are fair, but they must be made such that the networks they enhance remain composable with each other. This means that the liquidity-agnosticism we crave for applications and users isn't possible unless it is something of a built-in feature at the very root of the networks that enable the former.

While blockchains serve as trustless and censorship-resistant foundations for applications, general-purpose blockchains face a crucial limitation: they cannot effectively optimize for every possible use case. This reality has led to the rise of application-specific blockchains (appchains), which address a fundamental tension in blockchain design. While distributed systems should ideally be unopinionated, developers must make specific trade-offs to optimize for their applications' needs. These trade-offs inevitably impact the applications' functionality and user experience. As a result, many applications may achieve better results by using their own specialized chains, enabling  optimizations tailored to their specific requirements.

Ethereum's rollup-centric roadmap offers such applications the benefit of launching as a rollup and benefitting from a suite of tooling that has been somewhat standardized, while being able to offset some aspect of their consensus to the L1. The presence of native validating bridges with trust-minimized assumptions between smart contract rollups and Ethereum offers the former immediate interoperability with the most secure blockchain, and soon the rapid development of the designs we briefly discussed above will yield trust-minimized L2-L2 interoperability.

However, while the research is still being conducted, state remains fragmented and users remain at the mercy of cross-chain communication protocols with unjustifiable trust assumptions.

State heterogeneity and its consequences

State refers to the data necessary for ensuring a network's liveness, i.e.; that blocks are being produced and validated as they should. A blockchain's state transition function refers to the process via which this data is utilized to produce new state.

State fragmentation arises due to differences in trust assumptions and design choices at the chain level, and trickles down to applications.

On account-based smart contract chains, state is already greatly variable due to the interdependence of contract execution and the inability of said contracts to access the states they wish to alter beforehand. This affects the success rate of atomic operations, but at least it is an all-successful-unless-revert situation and users don't have to pay too much for failed operations. This advantage is due to the monopolistic design of most consensus mechanisms; a single agent is responsible for providing execution guarantees and thus can credibly commit to execute it or not. This isn't the case for cross-chain operations as there is no single leader.

Consensus mechanisms vary greatly from chain to chain, and so do the conditions an agent must satisfy in order to be granted execution abilities. This means that the qualities and functions of a validator on a network such as Ethereum is greatly different from that of validators on Sui or Aptos; these differences are due to the different design choices made by their consensus mechanisms both from economic and engineering perspectives.

This implies that there is no trust-minimized single source of execution guarantees for atomic cross-chain operations; and in the absence of a willing counterparty to provide such guarantees users risk partial execution of their desired operations in the worst case, and in the better case they adopt designs whose trust assumptions aren't beneficial. This directly translates to bad user experience and potential losses amidst other issues.

The fragmentation due to trust and state heterogeneity shows itself in various forms as follows:

1. Liquidity fragmentation: liquidity is the easiest measure of any protocol's success. The continued existence of huge amounts of liquidity across Ethereum's DeFi sector –despite commendable contest from alt-L1s– is a testament to its battle-tested execution environment which gives developers a sense of security.

New execution environments face a chicken-and-egg problem where there is a scarcity of liquidity due to participants’ aversion to risk. This problem is combated via reward schemes for early supporters (points, airdrops etc.), but the recent trend of these schemes towards extractiveness, as well as regulatory uncertainty have potentially eliminated user trust.

Thus, liquidity will likely remain greatly siloed within ecosystems due to the risks users associate with cross-chain interactions. This lock-in of liquidity causes decreased capital efficiency and loss of potential revenue for users.

2. Application fragmentation: this can take two forms: i) the instance of a dAPP on chain A being non-composable with its instance on chain B, or; ii) applications on chain A being unable to take advantage of beneficial features offered by a different dAPP on chain B, which aren't offered by any protocols on chain A.

These problems affect the deployment choices of dAPP developers and go on to affect users’ experiences.

The EVM remains trendy due to the battle-tested suite of contracts that exist on it and years of its behaviour's formalization, compared to other execution gadgets. However, there are applications better suited for custom execution gadgets which will still occasionally have to interface with “more regular” applications, without a way for these applications to trustlessly interface the wastage of resources on wheel reinvention will continue.

3. Asset fragmentation: arguably the most annoying manifestation of fragmentation, the existence of different instances of the same asset issued across applications and chains with varying liquidity and usability profiles is a great pain point.

Due to assets’ conformance to different execution standards and a limitation on the amount of networks service providers such as wallets can provide due to the costs, users have to generate and manage multiple accounts across multiple networks in order to have a comprehensive view of their asset inventory. This is compounded further by the amount of liquid staking/restaking and wrapped tokens issued by various applications on the same chain for their niche usecases.

We've been so stuck on arguments concerning blockchain mechanism design that it seems we've forgotten that general-purpose blockchains are merely baseplates for actual user-facing applications. These arguments are certainly important if we aim to remain decentralized and censorship-resistant, but the point stands that the proliferation of general-purpose smart contract chains with distinct security assumptions and designs is negative for everyone involved. Multichain is only cool when the chains are easily compatible, and chain abstraction seeks to provide a framework for this compatibility.

Chain abstraction; traversing heterogeneity

Chain abstraction is the overall goal of unifying crypto's increasingly modular stack and building in cohesion to achieve secure settlement of interactions across multiple chains in trust-minimized settings, rather than a specific mechanism that does so.

Chain abstraction isn't the enablement of cross-chain operations, those already exist (1i1o operations), it is the orchestration of various design choices to offer users a simplified experience on their applications without the constraint of the underlying blockchain (1iMo, Ni1o, NiMo operations).

Thus, it is expected to be most obvious at the application layer, offering users a consolidated interface for their interactions and balances across various states by using a set of infrastructure built towards the goal of composability.

Still don't get it? Chain abstraction is one of the primary functions of centralized exchanges: consolidating user balances across various states and allowing them to use it as they please in a specific/supported manner without having to manually consolidate their balance. If you deposit 500 USDC from Op-Mainnet to Coinbase/Binance/Kraken, and another 700 USDC from Arbitrum; your balance is simply exhibited as 1200 USDC which you can use as a whole to purchase ETH without any other operation. If you deposited in the same manner to a wallet provider such as MetaMask, the chains on which these assets reside are specified and as such you cannot spend them as a whole.

Wallet providers aren't to blame though, maintaining user balances via a homogeneous interface for multiple networks while maintaining the verifiability of said balances is a hard duty with many potential attack vectors. And it's not just them, it's also user-facing applications such as Uniswap and Aave.

However, with considerable progress and growth in our reasoning around product design and engineering, it isn't impossible to provide the same UX as CEXs with less the trust (even if it isn't immediately as maximally trustless as DeFi is expected to be).

From the previous section it is obvious that any mechanism geared towards chain abstraction has to fall into at least one of the following categories:

1. Solutions to liquidity fragmentation: cross-chain operations via e.g., chainless swaps, cross-chain intents.

2. Solutions to application fragmentation: establishment of application meta-states to enable applications transcend the limitations of application development on each chain they are deployed on.

3. Solutions to asset balance fragmentation: unification of asset interfaces via proposals such as ERC-7281 which enables xERC20s, and aggregated balance interfaces.

Below we will now discuss how the SOCKET Protocol provides an coordination framework/layer for these solutions.

SOCKET and its place in the chain abstraction framework

SOCKET contributes to the chain abstraction initiative as a chain-agnostic and modular protocol, which offers the benefits of multichain composability to both applications and users. Applications deployed on multiple networks can take advantage of SOCKET's tooling to enable the creation of transaction structures referred to as chain-abstracted packets, which can execute in an asynchronous manner.

Below, we'll go over SOCKET's architecture.

SOCKET CAPs for dAPPs

Multichain applications can employ SOCKET's packets to enable asynchronous reflexivity. In this way, actions carried out on a single iteration of the protocol on a different chain can be easily reproduced on a different iteration of the protocol on another chain, without the user having to manually make use of cross-chain bridges. This essentially grants the application a “meta-state” which can cause state alterations on any chains the user's requests (structured as packets) are executed.

Using Uniswap as an example: The application will be exhibited on SOCKET as a simple meta-application which represents its various contract deployments across networks, this meta-application reductively holds the entire state of uniswap and thus can allow users to swap/LP on the Arbitrum contract from the Mainnet contract in a single action from their perspective. The actual transactions involved (bridge, then swap/LP) are still properly recorded on each respective chain.

SOCKET's implements an offchainVM which consists of the following:

• User requests: which are essentially transactions signed by the user with an offchain authorization scheme, as permitted by the respective application.

• Application contracts: these are minimalistic/lightweight instances of applications, designed to connect the SOCKET Protocol to contracts of the desired application on multiple chains. They are responsible for presenting an interface for users to craft their requests and pass them on for responses.

• Transmitter responses: which present an execution route, as defined by the respective application, to the user-generated request. If valid, user requests are combined with a winning response to produce an executable structure referred to as a chain-abstracted packet (CAP).

 

• Gateway contracts: these hold the logic which is responsible for the combination of user-requests and agent-responses into executable CAPs. They are designed as offchain application-specific logic that enable onchain execution of CAPs for the application being considered, by authenticating user requests and their responses.

These contracts are hosted by agents referred to as watchers, who track supported chains for user requests. They run and maintain the gateway, and are intuitively responsible for parsing requests and responses into CAPs.

 

• Switchboards: these are used to provide a consortium of validation logic used by the gateway contracts during the authentication of user requests and agent responses.

They are lightweight contracts that enable application contracts to define uniquely arbitrary logic which must be satisfied for an operation targeting the application to be successful.

These contracts and actions all settle and occur atop SOCKET's contract, allowing it to serve as a quasi-settlement layer for interactions carried out using the protocol.

After a CAP is successfully parsed, agents referred to as transmitters are responsible for their execution. They submit execution requests via the gateway, thus participating in an auction for request execution rights (more on this in a bit).

If executed successfully, SOCKET implements the necessary state alterations due to the CAP across affected networks.

Thus the totality of the SOCKET Protocol's process occurs as follows in the typical scenario:

1. the user sends a signed request to the application's gateway via a provided interface

2. Watchers broadcast the details of a user request, so that transmitters can send the appropriate responses as execution bids.

3. the gateway's logic selects a winning bid, based on conditions predefined by the application. This response of the winner's bid is then combined with the user's request to form a CAP which is signed over by the watcher.

4. the switchboard(s) selected by the application is used to provide validation context for the SOCKET contract which is responsible for the CAP's execution. Thus, the switchboard examines and authenticates the contents of a CAP so that execution can occur.

5. execution of the packet is ultimately carried out on the relevant networks in a cyclic manner, until the user request is fully satisfied within optimal bounds.

This implementation enables the aggregation of an application's states (user's profiles and positions, contract holdings etc.) into a single entry point for users to easily interact with.

So how are communicated user requests processed and what does the auction process for transmitters look like? Let's see below.

Modular OFAs and incentivized expansion

Blockchains have been referred to as common knowledge systems due to their transparent nature and the extensive democratization of the data they hold, which enable collective action towards certain outcomes in some cases. This philosophization is in line with the practical case of the overspoken MEV problem that plagues major networks to this day: searchers take advantage of public mempools and topological advantages to frontrun users and engage in auctions for the ability to extract some nonzero value, thus causing the user some value loss.

This feature is commonly curtailed by the implementation of access control mechanisms, which cause the information propagated at any point of an STF to be withheld to a subset of actors who exist in the system to optimize user outcomes for a fee. Thus, these actors have compatible incentives with the user, which makes the system credible. A notable example of such access control mechanisms is OFAs; which are utilized in intent-based systems and beyond to align agents’ incentives with user's expected outcomes by specifying a portion of the user's value to be received by any agent who satisfies their desired outcome.

Intent-based protocols seek to outsource the production of STF variables to actors considered more eligible/knowledgeable than the primary benefactor. They may be considered as generalizations of specialized service aggregation protocols such as 1inch and matcha for swaps, and yield and alchemix for yield.

These aggregators compute optimal routes to achieve user outcomes with minimal user input, though this automation comes with significant computational costs. 

We consider intent-based designs a generalization as they can batch multiple transaction logic behind a single and simply expressed logic (which is often human-readable). This allows them to employ multiple specialized aggregator services under a comprehensive framework to provide a composable interface for users.

All this is to say that OFAs and intents are cool, even if their economics aren't quite figured out yet.

Solver centralization is an obvious issue across every relevant implementation due to exclusive order flow (EOF) and payment for order flow (PFOF), which occurs due to applications selling off their users’ orders to specific participants. The body of the gist is here, but the baseline is that OFAs in their current form are greatly limited for the most part by the censorship-resistance of the blockchain on which they are eventually executed.

This implies that modular order flow auctions (MOFAs), which are designed to be executed across multiple blockchains, will only be as credible as the least censorship-resistant chain on which an operation they process is settled.

However, they do come with the benefit of eased costs, as applications don't have to individually bootstrap entirely new solver sets by themselves. Thus, everyone benefits in this way:

• Applications don't have to take on the cost of bootstrapping solvers for their OFAs, this means we'll likely see less PFOF and EOF since solvers who choose to be extractive will be “leaving money on the table” for other solvers who opt in.

• The lessened rate of PFOF models means users will likely get even better execution on their operations due to the reduced probability of oligopolistic vertical integrations.

• Solvers will be forced to compete on even grounds, thus the best man for each operation will win.

• The underlying blockchains will benefit from this activity as solvers will have to hold some inventory on them to ease execution/operation costs.

Back to SOCKET; the gateway contract is responsible for conducting a MOFA amongst transmitters whenever a user request is received, this request will usually be expressed as an intent. Transmitters then send their bids for execution as responses to the gateway, and based on a condition which is ultimately left to the application, a winning bid emerges and is signed by the watcher for execution.

The agnosticism of CAPs means that transmitters will be better off offering their services across multiple networks, rather than a single one. The support of more networks means they are likely to hold inventory across them, which greatly helps in easing their operational costs for executing requests and helps them compete effectively.

Chain-abstracted accounts

One of the outstanding offerings enabled by SOCKET's design is chain-abstracted accounts, which can be built on any of the emerging chain-agnostic account frameworks (e.g., the proposed RIP-7560, magicspend++ etc.) to present users with a spendable aggregate of their assets across multiple supported networks. 

This unification can be achieved easily through the adoption of existing primitives such as time-locked contracts, which we discuss below.

Time-locked contracts

Timelocks are one of Bitcoin's understated innovations which only existed to satisfy edge cases but are now seeing more generalised use. Bitcoin transactions provide a programmable series of fields which users could use to impose time-based validity conditions on their transactions. Most notable of these fields is nLocktime, which users can employ to define a minimal time before which a transaction must not be added to a block.

Usually timelocks were employed by wallet providers to prevent fee-sniping, but coupled with hashlocks, their use was eventually expanded to payment channels and atomic cross-chain swaps as hash time-locked contracts commonly referred to as HTLCs.

MagicSpend++ is built on the idea of these time-locked contracts, but instead provides them as modular vaults across chains whose deposits can be spent in a pull-based manner by paymasters using cryptographic proofs generated from a user’s satisfied operation.

MagicSpend++

We have previously discussed Ethereum's push for account abstraction via smart accounts as a means to unifying user experience on rollups. However due to the overhead of enshrining smart accounts in the protocol, it is currently being offered via out-of-protocol infra built on the ERC-4337 standard.

MagicSpend++ leverages time-locked contracts to provide users who opt into ERC-4337's offerings via their smart contract wallets with unified, spendable asset balances. The basic idea is that users lock their balances of a supported asset in a configurable vault via their smart contract wallets across supported chains, thus making them spendable only via userOps settled on any number of chains.

Below we will now go over the details of this implementation as a step-by-step process:

1. The user starts an operation as they usually would via an ERC-4337 supportive interface and selects a paymaster service for their operation.

2. The paymaster checks the user's chain-abstracted balance to ensure it is enough to cover their service's expenses and the operation's execution. If the result of this check is satisfactory, they return a special_signature whose use will soon be discussed.

3. The userOp is parsed and the paymasterAndData field is set to the paymaster service which the user selected in the first step, alongside the special_signature which was provided by the paymaster in step 2.

4. The userOp is sent to the bundler and on to the entrypoint contract for authentication as usual.

5. After the usual userOp authentication/validation processes, the paymaster verifies the special_signature they provided and defines a mapping of {address => amount} which provides the source of the operation's funding while establishing an upper boundary on what can be withdrawn by the userOp.

6. Using the provided mapping, the user calls withdrawGasExcess and pulls the specified amount out of the paymaster's specified address, alongside the gas fee for the userOp's execution.

7. After the userOp's execution, the mapping provided by the paymaster is cleared, and a new one is generated by the user alongside a proof of their operation's execution. This mapping and the execution proof is sent to the vaults containing the user's asset balances across chains, allowing the paymaster to be reimbursed and paid for their services.

It is important to note that the only part of the process the user is actively involved in is the definition of their desired operation, the rest of the processes occur in the background between the user's wallet and the necessary infrastructure.

Conclusion

In this article we've been able to establish that the major cause of the fragmentation challenges crypto faces is the variety of engineering choices made by protocol developers in a bid to optimize for specific outcomes. Rather than arguing which outcome and optimizations are best, everyone will be better off transacting in trust-minimized settings across whatever chains they choose to use, without having to worry about the underlying processes.

This approach offers two key benefits:

1. For users: A seamless experience when interacting with applications and tokens across multiple blockchains.

2. For developers: The freedom to experiment with specialized mechanism designs while maintaining interoperability through common data transfer standards.

Hence, decentralized applications deployed across multiple chains are better off agnostic with respect to their users’ settlement layer. They should be able to support as many blockchains as possible in order to get their product's offering in front of more users. Here we use settlement as a placeholder for execution and finality, implying that applications and their users should be able to benefit from the features offered by multiple smart contract chains without having to greatly depend on any one's assumptions and tradeoffs.

SOCKET's design permits this flexibility/agnosticism with its use of standardized tooling to enable applications and users to move away from the chain-centric design that has plagued crypto. Its CAPs can be integrated by multichain applications seeking to unify their user's experience, so that the application can easily settle user orders that transcend a single chain.

SOCKET's CAP design already has a growing ecosystem building atop it, such as Bungee which enables global state/liquidity for dAPPs and Kinto for chainless swaps.

The immediate goal for SOCKET is to serve Ethereum's vibrant rollup ecosystem while the research and development of enshrined alternatives continue, this approach is intuitive since rollup interoperability can be considered a subset of chain abstraction. Its VM-agnosticity does promise future composability with more diverse altVM standards.

SOCKET’s support of chain-abstracted accounts provides users with a centralized exchange-like experience but with reduced trust requirements, allowing them to view and manage their assets across multiple chains in one interface. Through MagicSpend++, amongst other supported frameworks, users can instantly utilize their aggregated balances across chains without extra transactions. Thus, developers are able to compete and build heterogeneous base layers, while users win always since they are presented with a homogeneous interface and shielded from competing standards.

In a follow-up article, we will go in depth to discuss the types of applications we can expect to see on SOCKET soon. Stay tuned!