Tapioca DAO — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Tapioca DAO, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 55
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 55 closed, publicly disclosed Tapioca DAO 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 Governance attack, Integer overflow / underflow, Flash loan attack, Reentrancy, Bridge exploit, across EVM-Solidity, Move. 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
- Governance attack findings disclosed against Tapioca DAO
- Integer overflow / underflow findings disclosed against Tapioca DAO
- Flash loan attack findings disclosed against Tapioca DAO
- Reentrancy findings disclosed against Tapioca DAO
- Bridge exploit findings disclosed against Tapioca DAO
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Tapioca DAO: TOFT `exerciseOption` can be used to steal all underlying erc20 tokens
A critical input validation flaw in Tapioca DAO's BaseTOFT contract allows an attacker to steal all underlying ERC20 tokens stored within the wrapper. When executing cross-chain option redemptions via `exerciseOption` and `exerciseInternal`, parameters controlling the output token address (`tapSendData.tapOftAddress`) and transfer amount are unvalidated. An attacker can pass arbitrary data, bypass validation checks, and force the BaseTOFT contract to execute `safeTransfer` of its entire underlying ERC20 balance directly to the attacker's address.
Tapioca DAO: Incorrect formula used in function `Market.computeClosingFactor()`
A math logic bug in Tapioca DAO's lending market module causes liquidations to compute incorrect debt closing factors for under-collateralized accounts. The `Market.computeClosingFactor()` function improperly uses raw base debt shares (`borrowPart`) instead of rebased elastic debt amounts (`userElastic`) while applying incorrect decimal scaling factors that lead to arithmetic underflows. When liquidators trigger `BigBang._liquidateUser()`, the inaccurate closing factor adjusts position collateral and debt shares incorrectly, preventing under-collateralized positions from reaching target solvency and risking protocol bad debt.
Tapioca DAO: Overflow risk in Market contract
A high-severity integer overflow vulnerability was identified in Tapioca DAO's Market contract during solvency evaluations. When executing routine operations such as borrowing or removing collateral, the protocol scaled collateral shares by several large constants before passing them to `YieldBox.toAmount()`. Inside `YieldBoxRebase._toAmount()`, multiplying these pre-scaled shares by `totalAmount` exceeded uint256 limits whenever standard 18-decimal token amounts were processed. This forced arithmetic reverts across market interactions, effectively freezing protocol actions and locking user funds.
Tapioca DAO: Attacker can specify any `receiver` in `USD0.flashLoan()` to drain `receiver` balance
A logic flaw in Tapioca DAO's `USD0` contract allowed callers to execute flash loans by specifying an arbitrary `receiver` address without verifying authorization. The contract incorrectly checked whether the `receiver` had granted token allowance to the `USD0` contract itself rather than to `msg.sender`. Because users frequently grant allowances to token contracts, an attacker could specify any user holding `USD0` as the receiver, causing the protocol to burn flash loan fees directly from the victim's account balance.
Tapioca DAO: `LidoEthStrategy._currentBalance` is subject to price manipulation, allows overborrowing and liquidations
In Tapioca DAO's `LidoEthStrategy`, the `_currentBalance()` function determines the native asset value of held `stETH` by directly querying spot balances from Curve's `get_dy` function. Because AMM spot queries can be drastically altered in a single transaction using large swaps, the valuation of strategy reserves is vulnerable to price manipulation. An attacker can manipulate pool reserves upward to over-borrow and render the lending market insolvent, or manipulate them downward to trigger unfair liquidations on depositors.
Tapioca DAO: Ability to steal user funds and increase collateral share infinitely in BigBang and Singularity
A critical authorization bypass vulnerability in Tapioca DAO's BigBang and Singularity lending contracts allowed unauthorized users to transfer collateral shares from victim accounts. The `addCollateral` function checked user allowances using the `allowedBorrow` modifier against the caller-provided `share` parameter before converting the `amount` parameter into actual shares. By passing `share = 0` with a non-zero `amount`, an attacker could pass the allowance check unconditionally. The contract would then calculate the actual share amount and transfer tokens out of any user's YieldBox balance who had approved the market, enabling full theft of approved user collateral and unbacked borrowing of USDO.
All reports in this group
- Tapioca DAO: All assets of (m)TapiocaOFT can be stealed by depositing to strategy cross chain call with 1 amount but maximum shares possibleBridge exploit$0
- Tapioca DAO: Incorrect solvency check because it multiplies collateralizationRate by share not amount when calculating liquidation thresholdInteger overflow/underflow$0
- Tapioca DAO: TOFT `removeCollateral` can be used to steal all the balanceBridge exploit$0
- Tapioca DAO: Not enough TAP tokens to exercise if a user participates and exercises in the same epochGovernance attack$0
- Tapioca DAO: `twTAP.participate()` can be permanently frozen due to lack of access control on host-chain-only operationsAccess control$0
- Tapioca DAO: triggerSendFrom() will send all the ETH in the destination chain where sendFrom() is called to the refundAddress in the LzCallParams argumentGovernance attack$0
- Tapioca DAO: User's assets can be stolen when removing them from the Singularity market through the Magnetar contractOracle manipulation$0
- Tapioca DAO: CompoundStrategy attempts to transfer out a greater amount of ETH than will actually be withdrawn, leading to DoSReentrancy$0
- Tapioca DAO: `SGLLiquidation::_computeAssetAmountToSolvency`, `Market::_isSolvent` and `Market::_computeMaxBorrowableAmount` may overestimate the collateral, resulting in false solvencyGovernance attack$0
- Tapioca DAO: `_sendToken` implementation in `Balancer.sol` is wrong which will make the underlying erc20 be send to a random address and lostBridge exploit$0
- Tapioca DAO: twAML::participate - reentrancy via _safeMint can be used to brick reward distributionReentrancy$0
- Tapioca DAO: Collateral can be locked in BigBang contract when `debtStartPoint` is nonzeroGovernance attack$0
- Tapioca DAO: Exercise option cross chain message in the (m)TapiocaOFT will always revert in the destination, losing debited funds in the source chainGovernance attack$0
- Tapioca DAO: Usage of `BalancerStrategy.updateCache` will cause single sided Loss, discount to Depositor and to OverBorrow from SingularityReentrancy$0
- Tapioca DAO: TOFT `triggerSendFrom` can be used to steal all the balanceBridge exploit$0
- Tapioca DAO: Attacker can block LayerZero channel due to missing check of minimum gas passedBridge exploit$0
- Tapioca DAO: `_liquidateUser()` should not re-use the same minimum swap amount out for multiple liquidationGovernance attack$0
- Tapioca DAO: Refund mechanism for failed cross-chain transactions does not workBridge exploit$0
- Tapioca DAO: Incorrect liquidation reward computation causes excess liquidator rewards to be givenOracle manipulation$0
- Tapioca DAO: `BaseTOFT.sol`: `retrieveFromStrategy` can be used to manipulate other user's positions due to absent approval checkFront-running / MEV$0
- Tapioca DAO: Attacker can block LayerZero channel due to variable gas cost of saving payloadGovernance attack$0
- Tapioca DAO: `BaseTOFTLeverageModule.sol`: `leverageDownInternal` tries to burn tokens from wrong addressGovernance attack$0
- Tapioca DAO: `BaseTOFT.sol`: `removeCollateral` can be used to manipulate other user's positions and steal tokens due to absent approval checkFront-running / MEV$0
- Tapioca DAO: User can give himself approval for all assets held by `MagnetarV2` contractGovernance attack$0
- Tapioca DAO: TOFT and USDO Modules Can Be SelfdestructedGovernance attack$0
- Tapioca DAO: Attacker can steal victim's oTAP position contents via `MagnetarMarketModule#_exitPositionAndRemoveCollateral()`Governance attack$0
- Tapioca DAO: Rewards compounded in AaveStrategy are unredeemableGovernance attack$0
- Tapioca DAO: `AaveStrategy.sol`: Changing swapper breaks the contractAccess control$0
- Tapioca DAO: Magnetar contract has no approval checkingOracle manipulation$0
- Tapioca DAO: Accounted balance of GlpStrategy does not match withdrawable balance, allowing for attackers to steal unclaimed rewardsGovernance attack$0
- Tapioca DAO: Liquidation transactions can potentially fail for all marketsOracle manipulation$0
- Tapioca DAO: Attacker can pass duplicated reward token addresses to steal the reward of contract `twTAP.sol`Bridge exploit$0
- Tapioca DAO: `exitPosition` in `TapiocaOptionBroker` may incorrectly inflate position weightsGovernance attack$0
- Tapioca DAO: The amount of debt removed during `liquidation` may be worth more than the account's collateralOracle manipulation$0
- Tapioca DAO: TOFT in (m)TapiocaOft contracts can be stolen by calling removeCollateral() with a malicious removeParams.marketBridge exploit$0
- Tapioca DAO: `multiHopSellCollateral()` will fail due to call on an invalid market address causing bridged collateral to be locked upBridge exploit$0
- Tapioca DAO: Tokens can be stolen from other users who have approved MagnetarAccess control$0
- Tapioca DAO: Funds are locked because borrowFee is not correctly implemented in BigBangGovernance attack$0
- Tapioca DAO: A user with a TapiocaOFT allowance >0 could steal all the underlying ERC20 tokens of the ownerGovernance attack$0
- Tapioca DAO: twTAP.claimAndSendRewards() will claim the wrong amount for each reward token due to the use of wrong indexGovernance attack$0
- Tapioca DAO: Anybody can buy collateral on behalf of other users without having any allowance using the multiHopBuyCollateral()Oracle manipulation$0
- Tapioca DAO: Potential 99.5% loss in `emergencyWithdraw()` of two Yieldbox strategiesFront-running / MEV$0
- Tapioca DAO: TOFT leverageDown always fails if TOFT is a wrapper for native tokensGovernance attack$0
- Tapioca DAO: Reentrancy in `USDO.flashLoan()`, enabling an attacker to borrow unlimited USDO exceeding the max borrow limitReentrancy$0
- Tapioca DAO: `twTAP.sol`: Reward tokens stored in index 0 can be stolenGovernance attack$0
- Tapioca DAO: `BalancerStrategy.sol`: `_withdraw` withdraws insufficient tokensGovernance attack$0
- Tapioca DAO: Attacker can prevent rewards from being issued to gauges for a given epoch in TapiocaOptionBrokerOracle manipulation$0
- Tapioca DAO: Lack of safety buffer between liquidation threshold and LTV ratio for borrowers to prevent unfair liquidationsGovernance attack$0
- Tapioca DAO: The BigBang contract take more fees than it shouldGovernance attack$0