Index

General Information
Part A: Information about the offeror or the person seeking admission to trading
Part B: Information about the issuer, if different from the offeror or person seeking admission to trading
Part C: Information about the operator of the trading platform in cases where it draws up the crypto-asset white paper and information about other persons drawing the crypto-asset white paper pursuant to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114
Part D: Information about the crypto-asset project
Part E: Information about the offer to the public of crypto-assets or their admission to trading
Part F: Information about the crypto-assets
Part G: Information on the rights and obligations attached to the crypto-assets
Part H: Information on the underlying technology
Part I: Information on the risks
Part J: Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts

2026-06-05

This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union.
The person seeking admission to trading of the crypto-asset is solely responsible for the content of this crypto-asset white paper.

This crypto-asset white paper complies with Title II of Regulation (EU) 2023/1114 of the European Parliament and of the Council and, to the best of the knowledge of the management body, the information presented in the crypto-asset white paper is fair, clear and not misleading and the crypto-asset white paper makes no omission likely to affect its import.

The crypto-asset referred to in this crypto-asset white paper may lose its value in part or in full, may not always be transferable and may not be liquid.

The utility token referred to in this white paper may not be exchangeable against the good or service promised in this white paper, especially in the case of a failure or discontinuation of the crypto-asset project.

The crypto-asset referred to in this white paper is not covered by the investor compensation schemes under Directive 97/9/EC of the European Parliament and of the Council or the deposit guarantee schemes under Directive 2014/49/EU of the European Parliament and of the Council.

Warning
This summary should be read as an introduction to the crypto-asset white paper. The prospective holder should base any decision to purchase this crypto-asset on the content of the crypto-asset white paper as a whole and not on the summary alone. The offer to the public of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments and any such offer or solicitation can be made only by means of a prospectus or other documents pursuant to the applicable national law.
This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council or any other offer document pursuant to Union or national law.

The SEDA token is designed as a utility token that powers and enables operations within the SEDA decentralized oracle network. The SEDA token’s key functions are: (1) enabling network utilization, (2) supporting network security, (3) enabling network participation; and (4) governance.

(1) Network Security. The SEDA Chain uses a Proof-of-Stake (PoS) consensus mechanism. Validators that participate in block production and batch signing are required to stake SEDA tokens in order to operate a validator node. Validators that follow protocol rules receive a portion of the SEDA Chain’s native inflation issuance to incentivize compliant performance. Validators that violate protocol rules may be subject to slashing, which results in the reduction or loss of a portion of their staked tokens. The function of token burns associated with network usage is to enhance SEDA network security by reducing SEDA token supply.

(2) Network Utilization. SEDA tokens are used to enable core network operations by covering native network fees associated with computation, data delivery, and deployment of oracle programmes and data proxies to the SEDA Network. In certain execution paths, tokens are permanently removed from supply as part of protocol-defined processes associated with the usage of the SEDA Network.

(3) Network Participation. Operation of core network infrastructure requires staking SEDA tokens: main chain validators must stake SEDA token to participate in consensus; and overlay node operators are required to stake SEDA token to operate nodes used for querying data proxies. SEDA token holders may delegate tokens to main chain validators through the native Keplr dashboard to support network consensus. Through delegation, SEDA token holders may help to secure the network by delegating their tokens to validators in the active set.

(4) Governance. Validators and delegates may participate in onchain governance by voting on protocol proposals. Governance proposals are conducted through the Keplr governance forums.

SEDA token is a utility token that enables access to the SEDA decentralized oracle network. Token holders may use SEDA tokens to submit data requests to the SEDA network, incentivize solvers and overlay nodes of the network, stake tokens to secure the network through proof-of-stake mechanisms, and participate in on-chain governance related to protocol parameters and technical upgrades. The oracle programme complexity determines the amount of SEDA token required to perform the computation for the data request. Accordingly, the number of SEDA tokens determines the frequency of oracle programs performance. Service security and quality (e.g. latency, up-time) is maintained through the network’s decentralized proof-of-stake mechanisms. SEDA tokens are freely transferable on the SEDA Network. SEDA token has also been made available for transfer on external blockchain networks by bridge providers except where restricted by applicable law or regulations, smart contract or protocol limitations, or governance-approved technical updates that may temporarily limit transfers for network security or maintenance reasons. SEDA tokens do not confer ownership, profit rights, or any claims against any legal entity and may be used solely for utility within the SEDA network.

SEDA token operates as a decentralized utility token that enables access within the SEDA oracle network. Open Oracle Association, an association incorporated under Swiss law, supports the ongoing development and maintenance of the SEDA ecosystem and token.

This whitepaper is prepared in compliance with MiCA regulations to ensure transparency in relation to the potential admission of SEDA token on trading platforms within the European Union. This document does not constitute a new issuance, public offering, or solicitation to purchase SEDA token, but rather provides key information concerning the token’s characteristics and its intended admission to trading within the EU, including on platforms such as Foris DAX MT Limited (“Crypto.com”), Payward Global Solutions Limited (“Kraken”), and other MiCA-compliant venues.

Open Oracle Association

H781

Dammstrasse, 16, 6300 Zug

CH-ZG

Dammstrasse, 16, 6300 Zug

CH-ZG

2023-02-01

CHE-195.612.455

+41796137799

legal@seda.xyz

Not applicable

Open Oracle Association is a not-for-profit organization with the purpose of supporting of the development, coordination, and maintenance of the decentralized, data-driven SEDA oracle network, and the associated tools and technologies, designed to bring off-chain data onto blockchain networks (on-chain) in a secure and efficient manner. For this purpose, Open Oracle Association engages in the following key activities: Research and development of the protocol and related tools and technologies; ecosystem growth through community engagement, education, and technical enablement; entering into partnerships and collaborations to drive adoption and integration of SEDA across networks; as well as legal and administrative support.

Its principal market is the global blockchain and decentralized-data infrastructure sector, with a focus on facilitating data reliability and accessibility across multiple blockchain environments.

