SEDA Protocol — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for SEDA Protocol, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 28
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 28 closed, publicly disclosed SEDA Protocol reports indexed on CoinBuggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Logic error, Front-running / MEV, across Cosmos-SDK, Other, EVM-Solidity. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.
Use the vulnerability class links below to compare these findings against the same bug class in other protocols.
What reviewers look for
- Logic error findings disclosed against SEDA Protocol
- Front-running / MEV findings disclosed against SEDA Protocol
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
SEDA Protocol: Tallying a Data Request with a wildcard expression in its consensus filter will store non-deterministic data and cause a chain halt
SEDA Protocol's Tally module evaluates a configurable consensus filter against each reveal in a data request during EndBlock processing. The filter is parsed as a JSONPath expression, and the supported wildcard form returns matching elements in a non-deterministic order while only the first element is consumed. Because each validator independently derives a different 0th element from identical reveals, they compute divergent outlier/consensus flags and persist mutually inconsistent data results into the batching store. This per-validator state divergence breaks the state root consensus and halts the chain. The bug was acknowledged and fixed in a protocol PR by sorting the GetNodes output before selecting the first element.
SEDA Protocol: Anyone can post a request with `gasPrice` of 0 to cause SEDA chain to halt
SEDA's Core contract accepts data requests without validating that gasPrice is non-zero, while its Tally module divides a proxy fee by that gasPrice when metering gas during endblock processing. Posting a request with gasPrice 0, replicationFactor 1, and no filters lets a single anonymous attacker reach the metering step after a validator commit-reveals it, triggering a division-by-zero that panics every validator processing the Tallying request. The resulting simultaneous validator crash halts the whole chain until remediated. The team fixed the flaw across the seda-chain, seda-chain-contracts, and seda-evm-contracts repositories.
SEDA Protocol: Anyone can crash validators with a Tally VM program that panics the call_result_write import
SEDA's Tally WASM VM exposes host imports that run in the validator node's process. The call_result_write import indexes into a zero-length default call_result_value without validating the user-supplied result_data_length, so a crafted Tally program can pass a length that exceeds the actual slice and trigger an out-of-bounds panic. Because Tally programs run during every validator's EndBlock processing, any unprivileged user can deploy such a program and post a data request referencing it, causing all validators that execute it to crash and halt the chain. This is a low-precondition, protocol-availability denial-of-service reachable by anyone on the network, with a fix already merged upstream.
SEDA Protocol: Anyone can pass any length to some Tally imports to inflate memory, induce OOM, and crash validators
SEDA's WASM Tally runtime exposed imports such as secp256k1_verify whose message, signature, and public-key length parameters were unbounded. A malicious Tally program passing maximum unsigned values for all three lengths forced each validator to allocate roughly 12GB of memory during the EndBlock tally phase. Because the gas charge for the call scaled only linearly and was priced fractions of a cent, an attacker could cheaply trigger out-of-memory crashes across validators and halt the chain. The finding was adjudicated high and fixed by limiting length parameters and/or increasing gas costs in the seda-wasm-vm repository.
SEDA Protocol: Chain can deadlock due to no consensus because New Validators can not submit vote extensions
SEDA's Cosmos-SDK ABCI handlers require a validator to hold an entry in the previous validator tree batch before that validator may sign vote extensions. A newly-joined validator therefore cannot submit vote extensions for one full block after entering the active set, even though its voting power is already counted in the aggregate total. If the combined power of such new validators exceeds one-third of total voting power, PrepareProposal and ProcessProposal can never reach the required two-thirds consensus on vote extensions, so every proposal fails validation and the chain halts regardless of which validator proposes. The protocol acknowledged the issue and the recommended fix is to exclude new validators from the TotalVotingPower denominator until they have a qualifying prior-batch entry.
SEDA Protocol: Malicious contracts can force excessive memory usage at minimal gas cost, threatening node stability and economic security
SEDA's WebAssembly data-oracle VM underbills gas for memory growth because the metering code multiplies the Wasm memory index (almost always 0) rather than the dynamic page count from the stack. Since nearly every module uses a single memory segment, most memory.grow operations are charged only the fixed base fee regardless of how many pages (tens of megabytes) are actually allocated. An attacker can therefore deploy Wasm contracts that grow memory hundreds of pages per call at negligible cost and repeat this across nodes, degrading performance and risking out-of-memory crashes while breaking the protocol's resource-accounting economics. Sherlock adjudicated it medium severity and the fix was merged in sedaprotocol/seda-wasm-vm PR #59.
All reports in this group
- SEDA Protocol: Attackers can flood solvers with thousands of requests and prevent fee payoutsLogic error$0
- SEDA Protocol: ExecuteTallyVM has a memory leak which will lead to nodes eventually crashingLogic error$0
- SEDA Protocol: Mean-Based Outlier Detection Vulnerability Allows Single Node to Sabotage ConsensusLogic error$0
- SEDA Protocol: Data requests queue can be DoS'edLogic error$0
- SEDA Protocol: Attacker can exploits batch sender role to block result Submissions via fee transfer reversionLogic error$0
- SEDA Protocol: Gas costs are severely underpriced for certain WASM instructions which can lead to network DoSLogic error$0
- SEDA Protocol: Attackers can flood validators with Commit/Reveal execution messages to delay blocks or DOS the nodeLogic error$0
- SEDA Protocol: requestId has no unique parameters leading to different collisionsLogic error$0
- SEDA Protocol: Wrong amount of gas will be used in a certain caseLogic error$0
- SEDA Protocol: Tally VM startup costs not charged early enoughLogic error$0
- SEDA Protocol: Malicious proposer can submit a request with large invalid transactions because of no mempool to bloat the block storeLogic error$0
- SEDA Protocol: A request poster can set gas_price to 1 and pay minimal fees for a lot of gas and drain validators' resourcesLogic error$0
- SEDA Protocol: WASI imports can be exploited for unmetered execution or unbounded memory growthLogic error$0
- SEDA Protocol: Executors will get underpaid while excessive gas will be refunded to the requestorLogic error$0
- SEDA Protocol: The outlier gets the reduced payout when there is consensus on errorsLogic error$0
- SEDA Protocol: Malicious validators will bypass consensus threshold requirements affecting the integrity of the SEDA protocol's cross-chain data verification systemLogic error$0
- SEDA Protocol: Signatures for the first batch will be rejected by VerifyVoteExtensionHandlerLogic error$0
- SEDA Protocol: Validators will not be able to sign first batchLogic error$0
- SEDA Protocol: Attacker can front-run Withdraw and steal the withdrawalFront-running / MEV$0
- SEDA Protocol: A jailed validator with no registered key blocks proving scheme activationLogic error$0
- SEDA Protocol: Anyone can front-run the creation of a vesting account to block itFront-running / MEV$0
- SEDA Protocol: `call_result_write` import can be exploited for unmetered execution and memory growthLogic error$0