Crypto's unique value proposition lies in its disintermediation of middlemen and providing a platform (blockchains) atop which users can access applications irrespective of geographical limitations. This is a somewhat simple goal, but as usual, the devil is in the details, the details here being that blockchains come in a wide variety of flavors and have to make tradeoffs in some aspects to serve the applications atop them well.

Unsurprisingly, there are well over 500 chains across multiple layers, whether general-purpose or application-specific, each existing within a black box due to design nuances. This is because improvements can always be made to the underlying technology, and a seemingly endless amount of capital willing to finance such ventures.

However, applications for the most part aren't as unlimited. So far, we have only about ten different classes of applications that can be built atop these chains, with only a few of each reaching and satisfying their target market. While this is not the ultimate goal, it is our industry's current reality.

Thus, we have an excess of siloed chains that mostly provide marginal improvements for fewer applications.

This trend has led to multiple facets of fragmentation and complexity, which affect crypto users and application developers, as they have to be more conscious of what chains they choose to operate on. This has often been cited as one of the primary reasons for crypto's limited adoption and is now being addressed via the chain abstraction framework.

Chain abstraction seeks to offer a solution by creating frameworks that allow different chains to work together at different levels, without diverging from their unique trust models. It unifies interactions across chains, making applications easier to use and more efficient.

This article explores how Okto, a middleware appchain, applies the chain abstraction principle to build a wallet-interoperability layer that targets application developers and enables trustless transaction models across chains.

An overview of the fragmentation problem and Okto's value proposition

The limitations of Ethereum as the first smart contract chain led to a contest of sorts where more bespoke virtual machines and blockchains were (and are still being) designed to enhance existing onchain applications and even support new primitives. While the proliferation of blockspace and virtual machines comes with great benefits, it is now being decried due to the lack of composability across existing networks, which results in complexity across the board for users and limited adoption for applications.

The underlying idea is that application developers and users who build and transact in crypto should not miss out on the numerous benefits of VM-multiplicity due to the lack of a standard, composable framework. Generally speaking, users should be able to benefit from Arbitrum's speed without being limited to ETH as the only currency for network fee payment. Similarly, they shouldn't have to strictly pay gas fees with SOL when transacting on Solana. Developers shouldn't have to sell their applications to the highest bidding ecosystem and lose out on potential users across other networks and on and on.

More generally, crypto applications should serve all crypto participants rather than specific users on specific chains. An extension of this idea is that users should be able to spend their assets in non-custodial wallets without experiencing the friction of bridging. It is a multichain world and products should evolve to this reality rather than continuing to build in silos, and this is the singular goal of Chain Abstraction. And what better way to target users effectively than through the primary interface for transacting onchain: non-custodial wallets.

Okto contributes to the goal of chain abstraction by providing a set of features designed to allow application developers to define the wallet interface through which users can interact with their applications. These features are intended to serve interdependently as middleware between each of Okto's target profiles while coordinated on an agnostic platform— Okto Chain. These solutions include:

1. Decentralized Transaction Networks (DTNs) - Enables asynchronous management of multichain transactions through a network of nodes, thus providing a chain-abstracted experience to users operating across distinct chains. This feature is responsible for coordinating end-to-end transaction settlement across blockchains without the need for the user's “active participation” along every step of the process.
2. Unified Liquidity Layer (ULL) - Employs the cross-chain intent standard (ERC-7683), Okto taps into an established unified liquidity layer for multichain applications to enable users to move their multichain balances easily.
3. Decentralized Wallet Networks (DWNs) - Handles permissions and access policies for end-users. They are designed as delegated MPC signers that grant limited authorizations on a predefined account's asset balance.
4. Gas Station Network (GSN) - the cross-ecosystem gas station network provides a framework for abstracting gas payment away from users on any chain, through either gas sponsorship or gas relay services.

These solutions are managed via the Okto appchain, which keeps a registry of administered roles and sessions alongside user assets and operations. At this point, it is prudent to define the Okto Layer and state what it does and how it works.