Not applicable

FALSE

Since its establishment, Open Oracle Association’s financial position and operational performance have developed in line with its mission to advance decentralized oracle infrastructure. Primary source of funding include multiple contributions and treasury allocations in support of the project’s development and community activities.

Key performance Indicators (financial and non-financial) reflecting Open Oracle Association’s operational development include:

• Team size: 19
• Number of active integrations or partner projects: ca. 30
• Protocol uptime / reliability metrics: >99.99%
• R&D expenditure as a percentage of total spending: ca. 90%

During the reporting period, cash inflows were primarily derived from contributions, while outflows related mainly to personnel costs, technical development, administrative and legal expenses. Open Oracle Association maintains adequate short-term liquidity to meet operational requirements, and the capital resources are managed conservatively to ensure the sustainability and continuity of core activities.

Not applicable

FALSE

SEDA

SEDA

SEDA

SEDA is a decentralized oracle network designed to securely and efficiently transmit off-chain and on-chain data to or between blockchain networks across multiple environments. It operates as a layer one protocol for programmable oracle infrastructure, enabling developers and decentralized applications to access any data in a trust-minimized and interoperable manner. The SEDA project consists of the SEDA Chain, the Overlay Network, the Solver Network and Oracle Programmes. The SEDA Chain is used to coordinate and settle data requests. The Overlay Network is used to retrieve data from public or private sources. The Solver Network is used to transmit data requests and results between external blockchain networks and SEDA. Oracle Programmes allow developers to define the data sources, computation logic and output format for specific data requests. SEDA is intended to support the provision of external data to decentralized applications and blockchain networks across different execution environments.

The SEDA token is the native utility token of the SEDA ecosystem and is integral to the functioning of the network. It is used for accessing and participating in the data request lifecycle, securing the network through proof-of-stake mechanisms, and supporting decentralized governance on protocol parameters and network upgrades.

The SEDA token does not confer, represent, or otherwise encapsulate, any ownership rights, shareholder rights, off-chain governance participation, profit participation, dividends, or any claims against any natural or legal person, whether or not associated with SEDA or involved in the issuance or maintenance of the SEDA network.

The SEDA token is neither designed nor suitable for use as a means of payment, of storage or transfer of value, or for any other form of investment or speculation purposes.

TRUE

The SEDA project develops a decentralized oracle infrastructure that enables secure and efficient transmission of off-chain and on-chain data across multiple blockchain environments. Using the SEDA utility token, users can request and access verified data through the network’s programmable oracle layer; stake tokens to secure the network and validate data integrity via proof-of-stake; participate in on-chain governance, voting on protocol parameters and upgrades; deploy oracle programmes to define computation and data sources where data should be pulled from; and register data proxies to expose private API data onchain with payment or allowlist based gating. The services are designed to provide reliable data connectivity, interoperability, and transparent governance for developers and decentralized applications. The SEDA token serves solely as a utility tool within this ecosystem and confers no ownership, profit rights or any claims of any kind.

Past milestones

The SEDA roadmap identified the completion of devnet versions v0.2 and v0.2.1 as past milestones. These versions included the first Oracle Programmes, an Overlay Node, a Data Request tally function and an EVM Solver for communicating Data Requests from EVM-deployed Prover Contracts to SEDA.

The remaining development steps included the completion of version v0.3, the development and deployment of version v0.4, the release of the remaining devnet versions, a full upgrade to testnet and the subsequent launch of mainnet v1.0. These steps included the introduction of Proxy Nodes, initial Prover Contract deployments on selected EVM networks, and infrastructure frameworks designed to support progressive decentralization, including community-operated Overlay Nodes and decentralized Solver Networks capable of operating with SEDA from layer-one and layer-two networks as Prover Contracts become available in additional programming languages.

Future milestones

Future milestones include the development of SEDA into a widely adopted standard for programmable oracle infrastructure, enabling builders to access data from public and private sources through a unified platform across multiple blockchain networks.

All tokens from previous financing rounds are fully vested and circulating. At genesis, the SEDA token allocation was distributed as follows: 43.5% was allocated to the SEDA DAO Treasury, 25.8% formed part of the circulating supply, 18.1% was allocated to contributors, advisors and early backers, and 12.6% was allocated to the team.

Resource allocation primarily focuses on: (1) Research and development, including improving the SEDA network (mainly stability and latency), technological enhancements, security audits; and (2) Operational activities, including ecosystem growth, promotional initiatives aimed at increasing adoption or interoperability. These activities are designed to ensure the long-term resilience, growth, and technical advancement of the SEDA ecosystem.

While SEDA utility token is classified as “Other Crypto-Assets” under MiCA, the objective of seeking admission to trading is to enable the listing of the SEDA token on MiCA-regulated trading venues, thereby ensuring that the token can be accessed, exchanged, and utilized within the European Union. Admission to trading will support the long-term sustainability of the SEDA ecosystem, facilitating broader accessibility, liquidity, and stability, and strengthening network participation and brand visibility across the European Union.

Foris DAX MT Limited (“Crypto.com”; LEI: 2549005CVR5HH70FDO07), Payward Global Solutions Limited (“Kraken”; LEI: 9845003D98SCC2851458), and others.

Kraken: PGSL

Access will be granted under the terms and conditions provided by each trading platform individually.

The costs associated with access to trading platforms are determined by each trading platform individually.

Not applicable

Not applicable

Switzerland

Subject to mandatory applicable law, any dispute arising out of or in connection with this white paper and all claims in connection with the SEDA token shall be exclusively, including the validity, invalidity, breach or termination thereof, subject to the jurisdiction of the courts of Zug, Switzerland, with jurisdiction in accordance with Swiss law and applicable EU regulations.

Crypto-assets other than asset-referenced tokens or e-money tokens

