The SEDA protocol involves two types of smart contracts with distinct scopes:

1. CosmWASM contracts: These implement the core business logic of the protocol and are deployed exclusively on the SEDA Chain.

2. EVM contracts: These facilitate interoperability between SEDA and other networks. They are deployed on the following EVM-compatible chains:

• Ethereum
• Base
• Arbitrum
• Optimism
• Ink

The SEDA Network operates with the SEDA Chain’s native token (SEDA), which follows coin type 118 and has 18 decimals.

The EVM contracts interact with the chain’s native token, primarily ETH on Ethereum and equivalent native assets on other chains. No additional token standards are integrated at this stage.

The SEDA protocol is designed for progressive decentralization, but in its early stages, a failsafe mechanism based on roles and admin controls ensures stability, security, and incident response. These controls will be phased out or permanently disabled as the network matures.

1. SEDA Chain
   Governance follows the standard Cosmos SDK governance model, where on-chain proposals and community voting determine module parameter changes and network upgrades. There are no arbitrary admin-controlled limitations beyond what is defined by governance.
   A key aspect for the SEDA protocol is that WASM module parameters specify which accounts are authorized to upload and instantiate CosmWasm contracts, ensuring controlled and secure deployment.

2. CosmWASM Core Contracts
   The Core Contracts owner account can:

• Pause and unpause the contract.
• Configure staking parameters (minimum stake, eligibility, allowlist enforcement).
• Manage the allowlist of executors (overlay nodes executing data requests).
  The owner account and authorized deployment accounts are assigned to a security group account, a multi-signature account for enhanced security.

1. EVM Contracts
   The contracts follow a UUPS upgradeable proxy pattern, where an owner can perform contract upgrades.
   The Prover contract and the Core contract are PausableUpgradeable, allowing the owner to pause and unpause contract operations.

No.

No.

There are two off-chain components of the SEDA Network; the SEDA Overlay Network and the decentralized Solver Network.

SEDA Overlay Network

The SEDA Overlay Network is a multi-party computational network built to host tens of thousands of independently operated nodes. The primary responsibility of The Overlay Network is to query data sources as defined by a protocol Oracle Program.
The Oracle Program configuration determines the number of nodes elected, allowing for a customizable replication factor that balances scalability and decentralization. This secret committee independently queries the specified data sources and submits their results using a commit-reveal scheme. This process maintains data integrity and decentralized data querying, while eliminating the need for a single source of truth.

At the time of this audit, the SEDA Overlay Network will be launched in phased roll-out with a subset of allowlisted professional validators. The Overlay Network will be upgraded in the future to a permissionless model, incorporating staking and slashing mechanisms to secure participation and incentivize honest behavior. In the future, when a Data Request is submitted on the SEDA Chain, a randomly selected subset of Overlay Nodes forms a secret committee tasked with executing the data request binaries stored in the Oracle Program. This selection process leverages cryptographic sortition to ensure fairness and unpredictability, enhancing decentralization and security.

Decentralized Solver Network

The Solver Network is responsible for delivering data requests from the SEDA Prover Contract to the SEDA Chain for execution and returning the Data Request results back to the SEDA Prover Contract on the origin network.
To ensure tamper resistance, data results are batched, and each batch is signed by multiple validators using ECDSA signatures. The Solver submits the signed batch to the SEDA Prover Contract, which verifies its integrity and authenticity. When individual results are later submitted, they are verified against the corresponding batch using proofs of inclusion, ensuring they originate from a valid, previously verified batch.

SEDA Chain

• All active validators must have a registered Proving Public Key for batch signing. This requirement only applies once a proving scheme is activated, such as through a network upgrade proposal.

CosmWASM Contracts & EVM Contracts

• Both contracts lock tokens upon posting of a data request to ensure that all involved parties receive their designated allocations.
• Once a data request is resolved, the entire amount should be fully distributed, ensuring no excess tokens remain in the contract.
• When there are no ongoing data requests, the contract’s token balance should always be zero.

SEDA Chain

