Technical Blogs
SEDA Prover contracts allow any network to post data requests (DRs) and verify data results with day-one integrations.
SEDA Prover contracts address a fundamental limitation in traditional oracle architectures: horizontal scalability across blockchain networks. Legacy oracle systems, designed during the early blockchain era, required complete infrastructure redeployment for each new chain integration. This architectural constraint resulted in significant integration delays—often spanning months—as the blockchain ecosystem expanded to hundreds of networks built on diverse codebases.
SEDA's intent-centric architecture, enabled in part through its Prover contracts, eliminates these integration bottlenecks. Prover contracts serve as a standardized communication and data verification contract between any blockchain network and the SEDA chain. This modular design allows developers to deploy a Prover contract on their chosen network and immediately begin querying data sources, reducing integration time from months to seconds.
This article will explore the SEDA Prover Contracts role in the SEDA Network.
Article Overview
The SEDA Prover Contracts can be deployed on a permissionless basis and serve as the point of communication between SEDA’s main chain and requesting networks. Deployed Prover contracts are monitored by a Decentralized Solver Network. Once a request is posted, a Solver relays the DR to SEDA for execution, and returns data results upon completion. By deploying the SEDA Prover contracts, networks gain access to SEDA to query any data on the SEDA chain or issue new data requests.
Additionally, any network that integrates SEDA can interoperate with other SEDA-connected networks, as long as RPC endpoints are available to query state on the desired chains. Instead of requiring full infrastructure redeployments for each new integration, a single Prover contract deployment allows networks to connect with SEDA in just a few hours. This horizontal scalability ensures that blockchains can seamlessly access essential data on demand, eliminating the delays and permissioned integrations common in legacy models.
The Prover contract has two primary roles. The first is facilitating the communication between SEDA and any blockchain. Once the contracts have been deployed, a network can create a new oracle program or access existing modules by issuing a DR. Data requests are issued as a “data-intent”, where the requestor’s data intent instructions are stored in Oracle Programs and called during a request. Each DR is assigned a unique DR ID, which is matched with the corresponding Oracle Program ID required to handle the request on SEDA. When the DR arrives at the Prover contract it is relayed by the Solver to the SEDA Network for execution.
Once the DR has been processed and returned to the SEDA main chain, it is secured by tamper-resistant proofs signed by main chain validators. Results are then made accessible to the Solver that relays the DR result back to the Prover on the origin chain. Once returned, the data is available by the requestor and the DR life-cycle ends. This intent-centric design approach where Solvers monitor a single Prover contract for communication mitigates months-long redeployments allowing any network to communicate DRs with SEDA within hours.
The second role is to read tamper-resistant proofs generated by the SEDA chain to verify that data results originated from SEDA. When a data result has been filtered and aggregated by the DR Tally, it is sent to the SEDA main chain and batched with other data results. Data batches are secured with tamper-resistant cryptographic proofs, signed by main chain validators. These proofs ensure that Solvers relaying results cannot alter the data while it is in transit between SEDA and the destination chain.
The proof mechanism is based on Merkle trees and signature verification. Solvers relay batch proofs, which allow the cryptographic verification of data result inclusion. These batch proofs are signed by active validators, ensuring that results remain tamper-proof. By leveraging this approach, the security guarantees of the SEDA chain and its PoS model extend to the data verification process. Once a Solver relays the verified result back to the origin chain, the Prover contract reads the proof to confirm data integrity before making it available to the requestor. The SEDA Network remains data-agnostic—Prover contracts verify that data originates from SEDA but do not assess its correctness.