The SEDA token functions as a utility token within the SEDA decentralized oracle network, serving a critical role in enabling secure and reliable communication between off-chain and on-chain data across multiple blockchain environments. SEDA token is used to initiate and process data requests, incentivize network participants, and participate in the network’s proof-of-stake mechanisms, which enhances overall security, integrity, and trust. Through PoS participation, token holders may stake tokens to validate transactions, ensure accuracy and support consensus formation. The token’s purpose is purely functional, designed to facilitate operations within the SEDA ecosystem. The SEDA token does not confer, represent, or otherwise encapsulate, any ownership rights, shareholder rights, off-chain governance participation, profit participation, dividends, or any claims against any natural or legal person, whether or not associated with SEDA or involved in the issuance or maintenance of the SEDA network. The SEDA token is neither designed nor suitable for use as a means of payment, of storage or transfer of value, or for any other form of investment or speculation purposes.

Not applicable

The SEDA token is designed as a utility token that powers and enables operations within the SEDA decentralized oracle network. The SEDA token’s key functions are: (1) enabling network utilization, (2) supporting network security, (3) enabling network participation; and (4) governance.

(1) Network Security. The SEDA Chain uses a Proof-of-Stake (PoS) consensus mechanism. Validators that participate in block production and batch signing are required to stake SEDA tokens in order to operate a validator node. Validators that follow protocol rules receive a portion of the SEDA Chain’s native inflation issuance to incentivize compliant performance. Validators that violate protocol rules may be subject to slashing, which results in the reduction or loss of a portion of their staked tokens. The function of token burns associated with network usage is to enhance SEDA network security by reducing SEDA token supply.

(2) Network Utilization. SEDA tokens are used to enable core network operations by covering native network fees associated with computation, data delivery, and deployment of oracle programmes and data proxies to the SEDA Network. In certain execution paths, tokens are permanently removed from supply as part of protocol-defined processes associated with the usage of the SEDA Network.

(3) Network Participation. Operation of core network infrastructure requires staking SEDA tokens: main chain validators must stake SEDA token to participate in consensus; and overlay node operators are required to stake SEDA token to operate nodes used for querying data proxies. SEDA token holders may delegate tokens to main chain validators through the native Keplr dashboard to support network consensus. Through delegation, SEDA token holders may help to secure the network by delegating their tokens to validators in the active set.

(4) Governance. Validators and delegates may participate in onchain governance by voting on protocol proposals. Governance proposals are conducted through the Keplr governance forums.

SEDA

https://www.seda.xyz

2026-07-04

2026-07-03

The issuer supports the development and maintenance of the SEDA oracle infrastructure and related technical tooling. It does not provide services related to crypto-assets (e.g. trading, placement, custody, exchange).

English

JM711P4L2

KWWTM5J5T

FALSE

TRUE

TRUE

Not applicable, Holders of the SEDA token acquire a digital asset that enables – but does not confer any right to – access to certain functionalities within the SEDA decentralized oracle network. The SEDA token allows users to access and interact with the network, such as initiating and processing data requests, participating in proof-of-stake, and taking part in decentralized governance procedures within the protocol. The SEDA token does not confer, represent, or otherwise encapsulate any ownership rights, shareholder rights, off-chain governance participation, profit participation, dividends, or any claims against any natural or legal person, whether or not associated with SEDA or involved in the issuance or maintenance of the SEDA network. Holding the token does not grant voting rights in any legal entity, entitlements to assets or revenues, or any similar rights of control or benefit. The SEDA token is neither designed nor suitable for use as a means of payment, a store or transfer or value, nor as an instrument for investment or speculation purposes. Its value lies solely in its functional utility within the SEDA ecosystem. SEDA token holders may use their tokens for network participation or retain them at their discretion, subject to applicable laws and market conditions. Holders are solely responsible for the secure storage and management of their tokens (including safeguarding private keys) and for ensuring compliance with relevant legal and regulatory requirements in their jurisdictions. Token holders must recognize that no guarantee of future liquidity, price stability, or value appreciation is provided by the Open Oracle Association or other party. Holders also assume the risks associated with crypto-assets, including market volatility, technological vulnerabilities, and regulatory developments that may affect usability or value.

The SEDA token does not confer any ownership, legal entitlement, claim or financial right against the Open Oracle Association, the SEDA network, or any affiliated or non affiliated entity. Its sole function is to enable access to the SEDA network, allowing users to utilize network services, such as requesting or validating data and participating in proof-of-stake operations that secure the network. The exercise of token functionality is therefore purely operational and limited to activities within the SEDA ecosystem. All responsibilities related to the use, storage, and lawful handling of SEDA tokens - including compliance with applicable laws, regulations, and self-custody security - rest entirely with the token holder.

SEDA token does not confer any ownership, financial, or legal rights, and therefore no modifications to holder’s rights and obligations may be made. On-chain governance within the SEDA network is limited to technical parameters of the protocol.

Not applicable

TRUE

The SEDA project develops a decentralized oracle infrastructure that enables secure and efficient transmission of off-chain and on-chain data across multiple blockchain environments. Using the SEDA utility token, users can request and access verified data through the network’s programmable oracle layer; stake tokens to secure the network and validate data integrity via proof-of-stake; participate in on-chain governance, voting on protocol parameters and upgrades; deploy oracle programmes to define computation and data sources where data should be pulled from; and register data proxies to expose private API data on-chain with payment or allowlist based gating. The services are designed to provide reliable data connectivity, interoperability, and transparent governance for developers and decentralized applications. The SEDA token serves solely as a utility tool within this ecosystem and confers no ownership, profit rights or any claims of any kind.

The SEDA token is not redeemable. Its use and value derive from its functionality within the SEDA network. No redemption right or reimbursement right exists for token holders.

TRUE

Not applicable

Not applicable

FALSE

The SEDA token does not operate under a demand-based supply mechanism in which token minting and burning are automatically adjusted in response to market conditions or demand.