• Gas Allocation: The gas allocation model is designed to incentivize honest behavior in a simple yet effective way. Overlay nodes report their gas usage, but to discourage inflated reporting, the lowest gas reporter receives additional rewards compared to others. This ensures that nodes are incentivized to use and report only the necessary amount of gas, preventing unnecessary overuse of network resources.
• Fee Distribution: To maintain integrity in fee distribution, the protocol uses tally filtering to identify and exclude outliers. Only nodes non-outliers receive rewards, while outliers are filtered out. If the tally filter is too aggressive, meaning no clear consensus is reached, all participants are rewarded to prevent honest nodes from being unfairly penalized. Additionally, in cases where execution occurs but fails due to errors (e.g., no consensus or invalid filter input), only 80% of rewards are distributed, and 20% is burned, ensuring that execution efforts are still compensated while discouraging repeated failures.
• Refunding Unused Gas: Since gas usage is unpredictable due to the non-deterministic nature of external data, users can set a gas limit for execution and tally phases. Any unused gas is refunded, as overlay nodes are already incentivized to report their gas usage accurately due to the gas allocation mechanism. This ensures that users are not overcharged for gas they do not use while keeping the network efficient.
• Data Proxy Fees: To simplify cost predictability for data providers, fees are denominated in SEDA tokens. This approach makes it easier for providers to estimate their earnings per request. However, because execution costs are incurred in gas, the protocol translates these fees into gas units using the data request gas price, ensuring consistency across gas allocation and fee distribution.
• Batch Signing: Batch signing is implemented using vote extensions in ABCI++, as it provides an efficient method without introducing significant breaking changes to Cosmos SDK modules. This design choice allowed for seamless integration without modifying the block data structure, ensuring compatibility and maintainability.
• Batching Proving Metadata: Although this field is currently unused, it is reserved for future proving schemes. For example, proving schemes with signature aggregation, which would require storing an aggregated public key alongside the corresponding voting power of participating validators. This flexibility allows the protocol to evolve without requiring significant breaking changes.
• Double Batch Signing: To maintain consistency with existing validator security mechanisms, double batch signing incurs the same penalty as double block signing. This ensures that validators are held accountable for signing multiple conflicting batches, reinforcing network security and trust.

CosmWasm Core Contracts:

• Executor Allowlist: The allowlist is part of the phased decentralization of the Overlay Network. While any executor is technically eligible, only reputed and vetted operators are expected to be added. Inactive or malicious actors can be removed at any time to maintain network integrity.
• Multiple Identities: Users do not need separate wallets for each identity they operate. While this feature is less relevant under the current allowlist model, it will become crucial once the Overlay Network is fully decentralized. It allows users to run multiple identities efficiently, maximizing hardware utilization for vertical scaling, which enhances network security and performance.
• Pausable: A failsafe mechanism to mitigate and respond to incidents or unexpected failures. This allows intervention when necessary to maintain system stability.
• No Slashing / No Unstaking: This is a temporary measure as part of the phased decentralization process. Slashing and unstaking mechanisms will be introduced once the Overlay Network becomes permissionless. Until then, inactive or malicious actors can still be removed from the allowlist to uphold network integrity.

EVM Contracts:

• Pausable: A failsafe mechanism designed to mitigate and respond to incidents. This ensures that contract operations can be temporarily halted if necessary to maintain system integrity.
• UUPS Proxy Pattern: The contracts follow the UUPS (Universal Upgradeable Proxy Standard) pattern, providing upgradeability in the early stages of development. This enhances developer experience while allowing improvements over time. The upgradeability feature can be renounced, ensuring the contracts remain immutable once they reach a stable state.
• Not Optimized Implementations: The contracts serve as reference implementations, prioritizing clarity and functionality over full optimization. While gas efficiency improvements are possible, the current design ensures broad compatibility with various use cases, even if storage and execution costs are not fully optimized.

Further details are available in the 'SEDA Protocol Audit Overview' document listed below.

SEDA engaged Trail of Bits to review the security of its token migration contracts and the SEDA chain’s staking and vesting modules.
https://github.com/trailofbits/publications/blob/master/reviews/2024-03-seda-chaintokenmigration-securityreview.pdf

SEDA Protocol Audit Overview: https://sedaprotocol.notion.site/SEDA-Protocol-Audit-Overview-190a68d575ca807ca2a2d4e232a77781

SEDA Website: https://seda.xyz

Additional Resources

• SEDA Primer for Key Features: https://docs.seda.xyz/home/overview/seda-overview/seda-primer-for-key-features
• SEDA Network Architecture: https://docs.seda.xyz/home/overview/seda-network-architecture
• Data Requests: https://docs.seda.xyz/home/for-developers/data-requests
• Accessing Data from any Network: https://docs.seda.xyz/home/for-developers/access-data-from-any-network
• Building an Oracle Program: https://docs.seda.xyz/home/for-developers/building-an-oracle-program

The following areas are of particular importance for the audit:

• Data Integrity: While data integrity mechanisms rely on battle-tested cryptographic primitives, they are fundamental to the SEDA protocol’s correctness. Ensuring that results remain tamper-proof and resistant to manipulation is a top priority.
• Gas Allocation and Fee Payments: The gas allocation and fee distribution processes are inherently complex. Special attention should be given to potential edge cases that could impact fairness, efficiency, or execution reliability.
• Tally WASM VM Robustness: The robustness of the Tally WASM VM is critical to ensuring uninterrupted operations. Possible denial-of-service (DoS) vectors or unexpected behavior could lead to operational disruptions, affecting data request execution and overall system stability.