Decent — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Decent, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 9
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 9 closed, publicly disclosed Decent 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 Bridge exploit, Access control, Logic error, across 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
- Bridge exploit findings disclosed against Decent
- Access control findings disclosed against Decent
- Logic error findings disclosed against Decent
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Decent: Permanent loss of tokens if swap data gets outdated
The Decent bridge adapter is susceptible to permanent fund loss when cross-chain swap data expires before execution. Because the StargateComposer architecture handles token transfers independently of the subsequent swap logic, failures during the swap step leave assets trapped in the adapter contract. The protocol currently lacks an error-handling mechanism to recover these funds, and the forced retry logic prevents users from updating the stale parameters, rendering the assets unrecoverable.
Decent: Potential loss of capital due to fixed fee calculations
The StargateBridgeAdapter in the Decent protocol incorrectly assumes a fixed fee when processing cross-chain transfers via Stargate. Stargate’s fee library can dynamically adjust fees based on network demand, often resulting in a larger amount of tokens being delivered to the destination chain than the protocol initially expected. Because the adapter only approves and uses the pre-calculated, smaller amount, the excess tokens remain stuck and unrecoverable in the adapter contract.
Decent: DecentEthRouter.sol#_bridgeWithPayload() - Any refunded ETH (native token) will be refunded to the DecentBridgeAdapter, making them stuck
The Decent protocol suffers from a critical logic flaw in its bridge implementation where surplus native gas tokens (ETH) provided by users are misdirected and permanently lost. During cross-chain transactions initiated via LayerZero, the DecentBridgeAdapter incorrectly sets its own contract address as the recipient for gas refunds. As a result, any excess ETH sent by users to cover gas fees is trapped within the protocol's adapter instead of being returned to the sender, leading to a persistent and unrecoverable loss of funds.
Decent: Missing access control on UTB:receiveFromBridge allows UTB swaps to be executed without spending bridge fees while bypassing fee/swap instruction signature verification
The Decent UTB contract exposes a public receiveFromBridge function that lacks the retrieveAndCollectFees modifier applied to the other public entry points (swapAndExecute and bridgeAndExecute). Because receiveFromBridge directly invokes the internal _swapAndExecute, any caller can trigger cross-chain swaps while skipping all fee collection and bypassing the validators' fee/swap-instruction signature verification performed in UTBFeeCollector.collectFees. The same path also permits arbitrary unsigned payloads to be executed through UTBExecutor.execute. This weakens the protocol's economic and authorization guarantees for bridge operations, since swaps execute without the intended fee and validator oversight.
Decent: Users will lose their cross-chain transaction if the destination router do not have enough WETH reserves.
Decent's DecentEthRouter contains a fallback branch in onOFTReceived that triggers whenever the destination router's WETH balance is below the incoming cross-chain dcntEth amount. In that branch the router transfers dcntEth directly to the payload's _to address rather than delivering WETH/ETH to the intended recipient. For transactions routed through the UTB bridge adapter, _to is always the destination bridge adapter, which has no mechanism to redeem the dcntEth or bridge it back, so user funds become permanently stranded whenever WETH reserves are depleted — a realistic scenario especially on non-Ethereum chains where inbound volume exceeds outbound. The sponsor confirmed the flaw while disputing severity, and the judge 0xsomeone upheld a high-risk rating for this and all duplicate findings.
Decent: Due to missing checks on minimum gas passed through LayerZero, executions can fail on the destination chain
The Decent bridge protocol is vulnerable to a denial-of-service attack on its cross-chain messaging channels due to insufficient validation of gas parameters. Users provide a _dstGasForCall value that is used, along with a hardcoded constant, to define the gas limit for LayerZero operations. Because the contract does not enforce a minimum gas threshold, malicious or incorrect user input can cause cross-chain transactions to fail with out-of-gas errors. These failed messages become stuck in a STORED state in LayerZero, which blocks the processing of all subsequent messages on that channel, effectively disabling cross-chain transfers.
All reports in this group
- Decent: Users can use the protocol freely without paying any fees by calling the `DecentEthRouter::bridgeWithPayload()` function directly.Access control$0
- Decent: Anyone can update the address of the Router in the DcntEth contract to any address they would like to set.Access control$0
- Decent: When `DecentBridgeExecutor.execute` fails, funds will be sent to a random addressAccess control$0