The SEDA Network has an inflation module that incentivizes validators to run the SEDA network. Total SEDA token supply can increase based on inflation with a predetermined schedule defined by governance. SEDA token supply can also decrease based on token burns initiated by the data request lifecycle. The SEDA token can not be minted or further increased outside of the inflation parameters set by governance.

FALSE

Not applicable

FALSE

Not applicable

Switzerland

Competent courts of Zug, Switzerland

The SEDA token is issued, transferred, and stored on the SEDA Chain, a permissionless, application-specific layer-1 blockchain built using the Cosmos SDK framework. The SEDA Chain is an open-source, public distributed ledger licensed under GNU General Public License v3.0. It uses a Proof-of-Stake (PoS) consensus mechanism, securing the ledger through an active validator currently set of up to 100 validators selected by staked weight delegated from the community. Any entity may operate a validator node. The SEDA Chain coordinates and settles data requests, stores oracle program deployments, and maintains the canonical on-chain state for the SEDA ecosystem. The native denomination of the chain is aseda (the smallest unit of the SEDA token).

Networking Layer

The SEDA Chain operates a permissionless peer-to-peer network built on the Cosmos SDK framework and the CometBFT consensus engine (successor to Tendermint Core). CometBFT uses a gossip-based protocol for propagating block proposals and votes across the validator set.

Consensus and Application Interface

The SEDA Chain implements the Application Blockchain Interface (ABCI), which separates the consensus engine (CometBFT) from the application state machine. This separation allows the chain to execute domain-specific logic, including data request settlement and Oracle Program management, independently of the consensus layer.

Smart Contract Runtime

On-chain contracts are implemented and executed using CosmWasm (based on the WebAssembly / WASM standard). Oracle Programs are compiled to and stored as WASM binaries on-chain and assigned unique Oracle Program IDs.

Cryptographic Standards

Validator consensus signing uses standard Cosmos SDK secp256k1 key pairs. Starting with v1.0.0 of the SEDA Chain, validators are additionally required to generate and register SEDA Keys — a dedicated secp256k1 key used for batch signing duties at the application layer.

Token Denomination Standard

The SEDA token conforms to the Cosmos coin type 118 standard for HD wallet derivation.

Licensing

The SEDA Chain software is open-source, released under GNU General Public License v3.0.

The SEDA network is built on advanced DLT as described above, and comprises a modular, interoperable architecture designed for programmable oracle infrastructure.

Key components include:

• SEDA Chain: the application-specific layer-1 blockchain that serves as the canonical ledger for data request settlement, proof aggregation and consensus. It is built using the Cosmos SDK and leverages Proof-of-Stake consensus mechanisms, enabling token holders to delegate to validators who maintain consensus security.
• Overlay Network: The Overlay Network is a permissionless, multi-party computational network designed to host tens of thousands of independently operated nodes. Its primary responsibility is to query data sources, including public API endpoints and private data providers accessible through registered Data Proxies, as defined by a protocol's Oracle Program. When a data request is issued, Overlay Nodes form randomized secret committees (the size determined by the protocol's replication factor) that independently query data sources and return results using a commit-reveal scheme to maintain data integrity. Overlay Node operators must stake SEDA tokens to participate. The Overlay Network is being launched in phases; the initial phase comprises a whitelisted selection of professional validator companies before expanding to fully permissionless participation.
• Solver Network & Prover Contract: The Solver Network manages the routing of data requests from user chains into the SEDA network and returns cryptographically secured and tamper-proof results via Prover contracts deployed on destination blockchains. This architecture enables bi-directional data flow between any supported chain and the SEDA chain. The Prover Contract is permissionless and can be deployed to any blockchain at any time. Any network or protocol gains access to SEDA's data infrastructure by deploying a single Prover Contract monitored by the Solver Network, without requiring direct integration with the SEDA Chain itself.
• Oracle Programmes: At the application layer, developers can define custom Oracle Programs, specifying data sources, aggregation logic, filtration, and computation. 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. SEDA is built to be chain-agnostic and support integrations across many blockchains. Its modular architecture allows a single Prover Contract deployment to enable data access on multiple chains, reducing integration complexity. Oracle Programs additionally incorporate a Data Request (DR) Tally function, enabling protocols to define their data filtration and aggregation parameters. This ensures results from the Overlay Network are structured in a format compatible with the requesting application.

The SEDA Chain is built on the Cosmos SDK, which uses CometBFT (formerly Tendermint Core) as its consensus engine.

CometBFT is a deterministic Byzantine Fault Tolerant (BFT) consensus protocol that achieves agreement among a fixed validator set under partial synchrony. The mechanism is height–round–step based, where each block height progresses through sequential consensus rounds until a block is finalized. Each round consists of three primary steps: Propose, Prevote, and Precommit. This three-phase round structure, combined with validator locking and +2/3 voting power thresholds, guarantees both safety (no two conflicting blocks can be committed at the same height) and liveness (progress under partial synchrony). Consensus messages are signed and broadcast via a gossip network, ensuring verifiability and fork accountability for any double-voting or equivocation.

On the SEDA Chain, the active validator set is currently capped at 100 validators. Validators are selected for participation based on their staked weight, as delegated from the community. Any entity may operate a validator node; inclusion in the active set is permissionless and determined solely by staked weight. In addition to consensus participation, SEDA Chain validators perform batch signing duties at the application layer. Starting with SEDA Chain v1.0.0, validators are required to generate a dedicated SEDA Key (secp256k1) and register its public key on-chain to perform these batch signing duties. Failure to comply with signing requirements may expose validators to jailing risk.

Validator Incentives

The SEDA Chain distributes native inflation issuance to validators and their delegators as block rewards, proportional to staked voting power. Validators that comply with protocol rules, including block production and batch signing duties, receive a share of this inflation. Misbehaviour (including double-signing or failure to participate) is cryptographically provable and results in slashing, where a portion of the validator's bonded stake is destroyed. The inflation schedule and parameters are subject to on-chain governance.

Token Burns from Data Request Execution

