Tapioca — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Tapioca, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 47
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 47 closed, publicly disclosed Tapioca 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, Access control, Front-running / MEV, Bridge exploit, Price manipulation, 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
- Logic error findings disclosed against Tapioca
- Access control findings disclosed against Tapioca
- Front-running / MEV findings disclosed against Tapioca
- Bridge exploit findings disclosed against Tapioca
- Price manipulation findings disclosed against Tapioca
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Tapioca: User Can Claim More Than totalAmount Due to Lack of Max Return Amount Check in _vested Function
Tapioca's Vesting contract has an accounting defect in its `_vested` function: the initial-unlock time offset is subtracted from the vesting start before computing the linearly vested amount, and the partial-vesting branch is never clamped to the total allocation. Because the offset shifts the linear curve forward, the computed vested value can overshoot `_totalAmount` before the fully-vested branch is reached, letting a beneficiary claim more than the total vest. The reporter's Foundry PoC shows that a 500,000-token vest with a 50,000 initial unlock lets a user claim roughly 549,000 tokens (~49,000 above the total) by claiming just before the nominal duration expires. This is a pure arithmetic edge-case flaw rather than a reentrancy or access-control issue.
Tapioca: DoS in BBLeverage and SGLLeverage due to using wrong leverage executor interface
Tapioca's leverage modules BBLeverage and SGLLeverage call their leverageExecutor contract through an interface that does not match the executor's actual function signatures. The modules invoke getAsset() and getCollateral() with six arguments, but BaseLeverageExecutor — the base contract for all leverage executors — exposes those functions with only four parameters. Because the extra arguments force the calls to decode against selectors and calldata the executor cannot interpret, every buyCollateral() and sellCollateral() transaction always reverts, permanently disabling the leverage buy/sell functionality across both the BigBang lending and Singularity vault markets. The issue was found independently by five researchers, adjudicated as a medium-severity DoS, and fixed by updating the interfaces to pass the correct parameter sets.
Tapioca: Balancer using safeApprove may lead to revert.
Tapioca's Balancer._routerSwap() approves the Stargate router for an amount using OpenZeppelin's safeApprove but never clears the allowance afterward. Because Stargate's router rounds the transferred amount down by the source pool's convertRate (1e12 for the DAI pool), the approved allowance typically exceeds the actual transfer, leaving a positive residual. Since safeApprove reverts when changing one non-zero allowance to another nonzero value, any later swap through the function permanently DoSs the cross-chain swap path for that token.
Tapioca: `getCollateral` and `getAsset` functions of the AssetTotsDaiLeverageExecutor contract decode data incorrectly
In Tapioca's AssetTotsDaiLeverageExecutor, the getCollateral and getAsset entry points decode a caller-supplied payload into an SLeverageSwapData struct and forward only the inner swapperData bytes to the internal _swapAndTransferToSender helper. That helper abi-decodes the received bytes again as another full SLeverageSwapData, so the payload is reinterpreted with misaligned layout. The redundant decode causes the leverage operations to revert rather than execute their swaps. The protocol team confirmed the bug and fixed it by having the executor pass data through unchanged, mirroring SimpleLeverageExecutor, disabling the asset-to-sDAI leverage path until patched.
Tapioca: TOFTOptionsReceiverModule will have the user lose the whole output TAP when requested to exercise all eligible options
Tapioca's TOFTOptionsReceiverModule, which forwards the TAP proceeds of exercised option positions back to users, silently loses the entire award when a user exercises with `_options.tapAmount = 0`. This zero value is the standard way to request exercising the full eligible oTAP position, and TapiocaOptionBroker honors it by minting the full TAP payout to the module as payer; however, the module computes the user's outgoing transfer from the raw caller-supplied tapAmount rather than the realized balance change, so it forwards nothing. Because the eligible amount is consumed by the full exercise, the awarded TAP remains permanently frozen on the module balance with no rescue path. The confirmed high-severity Sherlock finding was patched in Tapioca-bar PR #366 and TapiocaZ PR #183.
Tapioca: BBLiquidation::_liquidateUser liquidator can bypass protocol fee on liquidation by returning returnedShare == borrowShare
Tapioca's BigBang and Singularity lending markets grant the full seized collateral, including the liquidation bonus, to the liquidator during the collateral-to-asset swap, and only compute the liquidator's callerShare and the protocol fee from the surplus the liquidator returns afterward. Because that surplus is the entire basis for both fees, a liquidator can return exactly the borrow amount, zeroing the protocol fee while keeping the full bonus captured during the swap. This requires no special precondition and works on any liquidation, so the protocol loses its share of the bonus (at least 10%, up to 20% worst case) on every such liquidation. Sherlock adjudicated it High severity with duplicates after an accepted escalation, and Tapioca fixed it in the referenced pull request.
All reports in this group
- Tapioca: Multiple contracts cannot be pausedAccess control$0
- Tapioca: Composing approval with other messages is subject to DoSFront-running / MEV$0
- Tapioca: USDO’s MSG_TAP_EXERCISE compose messages where exercised options must be withdrawn to another chain will always fail due to wrongly requiring sendParam's to address to be whitelisted in the ClusterBridge exploit$0
- Tapioca: `mTOFT` can be forced to receive the wrong ERC20 leading to token lockupAccess control$0
- Tapioca: `_computeClosingFactor` function will return incorrect values, lower than needed, because it uses `collateralizationRate` to calculate the denominatorLogic error$0
- Tapioca: Penrose::_depositFeesToTwTap can unexpectedly revert due to amount rounded downLogic error$0
- Tapioca: BBLiquidation/SGLLiquidation::_updateBorrowAndCollateralShare liquidator can bypass bad debt handling to ensure whole liquidation rewardLogic error$0
- Tapioca: Allowances is double spent in BBLeverage's and SGLLeverage's `sellCollateral()`Logic error$0
- Tapioca: Balancer rebalance operation is permanently blocked whenever owner assigns `rebalancer` role to some other addressAccess control$0
- Tapioca: All ETH can be stolen during rebalancing for `mTOFTs` that hold nativeBridge exploit$0
- Tapioca: The repaying action in `BBLeverage.sellCollateral` function pulls YieldBox shares of asset from wrong addressLogic error$0
- Tapioca: Singularity::removeAsset share can become zero due to rounding down, and any user can be extracted some amount of assetLogic error$0
- Tapioca: Not properly tracking debt accrual leads mintOpenInterestDebt() to lose twTap rewardsLogic error$0
- Tapioca: Unupdated totalBorrow After BigBang LiquidationLogic error$0
- Tapioca: Wrong parameter in remote transfer makes it possible to steal all USDO balance from usersLogic error$0
- Tapioca: Gas parameters for Stargate swap are hardcoded leading to stuck messagesLogic error$0
- Tapioca: Incorrect `tapOft` Amounts Will Be Sent to Desired Chains on Certain ConditionsLogic error$0
- Tapioca: Liquidation fees are permanently frozen on Penrose YB accountLogic error$0
- Tapioca: Operation residual is lost for the user of BBLeverage's and SGLLeverage's `sellCollateral()`Logic error$0
- Tapioca: Not considering fees when wrapping mtOFTs leads to DoS in leverage executorsLogic error$0
- Tapioca: Secondary Big Bang market rates can be manipulated due to not triggering penrose.reAccrueBigBangMarkets(); when leveragingPrice manipulation$0
- Tapioca: buyCollateral() does not work properlyLogic error$0
- Tapioca: Unprotected `executeModule` function allows to steal the tokensAccess control$0
- Tapioca: SGL and BB repay do not round up both on allowance spending and elastic amountInteger overflow/underflow$0
- Tapioca: StargateRouter cannot send payloads and rebalancing of ERC20s is brokenAccess control$0
- Tapioca: Unpausing with accrue timestamp reset can remove the accrual between last recorded accrue time and pausing timeLogic error$0
- Tapioca: Malicious MarketHelper contract can be used in TOFTMarketReceiverModule's leverageUpReceiver and marketRemoveCollateralReceiver functionsLogic error$0
- Tapioca: BBCommon::_accrue wrong value is used to prevent overflowInteger overflow/underflow$0
- Tapioca: Unverified `_srcChainSender` parameter allows to impersonate the senderBridge exploit$0
- Tapioca: `leverageAmount` is incorrect in `SGLLeverage.sellCollateral` function due to calculation based on the new states of YieldBox after withdrawalLogic error$0
- Tapioca: BBLeverage::sellCollateral is unusable due to wrong asset deposit attempt in YieldBoxLogic error$0
- Tapioca: Leverage borrowing with stale rate can atomically create bad debt with no prior positions and no investmentOracle manipulation$0
- Tapioca: Stargate Pools conversion rate leads to token accumulation inside the Balancer contractLogic error$0
- Tapioca: Variable opening fee will always be wrongly computed if collateral is not a stablecoinLogic error$0
- Tapioca: TOFTOptionsReceiverModule miss cross-chain transformation for deposit and lock amountsLogic error$0
- Tapioca: Underflow Vulnerability in `Market::_allowedBorrow` Function: Oversight with Pearlmit Allowance HandlingInteger overflow/underflow$0
- Tapioca: BBLeverage's and SGLLeverage's `buyCollateral()` remove the required funds from the target twiceLogic error$0
- Tapioca: exerciseOptionsReceiver() Lack of Ownership Check for oTAP, Allowing Anyone to Use oTAPTokenIDAccess control$0
- Tapioca: TOFTOptionsReceiverModule's and UsdoOptionReceiverModule's exerciseOptionsReceiver can lose the option payment providedLogic error$0
- Tapioca: Withdrawing to other chain when exercising options won’t work as expected, leading to DoSBridge exploit$0
- Tapioca: mTOFTReceiver MSG_XCHAIN_LEND_XCHAIN_LOCK unable to executeGovernance attack$0