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
- 88
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 88 closed, publicly disclosed Tapioca DAO 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, Governance attack, Access control, Bridge exploit, Reentrancy, 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
- Logic error findings disclosed against Tapioca DAO
- Governance attack findings disclosed against Tapioca DAO
- Access control findings disclosed against Tapioca DAO
- Bridge exploit findings disclosed against Tapioca DAO
- Reentrancy 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: `depositRepayAndRemoveCollateralFromMarket` function of MagnetarAssetModule can't be used on behalf of user
Tapioca's Magnetar contract is designed to let whitelisted contracts, such as TOFT or USDT modules, execute operations on behalf of end users, typically when handling cross-chain lzReceive token deliveries. The delegation path is authorized via _checkSender(data.user), which permits a whitelisted caller to act for the user. However, in depositRepayAndRemoveCollateralFromMarket, the deposit tokens are pulled with _extractTokens(msg.sender, ...) rather than from data.user. As a result, a whitelisted caller operating for another user will have its own funds pulled for the deposit, or the call will revert for insufficient balance/allowance. The sponsor confirmed the issue and patched it in the tapioca-periph repository.
Tapioca DAO: anyone with a `Pearlmit` approval to transfer `TapToken` can have their funds stolen
Tapioca DAO's aTokenOFT TapToken inherited a transferFrom path in BaseTapiocaOmnichainEngine that falls back to Pearlmit's transferFromERC20 whenever the standard ERC20 allowance is insufficient. The flaw is that the Pearlmit call authenticates the spender against msg.sender, which during this fallback is the TapToken contract itself rather than the actual caller. Consequently any user who has granted TapToken a Pearlmit allowance for their TAP can have those approved funds drained by an arbitrary third party who simply calls transferFrom. The sponsor contested the finding as Low/Invalid, questioning context, though the reported logic gap reproduces under the accompanying PoC conditions.
Tapioca DAO: Options can be exercised preemptively due to timing delays
TapiocaOptionBroker's options exercise path enforces its one-epoch cooldown using wall-clock time (block.timestamp) while its gauge reward accounting (netDepositedForEpoch) is keyed to an epoch counter. A participant who joins at the very start of an epoch can wait the full EPOCH_DURATION and call exerciseOption before the epoch counter advances, satisfying the timestamp-based cooldown while rewards are still computed against the current epoch's deposit denominator. The user then collects the same epoch's gauge rewards they never earned, corrupting the netAmount accounting and draining the reward pool so that other legitimately owed depositors can no longer claim their yield. The recommended fix is to anchor the cooldown to the epoch boundary rather than the timestamp.
Tapioca DAO: `MagnetarMintXChainModule.sol`:`mintBBLendXChainSGL` can be used to manipulate user positions by abusing whitelist privileges
Tapioca's Magnetar module gates account operations through a _checkSender check that permits either the account owner or any address whitelisted by the cluster contract. In the cross-chain flow, the whitelisted USDO token relay executes lzcompose payloads that ultimately call Magnetar's depositYBLendSGLLockXchainTOLP on the destination chain. Because the source-chain mintBBLendXChainSGL never verifies that the compose-message data.user matches the initiating caller, an attacker can embed an arbitrary victim address into the payload and have whitelisted USDO perform deposits, lending and token extraction against that victim's market position. The impact is direct manipulation of any user's position once that user has approved the Magnetar contract. Tapioca confirmed the issue via a duplicate report and produced a periph repository fix commit.
Tapioca DAO: Incorrect math means `data.removeAndRepayData.removeAssetFromSGL` will never work once SGL has accrued interest
Tapioca's MagnetarOptionModule converts a user-desired withdrawal amount into a YieldBox share via toShare() and passes that value directly into Singularity's removeAsset(). Singularity's removeAsset does not treat that argument as a YieldBox share but as a fraction of the market's total assets, so the two interpretations only coincide at market creation. Once a Singularity market accrues any interest, its elastic base diverges from YieldBox share accounting and the remove path withdraws the wrong quantity or breaks entirely. The sponsor confirmed the finding through a duplicate report and supplied a fix commit; the intended correction is to use Singularity's unused getFractionForAmount helper to convert amounts into proper market fractions, while the practical impact is a broken user-facing removal function rather than direct fund theft.
Tapioca DAO: `AirdropBroker`: Airdrops in epoch 4 can participate and exercise options in subsequent epochs
Tapioca's AirdropBroker registers epoch-4 airdrop entitlements in the `phase4Users` mapping but never clears that mapping at the boundary of phase four's sub-epochs. Because eligibility persists, a user who skips participating in epoch 4 keeps their full `aoTAP` entitlement and can participate and exercise those epoch-4 options in a later epoch, on top of the unclaimed epoch-4 amount that already rolled into that later epoch's pot. The defect inflates the effective airdrop a user can draw past the amount the protocol allocated to them and distorts the epoch distribution economics for the remaining twTAP lockers.
All reports in this group
- Tapioca DAO: A single second in an epoch makes an user eligible for the entire epoch's rewardsLogic error$0
- Tapioca DAO: Incorrect decoding in `decodeLockTwpTapDstMsg`Logic error$0
- Tapioca DAO: Magnetar unwrap operations broken due to bad ownership and checksLogic error$0
- Tapioca DAO: Adversary can steal user's NFT's if they have set Magnetar as `isApprovedForAll == true`Access control$0
- Tapioca DAO: `burst()` does not return eth when action failsLogic error$0
- Tapioca DAO: Funds can be stolen through remote transfer functionalityAccess control$0
- Tapioca DAO: `TapiocaOptionBroker.participate()` with the approve authorization, it still cannot be executedLogic error$0
- Tapioca DAO: Gov (`twTAP`) and Tapioca Option can be monopolized by an attackerGovernance attack$0
- Tapioca DAO: Incorrect return value of function `BaseTapiocaOmnichainEngine._payNative()`Bridge exploit$0
- Tapioca DAO: Adversary can utilise approved to Magnetar `oTAP` and `tOLP` NFTsAccess control$0
- Tapioca DAO: Absence of restrictions on the sender of the `twTAP.claimsReward()` function could enable attackers to freeze reward tokens within the Tap token contractLogic error$0
- Tapioca DAO: `AirdropBroker`: When `block.timestamp == lastEpochUpdate + EPOCH_DURATION`, users can exercise options in the new epoch.Logic error$0
- Tapioca DAO: `_vested()` claimable amount calculation errorLogic error$0
- Tapioca DAO: Magnetar's `mintBBLendSGLLockTOLP` reverts when `lock` is set to falseLogic error$0
- Tapioca DAO: `twAML` weights can be griefed by burning tokensGovernance attack$0
- Tapioca DAO: `depositYBLendSGLLockXchainTOLP` function of the MagnetarAssetXChainModule will not work because it transfers Singularity tokens to the user before `_withdrawToChain`Logic error$0
- Tapioca DAO: `_lockOnTOB` function of MagnetarMintCommonModule will not work due to the missing approved asset for YieldBox before depositingLogic error$0
- Tapioca DAO: `MagnetarMintXChainModule` will not work as msg type is not allowedLogic error$0
- Tapioca DAO: Incorrect approval mechanism breaks all Magnetar functionalityLogic error$0
- Tapioca DAO: After `unregisterSingularity()`, position has not been unlocked and will be locked in the contractLogic error$0
- Tapioca DAO: Missing check on helper contract allows arbitrary actions and theft of assetsAccess control$0
- Tapioca DAO: `IMarket.execute.selector`, `_checkSender` bypass allows to execute arbitrary operationsAccess control$0
- Tapioca DAO: `_internalRemoteTransferSendPacket()` can't send the difference back to the userLogic error$0
- Tapioca DAO: Layerzero fee refund address is not handled correctlyLogic error$0
- Tapioca DAO: Adversary can steal approved `tOLP`s to Magnetar via `_paricipateOnTOLP`Logic error$0
- Tapioca DAO: Rescue request timestamp not reset in `TapiocaOptionLiquidityProvision.sol` contractLogic error$0
- Tapioca DAO: Max magnitude lock check will lead to a DoS and possible monopolization of `gov/Option` on `twTAP`/`TapiocaOptionBroker`Governance attack$0
- Tapioca DAO: TOFT in (m)TapiocaOft contracts can be stolen by calling removeCollateral() with a malicious removeParams.marketBridge exploit$0
- Tapioca DAO: Attacker can block LayerZero channel due to variable gas cost of saving payloadGovernance attack$0
- Tapioca DAO: `AaveStrategy.sol`: Changing swapper breaks the contractAccess control$0
- Tapioca DAO: User can give himself approval for all assets held by `MagnetarV2` contractGovernance attack$0
- Tapioca DAO: CompoundStrategy attempts to transfer out a greater amount of ETH than will actually be withdrawn, leading to DoSReentrancy$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: Attacker can specify any `receiver` in `USD0.flashLoan()` to drain `receiver` balanceFlash loan 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: Ability to steal user funds and increase collateral share infinitely in BigBang and SingularityGovernance attack$0
- Tapioca DAO: Lack of safety buffer between liquidation threshold and LTV ratio for borrowers to prevent unfair liquidationsGovernance attack$0
- Tapioca DAO: Liquidation transactions can potentially fail for all marketsOracle manipulation$0
- Tapioca DAO: Not enough TAP tokens to exercise if a user participates and exercises in the same epochGovernance attack$0
- Tapioca DAO: Attacker can block LayerZero channel due to missing check of minimum gas passedBridge exploit$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: Reentrancy in `USDO.flashLoan()`, enabling an attacker to borrow unlimited USDO exceeding the max borrow limitReentrancy$0
- Tapioca DAO: `twTAP.participate()` can be permanently frozen due to lack of access control on host-chain-only operationsAccess control$0
- Tapioca DAO: `BalancerStrategy.sol`: `_withdraw` withdraws insufficient tokensGovernance attack$0
- Tapioca DAO: TOFT leverageDown always fails if TOFT is a wrapper for native tokensGovernance attack$0
- Tapioca DAO: Potential 99.5% loss in `emergencyWithdraw()` of two Yieldbox strategiesFront-running / MEV$0
- Tapioca DAO: The amount of debt removed during `liquidation` may be worth more than the account's collateralOracle manipulation$0
- Tapioca DAO: TOFT `exerciseOption` can be used to steal all underlying erc20 tokensGovernance attack$0
- Tapioca DAO: The BigBang contract take more fees than it shouldGovernance attack$0
- Tapioca DAO: TOFT and USDO Modules Can Be SelfdestructedGovernance attack$0
- Tapioca DAO: Collateral can be locked in BigBang contract when `debtStartPoint` is nonzeroGovernance 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: `exitPosition` in `TapiocaOptionBroker` may incorrectly inflate position weightsGovernance attack$0
- Tapioca DAO: Refund mechanism for failed cross-chain transactions does not workBridge exploit$0
- Tapioca DAO: Usage of `BalancerStrategy.updateCache` will cause single sided Loss, discount to Depositor and to OverBorrow from SingularityReentrancy$0
- Tapioca DAO: `LidoEthStrategy._currentBalance` is subject to price manipulation, allows overborrowing and liquidationsReentrancy$0
- Tapioca DAO: User's assets can be stolen when removing them from the Singularity market through the Magnetar contractOracle manipulation$0
- Tapioca DAO: TOFT `removeCollateral` can be used to steal all the balanceBridge exploit$0
- Tapioca DAO: Attacker can prevent rewards from being issued to gauges for a given epoch in TapiocaOptionBrokerOracle manipulation$0
- Tapioca DAO: A user with a TapiocaOFT allowance >0 could steal all the underlying ERC20 tokens of the ownerGovernance 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: `twTAP.sol`: Reward tokens stored in index 0 can be stolenGovernance attack$0
- Tapioca DAO: Overflow risk in Market contractInteger overflow/underflow$0
- 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: `multiHopSellCollateral()` will fail due to call on an invalid market address causing bridged collateral to be locked upBridge exploit$0
- Tapioca DAO: `SGLLiquidation::_computeAssetAmountToSolvency`, `Market::_isSolvent` and `Market::_computeMaxBorrowableAmount` may overestimate the collateral, resulting in false solvencyGovernance attack$0
- Tapioca DAO: Rewards compounded in AaveStrategy are unredeemableGovernance attack$0
- Tapioca DAO: TOFT `triggerSendFrom` can be used to steal all the balanceBridge exploit$0
- Tapioca DAO: Attacker can steal victim's oTAP position contents via `MagnetarMarketModule#_exitPositionAndRemoveCollateral()`Governance attack$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: 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: Attacker can pass duplicated reward token addresses to steal the reward of contract `twTAP.sol`Bridge exploit$0
- Tapioca DAO: Magnetar contract has no approval checkingOracle manipulation$0
- Tapioca DAO: `_liquidateUser()` should not re-use the same minimum swap amount out for multiple liquidationGovernance attack$0
- Tapioca DAO: Funds are locked because borrowFee is not correctly implemented in BigBangGovernance attack$0
- Tapioca DAO: Accounted balance of GlpStrategy does not match withdrawable balance, allowing for attackers to steal unclaimed rewardsGovernance attack$0
- Tapioca DAO: Incorrect solvency check because it multiplies collateralizationRate by share not amount when calculating liquidation thresholdInteger overflow/underflow$0
- Tapioca DAO: Incorrect formula used in function `Market.computeClosingFactor()`Integer overflow/underflow$0
- Tapioca DAO: Tokens can be stolen from other users who have approved MagnetarAccess control$0
- Tapioca DAO: twAML::participate - reentrancy via _safeMint can be used to brick reward distributionReentrancy$0