A core element of the SEDA incentive model is protocol-defined token burning. Every data request executed on the SEDA Network results in SEDA token burns as part of on-chain network processes. In certain execution paths, tokens are permanently and irreversibly removed from supply. This burn mechanism is structural and observable on-chain via the SEDA explorer, and its relationship to network usage is direct: as more Oracle Programs are deployed and more data requests are executed, more tokens are burned, reducing total circulating supply.

Solver Fee Structure

Solvers in the SEDA Solver Network quote a data request cost to data requestors comprising: (1) the solver's service fee; (2) data provider set costs; (3) SEDA Chain computation and gas costs; and (4) overlay cost for source query. Solvers settle fees with data requestors in a currency of their choice, then use their own inventory of SEDA tokens to relay the request to the SEDA Network. Solvers are economically independent operators responsible for managing their own SEDA token inventory.

Overlay Node Participation

Overlay node operators are required to stake SEDA tokens to participate in data retrieval committees. Token holders may delegate SEDA tokens to overlay nodes in a manner similar to validator delegation, aligning economic incentives with honest data retrieval.

Supply Adjustment

Total SEDA token supply may increase through inflation (with a governance-defined schedule) and decrease through data request burns. No minting or supply increase is possible outside the inflation parameters set by governance.

FALSE

TRUE

Trail of Bits — Chain Token Migration Security Assessment (March 2024)

• Object: External security assessment of the SEDA Chain token migration contracts, staking modules, and vesting modules, conducted by Trail of Bits. The review covered the migration of the SEDA token from its prior form onto the SEDA Chain, including the associated smart contract logic and on-chain staking and vesting infrastructure.
• Results: The assessment identified access-control and configuration-related findings. A fix-review appendix was conducted following the initial report. The trail-of-bits GitHub publication of the full report is accessible at: https://github.com/trailofbits/publications/blob/master/reviews/2024-03-seda-chaintokenmigration-securityreview.pdf
• Actions: The SEDA development team addressed the identified findings. A follow-up review confirming fixes is included in the comprehensive report with fix-review appendix.

Sherlock — SEDA Network Full Feature Launch Audit (February–March 2025, report finalized April 2025)

• Object: Security audit of the SEDA Network covering the full feature set at mainnet launch, including SEDA Chain oracle batch proof accessibility and the verification of oracle batch proofs across EVM destination chains. The audit was conducted by Sherlock under contest id 729 and ran from 17 February to 10 March 2025. Scope included cross-chain data transmission security, prover contract logic, and batch proof verification.
• Results: No high-severity vulnerabilities were identified that would compromise the core goals of the SEDA system. The audit confirmed the absence of critical or high-severity issues in the audited scope. Lower-severity findings were documented in the report.
• Actions: All identified findings were remediated by the SEDA team prior to mainnet full feature launch. The full report is linked from the SEDA audit documentation page: https://docs.seda.xyz/home/resources/audits/sherlock-audit-of-seda-network-full-feature-launch-april-2025

The admission to trading-related risks associated with the SEDA token primarily arise from the inherent characteristics of crypto-assets and the decentralized, rapidly evolving environment in which they operate.

(1) Market Risk: The value of the SEDA token may fluctuate significantly within short timeframes due to market volatility, investor sentiment, macroeconomic events, technological developments, regulatory developments, and overall market conditions. These fluctuations may lead to substantial financial loss for token holders, particularly those who are unaware of or unprepared for the high-risk nature of digital assets.

(2) Liquidity Risk: While SEDA tokens are or may be admitted to trading on certain exchanges, liquidity levels may vary across trading venues and over time. There is no assurance that token holders will be able to sell their tokens promptly or at a desirable price, particularly during periods of market stress or limited trading activity.

(3) Regulatory Risk: The regulatory landscape for crypto-assets remains under development globally. While SEDA is generally considered a utility token and does not fall under the scope of financial instruments or e-money under MiCAR, future regulatory changes or differing interpretations across jurisdictions could impact its classification, use, or tradability within the EU or other jurisdictions.

(4) Technology and Operational Risks: SEDA transactions are executed on a public blockchain and chain functionality. Risks include network congestion, elevated network fees associated with computation, data delivery, oracle program deployment , smart contract vulnerabilities, and potential forks or upgrades that could disrupt normal operations. Additionally, token holders bear sole responsibility for the secure custody of their SEDA tokens, including protection against loss of private keys, phishing, unauthorized access or other cyber threats.

(1) Operational Risks: Open Oracle Association’s effectiveness depends on robust internal processes, governance, and technology management. Failures in operational integrity such as process breakdowns, inadequate controls, or resource limitations could cause service disruptions, delays, or reputational harm to the SEDA ecosystem.

(2) Technology Management Risks: Open Oracle Association oversees certain technological development and coordination functions. Failure to implement timely software updates, address vulnerabilities, or adapt to new industry standards could expose the SEDA network to security incidents or technological obsolescence.

(3) Dependency on Key Individuals: The success of Open Oracle Association’s initiatives depends highly on the expertise and continuity of its leadership and contributors. The loss or unavailability of key individuals may cause delays in development, loss of strategic direction, loss of trust, or project failure.

(4) Financial Risks: Open Oracle Association may face financial risks, including liquidity, credit, and market risks. These could affect its ability to maintain operations, meet obligations, or preserve the stability of the SEDA ecosystem and token.

(5) Legal Risks: Open Oracle Association may face legal uncertainties, regulatory challenges, or potential litigation, which could impact the legality, usability, or value of the SEDA token.

(6) Fraud and Mismanagement Risks: While Open Oracle Association follows transparent governance principles, mismanagement, internal misconduct, or conflicts of interest could undermine trust in the association or the SEDA project, potentially affecting network stability and token value.

(7) Regulatory Compliance Risks: Open Oracle Association operates across a rapidly evolving international regulatory environment. Changes in applicable legislation or divergent interpretations across jurisdictions could impose new compliance obligations, restrictions, or registration requirements. Failure to meet these obligations may result in fines, sanctions, or the restriction on the availability or trading of SEDA tokens within certain markets.