Okto is a Layer 2 solution fashioned as a specialized middleware bridging blockchains and decentralized applications (dApps). Its various components, highlighted above, allow it to provide solutions to some of blockchain’s biggest challenges. These solutions include chain abstraction, deepening liquidity, simplifying transactions, and improving overall user experience.

Okto enables seamless interoperability across blockchains by abstracting complexities for users and application developers. Its core innovation is providing a wallet-interoperability layer that unifies transactions across multiple chains without requiring users to interact with each blockchain separately; thus allowing delegated access via secure economic models without violating the unique security models of various chains.

The following sections will review the previously mentioned solutions and examine their architecture.

Operation Abstraction via Okto's Decentralized Transaction Networks

Okto's decentralized transaction network manages the complexities of transacting in crypto's multichain world. The network does this by delegating user-defined orders to specialized nodes enabled via Okto's unified liquidity layer (ULL) to serve as solvers across multiple networks to execute said orders toward specific outcomes.

The decentralized transaction network's nodes are responsible for executing generally-specified operations (aka intents) flexibly across optimal routes to return the most value to users, regardless of the operation's complexity. The user simply provides a “start” point and their desired outcome, while the sub-transactions of the operation are defined and subsequently executed by nodes in the DTN (who can access the user's balance in a trust-minimized manner).

The major functions of the DTN are:

1. Bloc resolution: Every DTN node contains a registry of blocs implemented on Okto, which enables them to create “jobs” alongside instructions to be passed on to involved networks. The standardized nature of these blocs enables DTN nodes to use them to perform their delegated jobs in an agnostic manner compatible with integrated networks.
2. Asset assertion: The executing node compiles the affected asset balances and the affected chains from the order's metadata, and then checks the details against the data stored in the user's account registry.
3. Asset consolidation: Based on the operations defined by a user's expressed outcome, the executing DTN node can create sub-transactions that produce the most optimal routes to the user's outcome. Some of these routes will involve pulling assets from their balances on different chains to one address, from where other operations can ensue.
4. Transaction creation: The executing node is intuitively responsible for crafting transactions according to the constraints of involved networks, especially double-spend prevention schemes (such as nonce systems). The created transactions are then signed and sent to the decentralized wallet network, which independently performs validity checks alongside access policies before appending a signature to the job.

At the end of this process, with explicit approval from a DWN node, the executing DTN node publishes the transactions to relevant networks’ RPCs, with a failsafe retrial model in case of any failures that may cause a sub-transaction's failure on the involved network.

After the entire order is executed, the data indexer, which crawls the blocks of integrated chains, filters events associated with Okto's appchain based on the affected account/user profile and then records the events in their history.

With an understanding of the execution model in decentralized transaction networks, we now address how nodes in the transaction network deal with liquidity rebalancing and the importance of a unified liquidity layer.

The Unified Liquidity Layer

Since interoperability is its ultimate goal, Okto does its best to maintain backward-compatibility with existing standards where possible. One such standard is the cross-chain intent system known as ERC-7683, which (summarily) enables intent markets across various networks to interoperate.

ERC-7683 defines a standard API for cross-chain value transfer systems. These include all sorts of protocols that enable users to move their assets across distinct blockchains, either to obtain a mirror asset (bridges) or to trigger more specific operations. The standard provides generic interfaces for users to submit their orders to a pool of solvers who operate across multiple chains and applications.

Intent-based markets have gained great mindshare over the past year due to their abstraction of the complexities of transacting across two (or more) liquidity pools, applications, and even chains, through agents commonly referred to as solvers or fillers.

However, these markets still face distinct issues due to their lack of support for tail-end assets, applications and chains; these issues manifest mostly as

• Lack of liquidity for new/exotic assets due to limited solver inventory and
• The centralization of the solver duty due to the costs of “solving.”

Both of these worsen user intent outcomes, as the market does not execute the user's intent at the best possible prices.

Since these problems arise because these markets exist distinctly, each having to bootstrap its own solver set and ensure that the set is large enough for healthy competition, the cross-chain intent system (ERC-7683) provides a way for:

1. Solvers on different chains/applications to extend their services to other chains/applications.
2. Users in different intent markets to submit their orders/intents to the solvers on chains/applications that opt into the standard rather than being limited to the solvers on the market.

Okto's unified liquidity layer (ULL) extends these functionalities by default to applications launched atop it. 

Below is an overview of the technical details of the ULL and how this standard can provide its guarantees. A more detailed explanation of the cross-chain intent system is available here.

The primary function of the ULL is to enable seamless movement of users’ assets through the decentralized transaction network. It is managed by the DTN's nodes to allow them to to easily access liquidity reserves for settling users’ orders and portfolio rebalancing as necessary. 

Thus, the decentralized transaction network creates transactions that interact with the unified liquidity layer based on users’ orders. Transactions passed to the ULL in this way are processed by four contracts:

1. OktoSettlementContract
2. The Escrow contract
3. The Entrypoint contract
4. FillerAccount contract

Below is a break down the functions of these contracts.

OktoSettlementContract

The settlement contract's logic facilitates bridging user assets across chains according to the ERC-7683 standard. It is responsible for presenting an interface for order initiation, managing the order fulfillment and settlement processes, and resolving filler-user disputes that may arise due to unforeseen circumstances.

Similar to ERC-7683, an order can be initiated by either the user (OnchainCrossChainOrder) or a filler (GaslessCrossChainOrder), with the gas for execution being paid by the user or filler, respectively. Once an order is opened, fillers on the transaction's destination chain bid on it for fulfillment rights, and the winner of the process executes the transaction. After executing an order, the filler provides proof of execution, allowing the settler on the origin chain to transfer the required assets to the filler alongside their execution fee.

The settlement contract is managed via four distinct roles:

1. The owner - Which is a permissioned role responsible for triggering upgrades to the contract's logic. Such upgrades may include changes to the settlement conditions, the contract's perspective of individual chains, etc. This role is held by a multisig.
2. The admin - Is responsible for performing administrative tasks including adding fillers and settlers and removing them in case of violations. This role is held by Okto's MPC participants.
3. The filler - A permissionless but gated role responsible for executing user orders on the destination chain(s) and presenting proof of execution to the settlement contract.
4. The settler - Responsible for guaranteeing the execution of a user's order by verifying that a filler performed their duty accordingly.

These roles are managed via the Open-Zeppelin access control module to ensure transparency.

Escrow contract

Generally, when a user triggers a cross-chain order, the funds they wish to use are locked on the origin chain (where the assets are located). After a filler fulfills the user's order and the settler verifies its execution, the assets are unlocked and sent to the filler.

The escrow contract is responsible for issuing resource locks on assets moving through the unified liquidity layer, so that user assets remain safe until the execution of their order on a destination chain is confirmed. After a user's order is executed on the origin chain, the filler generates and submits a proof of execution alongside a signature provided by the user, to the escrow contract. The escrow contract then validates this signature and the submitted proof before unlocking the assets for the filler to claim.

If a filler doesn't satisfy the user's restrictions (order execution deadlines, minimum amount of asset returned, etc.), the user can request a refund from the escrow contract and cancel the order. This approach ensures that a deviating filler or settler doesn’t violate the guarantees of self-custody.

Entrypoint contract

The entrypoint contract is responsible for deferring gas payment to the end of an order, so that users don't pay any fees during order creation. It also enables “call nesting” so users can bundle multiple transactions into one and sign only once (for example, in approve-swap transactions).

The contract utilizes the IPermit2 interface to pack multiple calls into payloads that can be executed after a user signs to transfer ERC-20 tokens. This way, when a user signs for an order, their assets are transferred into the Escrow contract and no gas charges are deducted until the order is settled.

FillerAccount contract

The FillerAccount is a minimalistic ERC-4337 account primarily responsible for cross-chain asset transfers. It is set up to:

1. Process users’ orders through the Entrypoint contract.
2. Execute transactions associated with a user's order.
3. Transfer the output assets to a user after their order is completed.

Similar to the original ERC-4337 account standard, the FillerAccount can be managed by multiple signers, such as a multisig set up by the user with various access policies, so it also enjoys the benefits of account abstraction.

The unified liquidity layer also supports Okto's cross-ecosystem Gas Station Network (GSN), which enables users to get the native tokens of the required chains as the output while paying in any token on any of the chains supported in Okto.

Thus, a user can initiate an order with any asset on any supported origin chain (including altVM chains) and specify that their desired output is ETH on mainnet (or any other EVM chain), and the order is settled via the cross-ecosystem GSN. This approach removes the need for users to maintain native tokens across multiple ecosystems.

While Okto currently offers the cross-ecosystem GSN feature, the performant version is centralized and only available on the Okto app and SDK. The plan is to eventually decentralize the system and make it trustless so that other applications and chains can integrate it.

Let us now shift attention to the model's security assumptions.

Security assumptions of the DTN

The obvious questions any multichain execution system faces are its finality guarantees and the underlying network's economic security.

Transaction finality: while the dynamism of transaction finality guarantees across networks is the primary bottleneck multichain operations experience, Okto can provide asynchronous soft finality guarantees for multicall transactions involving contracts in different networks through blocs, without greatly degrading the trust assumptions of involved chains.

(This ability to grant soft finality is enabled by the interaction between [anchor] contracts, which reside on involved networks and their corresponding bloc on Okto, through an exposed bloc API).

Thus, correctness guarantees for state updates between anchor contracts and their blocs are provided by Okto nodes (with variable latency, depending on the target chain) for the most part.

A considerable limitation of this execution model is the lack of support for instantaneous deposits/withdrawals from blocs to their anchor contracts, as these actions require that the constraints of the relevant network on which the anchor contract resides be totally adhered to.

Economic security: since the Okto appchain serves as a data availability layer for the interactions atop it, its economic security is paramount and likely introduces unknown risk vectors. Nevertheless, using it for this purpose comes with the benefit of higher throughput and storage cost reduction, which matter for complex, multichain operations requiring large bandwidths.

Furthermore, nodes in the transaction network are expected to stake the OKTO token as a security feature. Over time, the network will enable slashing as a disincentive against predatory behavior. Okto also implements a reputation-based ranking system in which nodes are assigned a rank in the network based on how many jobs they've completed and how much value they return to users.

Permission abstraction via Okto's decentralized wallet network

Okto's decentralized wallet network is an attempt to revolutionize the capabilities of crypto wallets. Rather than simply serving as interfaces through which users transact on select networks with certain restrictions, integrated wallets can:

1. Unify user assets across chains.
2. Transact on behalf of users through specialized service aggregators (the DTN and ULL) spread across supported networks.

All while ensuring the benefits of self-custody aren't violated.

The decentralized wallet network provides users with a unified interface that shows their asset holdings, the addresses/accounts on which the assets are held, and the account's access policies. The network's standard is “account-agnostic,” designed to support any existing account standard the user may use on any network.

Thus, a user's account may be a vanilla EOA, 4337 contract, Solana, or even magic accounts. However, in the user's account profile on Okto, it'll be represented as a sub-account from which funds can be pulled at the user's behest.

To ensure that users maintain control over their assets and do not have to deal with the intricacies of multichain operations, the DWN delegates session keys to a set of nodes that perform a 3-of-5 MPC scheme to sign multichain transactions that arise due to a user's order. These nodes are permissioned and operate within stringent guidelines defined by the user for each sub-account.

It is important to note that the MPC scheme is a backend process that users will barely notice unless in conditions of severe network latency. The user establishes an authentication scheme of their choice, with alternatives ranging from common biometric schemes and one-time tokens to the more niche private key sign-in.

The end-to-end authentication process is as follows:

1. User authentication: The user obtains a token from their chosen provider (for example, Google OAuth) or provides the necessary biometric confirmation.
2. Gateway interaction: The obtained token/biometric information is passed to the Okto gateway, which then relays the request to an authentication module via a relay wrapper.
3. MPC verification: A rotating MPC network verifies the token and retrieves the corresponding Okto user ID. If a wallet does not exist for the user, it is created; if it exists, the session is registered accordingly in the user's account history.
4. On-chain logging: The session and wallet information are recorded on-chain, ensuring transparency and enabling subsequent transactions to be linked to the authenticated session.

The MPC system currently uses a 3-of-5 node configuration. This means that out of every five participating nodes across which a user's key is distributed, any three must validate and sign a transaction for it to be processed.

The network's ability to be installed via staking/restaking services, such as an Eigenlayer AVS module, allows it to inherit pre-established economic security guarantees and benefit from the AVS’ decentralization.

In Okto, the decentralized wallet network interacts mostly with the decentralized transaction network, providing the latter with the necessary authorization schemes for transactions it executes as part of a user's order. The DWN can provide such authorizations by passing the payloads they receive through a validation process in which each transaction is verified to be following the user's predefined policies.

When this validation process is completed, the MPC phase follows, during which multiple independent nodes contribute to the construction of a signature, which is appended to an associated job/order and then sent back to the executing DTN node. This model enhances the overall architecture's security relative to common wallet providers. 

Bringing it all together, Okto's decentralized wallet network enables users to delegate their accounts’ access policies as session keys to a network of nodes that run a decentralized MPC key generation scheme across supported interfaces. This approach enables the user to define an outcome whose optimal route is computed by the DTN and presented to the DWN for permission to pull user assets from various sources as defined by the DTN. DWN nodes can grant the DTN exclusive execution/access rights by constructing single-use keys, which the latter uses throughout various instances of the defined routes.

Here is a look at Okto's embedded wallet framework, which allows new and existing wallets to be integrated into the Okto ecosystem.

Embedded wallets

While Okto's decentralized wallet network is the underlying technology that enables users to transact over distinct networks, they can access its offerings through a configurable framework called the embedded wallet.

Embedded wallets are configured by wallet providers to present application developers with a framework for integrating their applications into trust-minimized ecosystems made up of other applications.

Embedded wallets can be configured into closed-loop or interoperable wallets.

Closed-loop wallets

This implementation can be likened to the “lite” interface of centralized exchanges, which offer restricted services to an inexperienced user. Application developers on Okto can design their embedded wallets so that users can: 

• Spend specific assets
• Interact with specific dApps

This is all done within a controlled environment, greatly reducing the users’ risk surface. The implementation targets developer demographics who may not wish to allow users access to a wide range of applications for whatever reason.

An example of this implementation is the Coin-DCX ecosystem.

Interoperable wallets

This class of embedded wallets is more attuned to serve experienced users who wish to transact across multiple blockchains with less hassle. Interoperable wallets enable users to spend any assets on any dApps across multiple networks, in a chain-abstracted manner.

Thus, users can maintain control over their assets and actions while benefitting from Okto's decentralized wallet and transaction networks.

An example of this is the Okto Lite wallet.

Security assumptions

The obvious question users may have when delegating their account keys to Okto's wallet network is the extra overhead that may arise and the model's potential failures. With this in mind, we'll briefly outline and evaluate the key generation process and how signing occurs.

Key generation and signing

MPC keys are generated by DWN nodes running within an actively validated service (AVS) cluster. Each node generates and stores a partial key (or a shard) which can be used for each user account whose order is processed through the cluster.

When the DTN sends an order to a DWN cluster, the cluster's nodes each append their partial signatures to the order using the generated keys; these partial signatures are combined to get a full signature that allows the order to be processed completely.

The wallet network is configured to a 3-of-5 threshold, there are five nodes in the cluster (and a corresponding amount of partial keys for each user) and three keys/nodes are required to generate a full signature per order.

The system limits the possibility of Byzantine behavior in nodes by using a permissioned set whose operators are known. However, it is important to note that node software compromises could still lead to safety failures if an attacker gains access to at least three nodes.

Okto L2: the coordination platform

The Okto appchain is designed as a specialized utility layer that streamlines and optimizes the crypto experience for application developers and users by providing a secure orchestration platform for applications and users to interact across unique virtual machines.

The appchain is a Proof of Stake Ethereum L2 built using Polygon's CDK framework. Its validators provide data availability guarantees for the various registries, enabling the orchestration process to function smoothly.

Some of these registries include:

• User accounts registry: Stores the data related to users who transact via Okto. This includes the users’ accounts and assets held on integrated chains, the access policies of each account, and the users' indexed historical data.

This registry enables the orchestration frameworks (DTN and DWN) to efficiently perform their duties by granting privileged access to the information necessary for settling user jobs.

• Bloc registry: Responsible for storing data related to the programmable scripts (i.e. blocs) that enable Okto's asynchronous execution feature.

These blocs can be executable logic by themselves, or serve as API endpoints for application developers to integrate already performant dApps and access Okto's offerings.

• Jobs registry: Tracks user orders and breaks them down into jobs. It also assigns jobs/orders to nodes of the DTN for execution and evaluates the cryptographic proofs of execution that the nodes return to them after completing a job.
• Security registry: Tracks the orchestration agents’ data (i.e., DWN and DTN nodes’ profiles). This data includes their stake in the network, their reputation score based on their executional efficiency and the details of the jobs they've executed.

This registry also manages the staking contract for every node in Okto, from the network's PoS nodes to DWN and DTN nodes. Thus, it is responsible for ensuring that nodes are paid properly for performing their duties.

The L2's architecture allows users to submit their desired outcomes as orders, which are then decomposed into smaller “jobs” that can be independently executed across multiple networks by different agents in a sequential, asynchronous manner. Thus, the ordering of an order's jobs is guaranteed (e.g., job A must be completed for job B to proceed), however; execution speed cannot be guaranteed as atomicity is not guaranteed (i.e., job A may be delayed on the target network and require resubmission by the executing DTN node, thus preventing job B from being processed).

The end-to-end process of an Okto transaction is as follows:

1. The user submits their order and initiates the process.
2. The job registry contract on Okto collects the order, assigns it an order ID based on the hash of its nonce, and processes it into jobs with job IDs.
3. The contract then publishes the jobs to the DTN, where each node places execution bids for the entire order or specific jobs.
4. A different contract evaluates the bids submitted by the DTN and selects the best bid based on cost-effectiveness and the reputation of the executing node in the network.
5. The nodes selected for each job (or for the entire order) prepare and sign the necessary transactions to be executed for the job to be satisfied. They then share the signed payload with the DWN, which verifies that executing DTN nodes undertake their mandates according to the user's requests.
6. Meanwhile, the executing nodes update the DTN throughout the order's execution so that the jobs’ ordering is always adhered to, regardless of the order's complexity. This approach prevents failures.
7. Whenever a job is completed, the executing node submits proof of correct bloc resolution and state inclusion to the job registry. The registry verifies the proof using data obtained from indexers that crawl the network on which the transaction was executed. Once verified, the node receives its payment for the job, while the user's account is updated using the data.

Into the Oktoverse: potentials of the Okto stack

Throughout this article, we've explored the architectures of Okto's various components and hinted at their value proposition in the context of application developers and users. This section looks at how the entire setup affects the current landscape.

Considering the previous discussions, Okto's architecture aggregates wallet services into a single interface, allowing users to spend their assets and perform their favorite onchain activities through this interface, with the help of the decentralized wallet and transaction networks.

This model provides the following benefits:

1. Unification and simplification - The decentralized wallet network enables users to aggregate their accounts across blockchains, regardless of their virtual machines’ specificities. Aided by the decentralized transaction network, this allows users to spend their assets in a chain-abstracted manner without bridging or managing their transactions manually.
2. Onchain identities - The aggregation of user accounts and the indexing of their activities on multiple chains on Okto also enables the establishment of succinct onchain identities, as the necessary data can be easily obtained via a simple API call. Thus, Okto's users can present their accounts, allowing anyone to view a thorough presentation of the assets they hold. This unlocks other use cases in areas such as undercollateralized lending and sybil-resistance, amongst others. They could also process their taxes through their profiles rather than having to sift through multiple wallets, as all the necessary data is accessible via Okto.
3. Enhanced security guarantees - embedded wallets are considerably more secure than common EOA wallets. This is because they are integrated into the decentralized wallet network, which imposes a multi-party computation key on user accounts for outgoing transactions. This MPC key isn't easily obtained relative to an EOA's private key, as its shards are held by a rotating committee of distinct nodes. The MPC scheme is designed to be initiated by the user through various popular authentication policies such as biometric verification, email login, OAuth schemes, etc. Thus, users are selected to access better security guarantees through familiar processes.
4. Interoperability - since this is a broad category, we will address the benefits of interoperability through the perspectives pf users, applications and application developers, and chains.

• Interoperability for users: Users can spend their assets conveniently without dealing with the characteristic vendor lock-in of the current onchain landscape. This means a user can spend their USDC balance across multiple blockchains without manually bridging and aggregating it to a single account. Also, they can initiate transactions from a different chain to be settled on another without ever leaving one interface or signing more than once.
• Interoperability for applications: Applications do not have to be siloed. They should be accessible to a larger market than the one on the chains they are built atop. This is possible on Okto through wallet providers that can create an interoperable ecosystem. Each ecosystem comprises clients (application developers) who opt into the provider's specified policies for certain incentives.
• Interoperability for chains: Okto L2 is designed to serve as middleware for blockchains, whether general-purpose or application-specific. It indexes state transitions during order execution on integrated chains and contextually provides this information to other chains to trigger specific actions/outcomes.

Conclusion

As the space continues to grow, the complexity of interacting with multiple isolated chains will continue to be a significant barrier to adoption for applications. Chain abstraction is one of the recent narratives with promising developments from thriving teams; its benefits will allow crypto's expansion beyond the current phase, allowing developers to tuck the underlying complexity securely beneath the hood.

Okto's architecture offers a powerful solution to this fragmentation, providing a seamless platform for users and developers to interact across various chains without the typical friction.

By leveraging its appchain orchestration layer, Okto ensures a unified experience where different blockchains and applications can coexist and collaborate while still respecting their individual trust models. This approach enhances user experience while enabling developers to create applications that can reach a wider audience without the limitations of any single blockchain. Their use of a specialized L2 appchain for orchestration means that the network can provide data availability guarantees to its users while also inheriting the economic security of Ethereum.

Additionally, integrating established multichain standards, such as the cross-chain intent standard (ERC-7683) and Agglayer, solidifies Okto’s proposition as an interoperability layer, as its platform remains flexible and open to future developments. The combination of Okto’s decentralized wallet network, unified liquidity layer, and transaction networks allows users to interact with crypto more intuitively, securely, and cost-effectively.

With their recent testnet launch, we can already experiment with the model and see how it provides the best outcomes for both applications and users while expanding the capabilities of existing blockchains.

Acknowledgements: Special thanks to Daniel Ayuko for review and feedback. 

Disclaimer: This report on Okto Layer was funded by Okto. Funding covers research and production costs but does not influence our analysis or conclusions. 2077 Research maintains complete editorial independence, and our findings are based on our investigation and judgment. This report is for informational purposes only and should not be considered investment, financial, legal, or tax advice. Readers should conduct their research and exercise independent judgment before making any decisions.