DODO Cross-Chain DEX — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for DODO Cross-Chain DEX, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 6
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 6 closed, publicly disclosed DODO Cross-Chain DEX reports indexed on Coin Buggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Logic error, Bridge exploit, Access control, across EVM-Solidity, Solana-Rust. 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 DODO Cross-Chain DEX
- Bridge exploit findings disclosed against DODO Cross-Chain DEX
- Access control findings disclosed against DODO Cross-Chain DEX
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
DODO Cross-Chain DEX: Wrong encoding of `BTC` receiver in revert options
In DODO's cross-chain gateway, when a user withdraws zBTC back to a native Bitcoin address, the contract casts the receiver from a bytes payload to 20 bytes when constructing the revert options. Bitcoin addresses (bech32) are longer than 20 bytes, so this truncation corrupts the refund address. If the cross-chain transfer fails and onRevert is triggered, user refunds get sent to a wrong, uncontrolled address, causing permanent loss of funds. The protocol team acknowledged and fixed the issue in a subsequent PR by concatenating the full sender bytes instead of the truncated cast.
DODO Cross-Chain DEX: Executing withdrawToNativeChain with Zeta as fromToken will not be possible
This Sherlock finding documents a logic error in DODO's cross-chain gateway on ZetaChain. When a user calls withdrawToNativeChain to swap ZETA (the native token) into a ZRC20, the fee is paid out of msg.value, but the full undeducted msg.value is forwarded to mixSwap. Because mixSwap's _deposit requires msg.value to exactly equal the fromTokenAmount (the ETH_VALUE_WRONG check), the mismatch causes the swap to revert whenever a non-zero transfer fee is configured, permanently blocking ZETA-to-ZRC20 swaps. The fix is to pass msg.value minus the fee to mixSwap.
DODO Cross-Chain DEX: Any attacker will steal accumulated ZRC20 tokens from `GatewayTransferNative` contract
DODO's cross-chain gateway on ZetaChain lets users withdraw native tokens by passing the internal native-token placeholder as the ZRC20 address, which skips the transferFrom allowance check. Because the function never validates that msg.value covers the claimed amount, an attacker can call withdrawToNativeChain{value:0} using the placeholder while embedding a real ZRC20 address inside the cross-chain message. The message decoding then routes the withdrawal to the real token contract, draining the gateway's accumulated ZRC20 balances and sending native USDC (or equivalent) to addresses the attacker controls. The protocol team acknowledged and fixed the issue in a follow-up PR adding proper native token amount validation.
DODO Cross-Chain DEX: Attacker can steal an high-value token due to lack of swap execution
The DODO Cross-Chain DEX GatewayTransferNative contract lets users withdraw funds across chains. When a user supplies empty swap data but requests a target token that differs from the deposited ZRC20 token, the `_doMixSwap` helper executes an unconditional early return and sends the full original amount to the mismatched destination token. An attacker can therefore deposit a low-value ZRC20 (e.g., AVAX) and receive a high-value ZRC20 (e.g., ETH.ARB) at a 1:1 wei ratio, draining the high-value balances the contract holds. The Sherman protocol team acknowledged and fixed the issue in a follow-up PR, and the same flaw exists in GatewayCrossChain.
DODO Cross-Chain DEX: Bug in AccountEncoder causes wrong Solana account permissions
DODO's cross-chain bridge compresses Solana account permissions into a byte array in its EVM-side AccountEncoder library. The decompressAccounts() assembly routine reads a full 32-byte word with mload when parsing what should be a single 1-byte isWritable boolean, so the boolean evaluation consumes the boolean plus the first 31 bytes of the next account's public key. Because public keys are essentially always non-zero, every boolean collapses to true, marking all accounts writable regardless of user intent. This silently corrupts permission data for every multi-account Solana bridge transaction, expanding the attack surface where Solana programs may modify accounts users expected to be read-only. The finding was confirmed, rated medium (M-4), and fixed by extracting only the first byte via shr(248, ...).
DODO Cross-Chain DEX: `GatewayTransferNative.withdrawToNativeChain` Allows Swapping Arbitrary Contract ZRC20s by Misusing Deposited Token Amount
GatewayTransferNative.withdrawToNativeChain lets a user supply arbitrary DODO swap parameters inside the message payload but never verifies that the swap's input token matches the ZRC20 token actually deposited. Because _doMixSwap approves the contract's own balance of the requested fromToken up to the deposited amount, an attacker depositing a low-value token can instruct the contract to swap away valuable native ZRC20 it holds as refunds or fees. The attacker receives the swapped proceeds on the destination chain, draining the gateway's accumulated token balance while only sacrificing a cheap deposit.