(8) Reputational Risks: Negative publicity - whether due to operational failures, security breaches, or association with illicit activities - can damage the reputation of Open Oracle Association and, by extension, the value and acceptance of the SEDA token.

(9) Conflicts of Interest: Risks arise when an issuer's interests do not align with those of the crypto-asset holders, potentially leading to decisions that are not in the best interests of the asset holders, impacting the value of a crypto-asset or damage the credibility of the project.

(10) Counterparty Risks: Open Oracle Association collaborates with external partners, validators, and service providers. Risks may arise if these partners fail to perform obligations, which could negatively affect Open Oracle Association’s operations or the network’s integrity.

(1) Custodial Risk: Crypto-assets are vulnerable to theft from exchanges or wallets, loss of private keys, or failure of custodial services, which can lead to the irreversible loss of crypto-assets.

(2) Smart Contract Risk: Crypto-assets may rely on smart contracts. Bugs or vulnerabilities in smart contract code can expose blockchain users to potential hacks, exploits, or unintended outcomes. These risks may result in crypto-assets losses or unauthorized access to sensitive data.

(3) Regulatory and Tax Risk: Changes in regulations, such as consumer protection, taxation, and anti-money laundering, could affect the usability, value, or legality of crypto-assets in different jurisdictions.

(4) Counterparty Risk: When crypto-assets are used in contractual agreements or held on exchanges, there is a risk that counterparties may default on their obligations due to insolvency, compliance issues, or fraud, resulting in loss of crypto-assets, operational disruptions.

(5) Reputational Risk: Involvement in illicit activities, security breaches, or technological failures can damage the reputation of a crypto-assets, impacting user trust and market value.

(6) Market Risk: Crypto-assets are highly volatile, with prices fluctuating significantly due to market sentiment, regulatory developments, technological advancements, and macroeconomic conditions.

(7) Liquidity Risk: Certain crypto-assets may experience low liquidity, making it challenging to execute large amounts without affecting the market price, which could lead to significant losses, especially in fast-moving market conditions.

(1) Network Adoption Risks: The value and functionality of the SEDA token depend on participation by data providers, validators, developers, and end users within the ecosystem. Limited adoption or competition may reduce network activity, token utility and demand.

(2) Concentration of Governance Influence: If a small number of large validators accumulate disproportionate staked voting power, this may reduce the practical decentralization of on-chain governance and lead to decisions that do not reflect the broader stakeholder community's preferences.

1) Data Accuracy and Manipulation Risk: The project provides off-chain and on-chain data for blockchains, and inaccurate, manipulated, or compromised data sources could result in erroneous executions.

(2) Scalability Risk: As the number of users and transactions grows, a blockchain network may face scaling challenges. This could lead to increased transaction fees and slower transaction processing times, affecting usability and costs.

(3) Economic Self-sufficiency: The long-term sustainability of the SEDA network depends on achieving sufficient transaction volume and economic activity to incentivize participants. Failure to reach this threshold could lead to reduced participation, protocol changes (e.g., fee structures or rewards), or declining network relevance.

(4) Byzantine Validator Attacks: If an attacker gains control of more than one-third of the total staked voting power in the active validator set, they could compromise the safety or liveness of the CometBFT consensus mechanism, potentially disrupting block production or, in extreme cases, enabling conflicting block commits.

(5) Consensus Failures or Forks: Faults in the consensus mechanism can lead to forks, where multiple versions of the ledger coexist, or network halts, potentially destabilizing the network and reducing trust among participants.

(6) Bugs in the Blockchain’s Core Code: Even with thorough testing, there is always a risk that unknown bugs may exist in a blockchain protocol, which could be exploited to disrupt network operations or manipulate account balances. Continuous code review, audit trails, and having a bug bounty program are essential to identify and rectify such vulnerabilities promptly.

(7) Smart Contract Security Risk: Bugs or vulnerabilities in smart contract code can expose blockchain networks to potential hacks and exploits. Any flaw in the code can lead to unintended consequences, such as the loss of crypto-assets or unauthorized access to sensitive data.

(8) Dependency on Underlying Technology: Blockchain technology relies on underlying infrastructures, such as specific hardware or network connectivity, which may themselves be vulnerable to attacks, outages, or other interferences.

(9) Risk of Technological Disruption: Technological advancements or the emergence of new technology could impact blockchain systems, or components used in it, by making them insecure or obsolete (e.g. quantum computing breaking encryption paradigms). This could lead to theft or loss of crypto-assets or compromise data integrity on the network.

(10) Governance Risk: Governance in blockchain technology encompasses the mechanisms for making decisions about network changes and protocol upgrades. Faulty governance models can lead to ineffective decision-making, slow responses to issues, and potential network forks, undermining stability and integrity. Moreover, there is a risk of disproportionate influence by a group of stakeholders, leading to centralized power and decisions that may not align with the broader public’s interests.

(11) Anonymity and Privacy Risk: The inherent transparency and immutability of blockchain technology can pose risks to user anonymity and privacy. Since all transactions are recorded on a public ledger, there is potential for sensitive data to be exposed. The possibility for the public to link certain transactions to a specific address might expose it to phishing attacks, fraud, or other malicious activities.

(12) Data Corruption: Corruption of blockchain data, whether through software bugs, human error, or malicious tampering, can undermine the reliability and accuracy of the system.

(13) Third-Party Risks: Crypto-assets often rely on third-party services such as exchanges and wallet providers for trading and storage. These platforms can be susceptible to security breaches, operational failures, and regulatory non-compliance, which can lead to the loss or theft of crypto-assets.

(14) Oracle Data Integrity Risk: The SEDA Network relies on Overlay Nodes forming secret committees to retrieve and return data. If a sufficient number of nodes within a committee are compromised, manipulated, or collude to return false data, oracle programs could produce inaccurate results delivered to destination chains. The commit-reveal scheme and replication factor parameters partially mitigate this risk, but cannot eliminate it entirely.

