SEDA Network Architecture

SEDA Layer One

SEDA secures Oracle Programs and Data Proxies using heavily battle and time-tested algorithms. The SEDA Chain bases its security on Proof-of-Stake (PoS), using the Cosmos SDK as a foundation. Users may delegate their stake to validators participating in consensus to secure the network. Any entity can run a validator node on SEDA, where up to 100 validators are selected for participation based on their staked weight, as delegated from the community.

Oracle Programs

SEDA’s Programmable Oracle Infrastructure is designed to mitigate the inherent restrictions faced when building modern apps with traditional oracle models. SEDA’s design navigates away from default data sets and rigid architecture stacks by leveraging an intent-centric framework.

SEDA introduces the concept of Oracle Programs, containers that consist of protocol-defined instructions that dictate how their data requests should be executed. Essentially, an Oracle Program enables developers to program their own oracle feeds, which are then deployed to the SEDA Network. The network takes ownership of accessing and transporting the data to the protocol.

Where traditional oracle models must build specific data feeds for each type of data being consumed, such as price feeds, SEDA’s Oracle Programs allow the builder to customize a feed for any data type. When creating an Oracle Program, there are three broad parameters for which developers can define their oracle feed instructions:

1. What data they want to access.

SEDA's infrastructure can query any public API end point on the internet, as well as a suite of private data providers, for all data types.

1. Which data sources they want to include in their query.

By incorporating a http-fetch function, developers can build oracle feeds to query data on any public API endpoint that makes that data available for consumption by their smart contracts.

For private providers, builders can select which providers they want access to and highlight providers they do not wish to include in their queries.

1. How data should be filtered, aggregated and returned for consumption.

SEDA incorporates a DR Tally function that can order and structure data results according to the protocol-defined instructions coded into an Oracle Program.

Protocols can define their data filtration and aggregation parameters to ensure that the returned data is presented in the most compatible structure for their app or network.

Once an Oracle Program is deployed to the SEDA Network, it is stored as a WASM Binary and assigned an Oracle Program ID. The Oracle Program ID matches the ID attached to the protocol and is fetched by the SEDA Network when a protocol's ID, associated with their data requests, is relayed to the SEDA Main Chain.

In a Web3 landscape where app builders are migrating on-chain, SEDA’s custom Oracle Programs ensure that a lack of access to data never restricts developers. The Oracle Program SDKs are open-source and available on the SEDA Github to make any Oracle Feed type available to builders from day-one.

Data Proxies

A Data proxy is a simple middleware component that acts as a pipeline or connector between a data provider and the SEDA network by holding an API key that has access to the data provider’s services. Additionally, Data Proxies verify conditions to inbound HTTP requests, checking that the requester is part of the SEDA network and that the provider’s fees have been paid. Additionally, they allow providers to add an SECP private key to the proxy, which would be used to sign the data before it’s forwarded back to the requester, adding additional security and verifiability.

In the end, the proxy nodes allow data providers to expose their entire suite of APIs through a single, one-time deployment and earn value based on onchain demand with minimal technical overhead or maintenance.

Request Flow

How data is requested via the SEDA Network.

Response Flow

How data is served from the Data Proxy to the SEDA Network.

_{⚠ Important: Data providers that deploy or operate a data proxy connected to the SEDA Network do so independently and at their sole risk. SEDA provides its infrastructure and services strictly “AS IS”, “AS AVAILABLE”, and “WITH ALL FAULTS”, without any warranties of any kind, whether express or implied. SEDA expressly disclaims all liability, including but not limited to, any reliance on the content, information, or materials available on its sites, documentation, or services, any loss, error, outage, security incident, inaccuracy, or unavailability arising from or related to its infrastructure, services, or data. Data providers are solely responsible for their own infrastructure, data accuracy and legality, security, regulatory compliance, and for any claims, damages, or liabilities (including those bought by users or third parties) arising from or related to their proxies or data. Nothing herein constitutes legal, financial, investment, or other professional advice, nor does it any form of contract, solicitation, recommendation, commitment, or offer to buy or sell. Access to and use of any part of SEDA is subject to the most current SEDA Terms of Service.}