LogoLogo
  • Overview
    • SEDA Overview
      • SEDA Primer for Key Features
        • SEDA’s Intent-Centric Framework
        • Modular Design Benefits
        • Programmable Tooling and Permissionless Development
        • Fast Settlement & Horizontally Scalable
        • Fork-less Upgrades
      • RWAs, Price Feeds, AI and More
        • Custom Data Feeds
      • SEDA Token Primer
        • Network Utilization
        • Network Participation & Chain Security
        • Network Governance
      • Introducing SEDA's Flagship Product - The IVM
        • 🌉Intro to Interop 3.0 & Emerging Verification Markets
        • Programmable Modules
        • Triggering A Verification Data Request With An IVM
        • SEDA IVM Security
        • An IVM Summary
    • SEDA Network Architecture
      • Walking Through SEDA’s Architectural Features
      • The PoS SEDA Chain
      • Oracle Programs
      • The Overlay Network
      • Decentralized Solver Network
      • SEDA’s Prover Contract
  • For Developers
    • 📈Data Requests
      • ❓What is a Data Request?
      • 🔃Data Request Life Cycle
    • 💾Building an Oracle Program
      • Price Feed Example
        • 👋Getting Started: Price Feed
        • 🧪Testing Your Oracle Program
        • 🚀Deploying Your Oracle Program
      • 🌐Fetching Open Data
      • 🔐Advanced: API-key Gated Data
    • ⚡Access Data from Any Network
      • 🔎Access from EVM Networks
        • 🔧Using SEDA in a Contract
        • 🚀Contract Deployment
      • 🔜Access from other Networks
      • 🔜Advanced: Run your own Solver
    • 🏗️Deployments
    • 👽Interoperability Verification Module (IVM)
      • 🛸Interop Verification Module for Message-Based Bridge Protocols
      • Powering Intents and Chain Abstraction with SEDA
  • For Users
    • ⭐Getting Started
      • 🏦Wallet Overview
      • ⏬Installing Cosmos Hub on Ledger
      • ⛓️Adding SEDA Chain to Keplr
      • 🌌Delegating your SEDA
        • 📨Selecting a Validator
        • 📡Delegating to a Validator
    • 👐Tools and Dashboards
      • 🌐SEDA Explorers and Dashboards
      • 🔭Third-party Explorers
      • 📶Public RPCs + APIs
    • 🔵SEDA Token Info
      • 📈Token Charts and Tracking
      • 📊Exchanges
      • 〰️SEDA Distribution Schedule
  • For Data Providers
    • Data Proxy
      • ℹ️Introduction to Data Proxy
      • 💻System Requirements
      • 🔢Operating and Running a Data Proxy
      • 🔐Advanced: API-key Gated Data
  • For Node Operators
    • 📶SEDA Chain Guide and Requirements
      • 🎬Installation and System Requirements
      • 👟Operating and Running a Node
      • 🔗Linking to an External Node
      • 🏗️Validator Onboarding
      • 🔑SEDA Keys
      • 📸Joining Testnet Using Snapshot
      • 🤝Joining Testnet Using State Sync
  • Resources
    • 🛡️Audits
      • Trail of Bits Audit Report Repo Link - March 2024
      • Sherlock Audit of SEDA Network Full Feature Launch - April 2025
  • Legal
    • Privacy Policy
    • Terms
Powered by GitBook
On this page
  1. Overview
  2. SEDA Overview
  3. SEDA Primer for Key Features

Modular Design Benefits

PreviousSEDA’s Intent-Centric FrameworkNextProgrammable Tooling and Permissionless Development

Last updated 2 months ago

SEDA’s design allows it to fetch and deliver data from any source to any destination blockchain network. To achieve this, SEDA consists of four modular components: data settlement, compute, relay, and data provision.

This section highlights each component and describes how they interact to power fast, secure, and accessible data transmission to and from any blockchain.

The SEDA chain is a dedicated data transmission blockchain built using the Cosmos SDK as a foundation. It functions as a verification and checkpointing layer. The main responsibilities of the SEDA chain are security, consensus and proof generation, which power SEDA’s interoperability with any other blockchain. The SEDA chain is the single point of truth for all other network components.

Any network can issue a data intent, read or verify SEDA’s data, known as data consumption. Networks deploy a prover contract that acts as the point of communication between data requestors and the SEDA Network. Destination networks issue their data requests as data intents that pass through the Prover Contract and are relayed to the SEDA Network via a

Solver.

In the example above, we go over the most basic flow possible: a data requestor fetches some data and then uses it. In practice, there will likely be middleware services that will make it easier to consume data for popular feeds. That way, the feed cost can be split amongst multiple participants, and the frequency of updates can be higher.

Page cover image