(15) Data Provider Dependency Risk: Oracle Programs that rely on specific private data providers connected via Data Proxies are dependent on the continued availability and accessibility of those providers. If a data provider restricts, modifies, or terminates access to their API, affected oracle programs may produce inaccurate, incomplete, or unavailable data results for downstream consumers.

Offer-Related Risks

• Technology and Operational Risks: Open Oracle Association and the SEDA development community maintain robust software development practices, including code reviews and external security audits (as documented in H.9). SEDA Chain software is open-source, enabling community scrutiny. Token holders bear responsibility for the secure self-custody of their SEDA tokens and are directed to use supported wallet solutions, including hardware wallets.

Issuer-Related Risks

• Operational Risks: Open Oracle Association maintains internal governance frameworks and operational procedures designed to ensure continuity of its coordination and development activities. Responsibilities are distributed across the management body and contributing teams to reduce dependency on single points of failure.
• Technology Management Risks: Open Oracle Association follows structured software development and change management procedures. The SEDA Chain is open-source under GNU GPL v3.0, enabling community review and independent contributions. External security assessments are conducted prior to major network launches, as documented in H.9 (Trail of Bits, March 2024; Sherlock, February–March 2025).
• Dependency on Key Individuals: Open Oracle Association distributes responsibilities across its management body and contributor teams, reducing single-person dependency risk.
• Financial Risks: Open Oracle Association manages its capital conservatively, with treasury allocations supporting ongoing R&D and operational activities. Expenditure is primarily directed to research, development, and ecosystem growth. Live circulating supply and treasury data are publicly verifiable on-chain at https://explorer.seda.xyz.
• Legal Risks: Open Oracle Association retains legal counsel to monitor and respond to applicable regulatory developments. This white paper is prepared in compliance with MiCA (Regulation (EU) 2023/1114) as the primary applicable EU regulatory framework.
• Fraud and Mismanagement Risks: Open Oracle Association maintains transparent governance and communicates with the community in a fair, clear, and not-misleading manner. Token burns, staking, and transaction activity are publicly verifiable on-chain via the SEDA explorer at https://explorer.seda.xyz/trends.
• Regulatory Compliance Risks: Open Oracle Association actively monitors international regulatory developments and maintains compliance frameworks aligned with applicable law. The preparation of this MiCA white paper reflects Open Oracle Association's commitment to regulatory compliance within the European Union.
• Reputational Risks: Open Oracle Association maintains public disclosure of SEDA's technical architecture, token allocation, and on-chain activity through official documentation at https://docs.seda.xyz and the SEDA explorer at https://explorer.seda.xyz. MiCA compliance serves as an additional credibility mechanism for EU market participants.
• Conflicts of Interest: Open Oracle Association operates as a not-for-profit organization with the sole purpose of supporting the SEDA ecosystem.
• Counterparty Risks: Open Oracle Association evaluates and monitors relationships with external partners, validators, and service providers. The permissionless nature of the SEDA Chain means that no single validator, solver, or overlay node operator is indispensable to network continuity.

Crypto-Assets-related Risks

