Chain Abstraction At A Glance

Chain Abstraction is “A user experience exempt from the manual processes required to interact with multiple chains” (By @ParticleNtwrk). This means that a Chain Abstracted Web3 will allow onchain users to interact with applications without the complexities of managing blockchain transactions.

Like traditional apps where users aren’t required to interact with complex software, Chain Abstraction removes user obligation to interact with blockchains, allowing intuitive and familiar app experiences.

‍

‍

The Chain Abstraction technical stack is made up of three distinct layers.

‍

1. Transaction Creation Layer: Applications and accounts, where users create a transaction
2. Transaction Management Layer: Software that manages the rules and flows as to how a transaction is executed
3. Transaction Settlement Layer: Where SEDA exists to verify and prove if a transaction was successful to finalise transactions on all networks.

‍

‍

SEDA is the foundation of the Chain Abstraction stack verifying transaction outcomes across any blockchain.

In true Chain Abstraction, users only interact with the first layer. This allows them to use any application through a single account and engage seamlessly with apps across different chains — as if they were part of one unified ecosystem. SEDA is vital in enabling one decentralized standard for data transport between any network that allows users to interact with Web3 as if it were one unified ecosystem.

‍

Learn more about the Chain Abstraction Stack here:

https://x.com/sedaprotocol/status/1864703696279330869

‍

Oracle Programs For Chain Abstraction

‍

Recap on Oracle Programs: https://x.com/sedaprotocol/status/1864288192502923697

SEDA Oracle Programs allow apps and networks to deploy custom data feeds that query the transaction states on numerous blockchains. This allows the app to provide user experiences across multiple chains, from one place. Interchain communication is essential to chain abstraction as users create transactions on one chain but have the transaction executed on another (Normally by a solver).

‍

As chains cannot access data outside of their native environment to validate a user transaction, SEDA is used to  verify the outcome of a transaction on the destination chain and reports the outcome back to the origin chain (See Image)

Imagine an application built on Chain A that can execute transactions on Chains B,C, and D. To ensure Chain A can verify the transactions on the other three chains, an oracle must be able to read all three chains’ states and return states to Chain A.

Traditional oracles require multi-month deployments to new networks that take around six months. With SEDA, Chain A doesn’t have to wait for a combination of outdated Oracle models to connect to other chains; instead, it can deploy an Oracle Program in seconds that defines the chain’s data it wants to access.

‍

Oracle Program Example

In the above scenario, Chain A creates an Oracle Program using the SEDA SDK that says

‍

1. I want to query data on Chains B,C, and D
2. I want to query this data using providers X,Y, and Z (SEDA public or private data suppliers)
3. I want data returned as true or false for certain transactions

‍

Chain A then deploys the program and can instantly access the data of the above chains to verify if user transactions were successfully executed. Using Oracle Programs, networks maintain control over the services they want to provide by curating their oracle feeds tailored to the use case they provide.

‍

SEDA | Design For Chain Abstraction

SEDA Prover contracts are monitored by Solvers for new data requests. Solvers then relay the requests and results between SEDA and the blockchain where the request was made.

‍

In addition to Oracle Programs, SEDA’s Prover Contract and Solver Network power horizontal day-one scalability to any new network, which is necessary for ongoing chain abstraction. In the current onchain landscape, new networks can be deployed in seconds. To continue to provide a comprehensive chain abstracted experience, new networks must be able to interact with existing networks to connect their apps, users, and liquidity to the wider Web3 world.

SEDA’s programmable infrastructure design enables new and existing networks to deploy a single contract (a prover contract) to any new chain in minutes. Solvers (transaction assistant bots) monitor the prover contract for data requests and relay them to the SEDA chain. In contrast to traditional models that require a new network to prove user traction before deploying their entire stack, SEDA contracts allow day-one access to any other blockchain.

With existing models, new chains are forced into isolation from other networks, resulting in fragmented user experiences. With SEDA, any network can provide a chain abstracted experience from day one. SEDA is built to capture every transaction generated from universal accounts and verify their outcome.

‍