Data intents on SEDA allow developers to access customized data from any network on demand.
Data requests on SEDA are expressed as intents relayed between SEDA and the consumer chain via a network of solvers. Data intents enable protocols to issue complex requests executed according to the protocol’s predefined instructions stored in an oracle program.
Intent frameworks for oracles support horizontal scalability by reducing the infrastructure required to deploy on new networks. Traditional models can also benefit from SEDA’s infrastructure, which acts as an ‘expansion pack’ for additional interoperability with added programmability.
Article Overview
- What Are Data Intents?
- Comparing Intent-Based Oracles And Traditional Oracle Designs.
- How Are Data Intents Processed?
What Are Data Intents On SEDA?
Intents combined with oracle programs allow protocols to simply state what data they want, where they want it from and how it should be processed.
A data intent is the desired outcome a protocol specifies when requesting specific data. Data intents differ from traditional data requests in that protocols on SEDA can deploy oracle programs (a set of instructions) that define how their intent is executed. Traditional models operate more like a preset menu showcasing the available data for selection. An oracle program can add parameters such as where data should or should not be queried, how it should be filtered, and finally, how it should be aggregated for consumption. Then, a protocol can issue their intent, stating this is the data we want, and here are the instructions.
Comparing Intent-Based And Traditional Oracle Designs
Imagine a traditional oracle like a juice cafe where the consumer can select between apple, orange, or pineapple juice — where the juice represents available data. You cannot deviate from the options available. On the other hand, SEDA is much more like a smoothie bar where you tell the operator what fruits (data) you want and how you want them. SEDA then takes your order and instructions (the intent) and completes the operation on your behalf. The outcome is a user-managed approach with increased flexibility, scalability, and specialization.
Typical oracles excel at providing specific data sets for particular use cases to certain networks, such as liquid staking feeds or specific price feeds. These models continue to work well for established DeFi projects on major networks. On the other hand, SEDA offers programmability, enabling instant deployment of app-specific data feeds in a permissionless and agnostic environment.
As Web3 enters an age of hyper-specialization, the niche data sets required by protocols are forever increasing. New use cases, abstraction frameworks, and industry-wide interoperability demand instant access to various data types. Instead of building specific oracle feeds for each use case, SEDA’s intent frameworks empower developers to issue custom data requests from any network. Simply put, protocols tell SEDA how, from where, and what data they need, and SEDA processes the request.
How Are Data Intents Processed?
SEDA’s modular architecture with intent-centric designs support horizontal scalability.
SEDA uses a single prover contract that is deployable to any network as the initial point of communication. Any protocol on any network can issue their intent processed by the following flow:
- Protocol initiates the request as an intent sent to the prover contract.
- The prover contract is monitored by solvers that relay the intent to SEDA.
- SEDA then processes the data request leveraging its overlay network and DR Wasm tally.
- The results are filtered and then aggregated according to instructions defined by the consumer’s oracle program.
- After aggregation, SEDA makes the single data point available to the solver.
- The solver returns the data result via the prover contract to the protocol for consumption.
Utilizing solvers to monitor inbound intents mitigates the need for SEDA to deploy entire tech stacks to new chains. SEDA can achieve near-instant communication between any current or new network by deploying a prover contract monitored by solvers. Once the intent is relayed to the network, it can be processed and returned to any destination chain. With SEDA’s current design, an estimated 31,150 pathways are currently supported between 250+ blockchain networks.