• Custodial Risk: SEDA tokens may be held in non-custodial wallets supported by hardware devices (e.g. Ledger, Keplr, Leap Wallet), reducing exposure to third-party custodial risk. Token holders are solely responsible for the secure management of their private keys. Supported wallet options are documented at https://docs.seda.xyz/home/token-overview/access-and-delegate-seda-token.
• Smart Contract Risk: SEDA Chain smart contracts (CosmWasm) and EVM contracts have been subjected to external security assessments prior to mainnet launch, as detailed in H.9. The SEDA chain contracts and EVM contracts are open-source, available for community review at https://github.com/sedaprotocol/seda-chain-contracts and https://github.com/sedaprotocol/seda-evm-contracts.
• Regulatory and Tax Risk: This white paper is prepared in compliance with Regulation (EU) 2023/1114 (MiCA). Holders are solely responsible for determining and complying with applicable tax and regulatory obligations in their respective jurisdictions.
• Counterparty Risk: The permissionless and decentralized nature of the SEDA Chain reduces single-counterparty dependency. Validators are selected from a competitive pool of currently up to 100 based on staked weight, and no single validator controls the network. Data on active validators is publicly available at https://wallet.keplr.app/chains/seda.
• Reputational Risk: On-chain transaction and burn activity are publicly observable via the SEDA explorer (https://explorer.seda.xyz), providing transparency that supports market confidence.

Project Implementation-Related Risks

• Network Adoption Risks: Open Oracle Association supports ongoing ecosystem growth through research and development, community engagement, technical enablement, partnerships, and integrations. The SEDA network currently serves approximately 30 active integration or partner projects, with on-chain activity publicly verifiable at https://explorer.seda.xyz/trends. Future milestones targeting expanded adoption are described in D.8.
• Decentralization and Governance Risk: On-chain governance proposals are submitted and voted upon by validators and their delegators, distributing decision-making across the active validator set. The Keplr dashboard warns users against delegating to any single validator controlling more than 5% of the total circulating token supply, providing a decentralization safeguard: https://wallet.keplr.app/chains/seda. On-chain governance activity is publicly observable.

Technology-Related Risks

• Data Accuracy and Manipulation Risk: The Overlay Network's commit-reveal scheme and secret committee formation are designed so that individual nodes cannot know committee composition in advance, reducing coordinated data manipulation risk. Data requestors may configure the replication factor within their Oracle Program to increase the number of nodes querying a given data source. Oracle Programs may be configured to query multiple independent data sources, further reducing single-source manipulation risk.
• Scalability Risk: The SEDA Chain architecture separates consensus (CometBFT) from application logic (via the ABCI interface), enabling optimization of each layer independently. The modular design of the SEDA network, including the Overlay Network and Solver Network, is intended to scale to tens of thousands of nodes
• Economic Self-sufficiency: The token burn mechanism ties SEDA's economic sustainability directly to network usage: as data request volume grows, more tokens are burned, structurally aligning protocol economics with adoption. Inflation parameters are governance-controlled, allowing the network to adjust rewards in response to participation levels.
• Network Attacks and Cyber Security Risks: CometBFT's Byzantine Fault Tolerant consensus design tolerates up to one-third of validators behaving maliciously or failing arbitrarily. Economic alignment is enforced through staking (validators bond SEDA tokens) and slashing (misbehaviour results in permanent destruction of bonded stake). The top-100 permissionless validator structure distributes consensus security across independent operators with competing economic interests.
• Consensus Failures or Forks: CometBFT is a deterministic consensus protocol that produces single, finalized blocks; there is no probabilistic fork risk of the kind associated with proof-of-work chains. CometBFT's fork-accountability mechanism allows equivocating validators to be identified and slashed.
• Bugs in the Blockchain's Core Code: SEDA Chain software is open-source (GNU GPL v3.0), enabling community review. The development team conducts regular code reviews and engages external security firms for independent audits. Two external security assessments have been conducted prior to full mainnet feature launch, as documented in H.9.
• Smart Contract Security Risk: SEDA chain contracts (CosmWasm) and EVM contracts are open-source and have been independently audited by Trail of Bits (March 2024) and Sherlock (February–March 2025). All findings identified in these audits were remediated prior to mainnet full feature launch.
• Dependency on Underlying Technology: The SEDA Chain operates on standard server-grade hardware, with minimum requirements of a Quad Core AMD/Intel CPU, 32GB RAM, 1TB SSD, and a 100Mbps bidirectional connection. These are conventional datacenter specifications not dependent on specialized or scarce hardware.
• Governance Risk: On-chain governance is conducted through the Keplr governance forum, with voting rights distributed across validators and their delegators. The Keplr dashboard applies a 5% concentration warning to discourage excessive voting power consolidation. Governance proposals and their outcomes are publicly recorded on-chain. Source: https://docs.seda.xyz/home/token-overview/seda-token-utility.
• Anonymity and Privacy Risk: SEDA Chain transactions are recorded on a public distributed ledger and are pseudonymous rather than anonymous. Token holders should be aware that on-chain activity is publicly observable. Holders are advised to manage their on-chain addresses carefully to minimise linkability.
• Data Corruption: CometBFT's deterministic consensus and Merkle-proof-based state verification are designed to detect and prevent data corruption at the protocol level. Conflicting or corrupted state transitions are rejected by the validator set as part of the consensus process.
• Third-Party Risks: SEDA bridges and exchange integrations involve independent third-party operators. SEDA's official documentation lists verified third-party token deployment addresses for the SEDA token on Ethereum, HyperEVM, and Base at https://docs.seda.xyz/home/token-overview/seda-token-information. Holders should verify contract addresses before interacting with any bridge or exchange. Bridge and exchange services are independent of Open Oracle Association, which bears no liability for third-party service availability or performance.
• Data Provider Dependency Risk: Oracle Programs may be configured to query multiple independent data providers, reducing reliance on any single source. Data Proxies are permissionless and replaceable; the open-source Data Proxy software is available at https://github.com/sedaprotocol/seda-data-proxy, enabling new data providers to connect without issuer approval.

Open Oracle Association

CHE-195.612.455

SEDA

The SEDA Chain is built on the Cosmos SDK, which uses CometBFT (formerly Tendermint Core) as its consensus engine.

CometBFT is a deterministic Byzantine Fault Tolerant (BFT) consensus protocol that achieves agreement among a fixed validator set under partial synchrony. The mechanism is height–round–step based, where each block height progresses through sequential consensus rounds until a block is finalized. Each round consists of three primary steps: Propose, Prevote, and Precommit. This three-phase round structure, combined with validator locking and +2/3 voting power thresholds, guarantees both safety (no two conflicting blocks can be committed at the same height) and liveness (progress under partial synchrony). Consensus messages are signed and broadcast via a gossip network, ensuring verifiability and fork accountability for any double-voting or equivocation.

On the SEDA Chain, the active validator set is currently capped at 100 validators. Validators are selected for participation based on their staked weight, as delegated from the community. Any entity may operate a validator node; inclusion in the active set is permissionless and determined solely by staked weight. In addition to consensus participation, SEDA Chain validators perform batch signing duties at the application layer. Starting with SEDA Chain v1.0.0, validators are required to generate a dedicated SEDA Key (secp256k1) and register its public key on-chain to perform these batch signing duties. Failure to comply with signing requirements may expose validators to jailing risk.

Validators in CometBFT-based systems are incentivized through protocol-level inflation that mints new tokens and distributes them as block rewards proportional to each validator’s staked voting power. By staking their own or delegated tokens, validators gain the right to participate in block proposals and voting, earning rewards for correctly signing and committing blocks. Misbehavior, such as double-signing, failing to participate, or proposing invalid blocks, can be cryptographically proven and results in slashing, where a portion of the validator’s stake is destroyed or confiscated. This combination of inflationary rewards for honest participation and punitive slashing for Byzantine or negligent behavior ensures economic alignment between validator incentives and network security, maintaining protocol integrity over time.

2026-01-01

2026-05-28

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5). As the base layer is a decentralized network, estimates on individual node power draw are used.
Full methodology available at: www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at: www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at: www.micacryptoalliance.com/methodologies

Land use: 1.70182 m²

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at: www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at: www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5). As the base layer is a decentralized network, estimates on individual node weight, hazardous components and depreciation rate are used.
Full methodology available at: www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5). Usage of natural resources is approximated through land use metrics. Land use, water use and water recycling are calculated based on energy mix-specific estimates of purchased electricity land intensity, purchased electricity water intensity, and water recycling rates.
Full methodology available at: www.micacryptoalliance.com/methodologies