High
Solo
Total
Medium
Solo
Total
Total Earnings
#21 All Time
Payouts
1st Places
2nd Places
3rd Places
All
Sherlock
Code4rena
Cantina
Immunefi
Feb '25
Collaborative Audit • Sherlock • 0x73696d616f
Jan '25
Findings not publicly available for private contests.
Dec '24
high
`totalCdsDepositedAmountWithOptionFees` is incorrectly reduced in `CDSLib::withdrawUser()`, leading to stuck option fees
high
`treasury.updateYieldsFromLiquidatedLrts()` updates the yield in the current chain, but collateral may be in the other chain
high
Borrower withdrawing at a loss will cause losses for cds depositors that only withdraw after the price recovers
high
Total cds deposited amount is incorrectly modified when cds depositor is at a loss, leading to stuck USDa
high
Nonce is not stored in `CDS:withdraw()`, allowing `excessProfitCumulativeValue` signatures to be reused
high
Cds withdrawer can steal other user/delay submitting`excessProfitCumulativeValue` due to missing signing info
high
Cds depositors profit up to the strike price is not redeemable as the total cds deposited amount is not increased
high
Cds depositor profit is never taxed as the tax is only applied on the option fees
high
Type 1 borrower liquidation will incorrectly add cds profit directly to `totalCdsDepositedAmount`
high
Mismatch between liquidation amount and total available reduction will lead to stuck collateral on liquidations
high
Liquidation profit is never given to cds depositors who will take these losses
high
`borrowing::withdraw()` at a loss will increase downside protected and misscalculate option fees
high
Cds amounts to reduce from each chain are incorrect and will lead to the inability to withdraw cds in one of the chains
high
Concurrency issues will overwrite omnichainData and users will not be able to withdraw
high
`borrowing::liquidate()` sends the wrong liquidation index to the destination chain, overwritting liquidation information and getting collateral stuck
high
Malicious user can call `borrowing::calculateCumulativeRate()` any number of times to inflate debt rate as `lastEventTime` is not updated
high
`CDS::updateDownsideProtected()` is missing access control, allowing anyone to increase `downsideProtected` and DoS cds withdrawals, making funds stuck
high
`Treasury::totalInterestFromLiquidation` can not be withdrawn
high
`strikePrice` is not validated on `borrowing::depositTokens()` and can be sent as the same price as the deposit to exploit
high
Missing downside protection as the borrower always has to pay the full USDa amount
high
Late abond holders steal USDa amount from liquidations from earlier abond holders
high
`BorrowLib::redeemYields()` burns abond from `msg.sender` but calculates yield from `user`, leading to exploits
high
`CDSLib::withdrawUserWhoNotOptedForLiq()` tax is not stored in the treasury
high
Borrower deposit, withdraw, deposit will reinit `omniChainData.cdsPoolValue`, getting profit stuck for cds depositors
high
`omniChainData.totalAvailableLiquidationAmount` is never reduced on cds withdrawal, leading to stuck collateral
high
Liquidation will reduce total cds deposited amount, leading to incorrect option fees
medium
Accumulated profit/losses by the cumulative value is not dealt with in `borrowingLiquidation::liquidationType1()`, leading to losses
medium
Malicious user will inflate/deflate `previousData.cdsPoolValue` as it pleases, DoSing withdrawals or bypassing 20% ratio
medium
`borrowing::calculateCumulativeRate()` is called after the deposit/withdrawal, leading to incorrect debt amounts
medium
`borrowing::_getDownsideFromCDS()` does not update downside protected on the amount available, DoSing withdrawals
medium
`borrowLiquidation::liquidationType1()` fails for 100% LTV value
medium
Interest generated by last bond will not go to anyone when liquidating as there is no bond amount to collect it
medium
Interest generated from bonds deposited into external protocol is not accounted for correctly and will be stuck
medium
`GlobalVariables::oftOrCollateralReceiveFromOtherChains()` calculates the fee as if it was the same in both chains, which is false
medium
`GlobalVariables::oftOrCollateralReceiveFromOtherChains()` always charges twice the collateral on `COLLATERAL_TRANSFER`, which is not needed
medium
`Treasury::yieldsFromLiquidatedLrts()` are not withdrawable and are stuck
medium
`Treasury.noOfBorrowers` can be set to 0 by looping wei deposit<->withdrawals and DoS withdrawals and reset borrower debt
medium
`CDSLib::calculateCumulativeRate()` incorrectly only increment the local option fees when there are cds deposits
Nov '24
high
`FluidLocker::_getUnlockingPercentage()` incorrectly divides one of the components of the formula by `S`, leading to always having `80%` penalty
high
`FluidLocker::_getUnlockingPercentage()` uses 540 instead of `540 days` leading to stuck funds as the unlocking percentage will be bigger than `100%` and underflow
high
`Fontaine` never stops the flows to the tax and recipient, so the buffer component of the flows will be lost
medium
An attacker may DoS user Fluid balance increases by frontrunning `FluidLocker::claim()` calls and calling `EP_PROGRAM_MANAGER::batchUpdateUserUnits()` directly
medium
`FluidLocker::_getUnlockingPercentage()` divides before multiplying, suffering a significant precision error
medium
A malicious user may unlock instantly all the funds from the `FluidLocker` when no one is staking in the Tax pool
Findings not publicly available for private contests.
Oct '24
medium
User to sell the last supply will make the exchange contribution forever stuck
medium
`GoodDollarExchangeProvider::mintFromExpansion()` will change the price due to a rounding error in the new ratio
medium
Malicious user may frontrun `GoodDollarExpansionController::mintUBIFromReserveBalance()` to make protocol funds stuck
medium
`GoodDollarExpansionController::mintUBIFromExpansion()` expansion rate will not match the expected due to delays when calling it
medium
`TradingLimits::update()` incorrectly only rounds up when `deltaFlowUnits` becomes 0, which will silently increase trading limits
high
high
high
high
high
medium
medium
medium
medium
medium
high
high
high
high
high
medium
medium
medium
high
medium
medium
medium
Sep '24
high
medium
medium
medium
high
`totalEarnings` is incorrect when withdrawing after ending which will withdraw too many funds leaving the `Vault` insolvent
high
The amount withdrawn by an user does not discount the fee paid which will leave funds stuck when calling `LidoVault::VaultEndedWithdraw()`
medium
Attacker will DoS `LidoVault` up to 36 days which will ruin expected apr for all parties involved
medium
Lido slashing after requesting the ending withdrawal will affect the stETH shares / eth, leading to some users inability to withdraw
medium
Withdrawing after a slash event before the vault has ended will decrease `fixedSidestETHOnStartCapacity` by less than it should, so following users will withdraw more their initial deposit
high
medium
medium
high
`Listings::cancelListings()` overcharges extra funds from the user and will get them stuck
high
Malicious users will exploit the fact that `ProtectedListings::adjustPosition()` does not take a checkpoint and reduce their debt
medium
The protocol will become insolvent and some nfts will be forever stuck
Aug '24
high
Users will steal excess funds from the Vault due to `VaultPoolLib::redeem()` not always decreasing `self.withdrawalPool.raBalance` and `self.withdrawalPool.paBalance`
high
Anyone can trigger `VaultLib::_liquidatedLp()` which does not call `lvRedeemRaWithCtDs()` with the correct amount and will lead to incorrect withdrawals and stuck funds
high
Admin new issuance or user calling `Vault::redeemExpiredLv()` after `Psm::redeemWithCt()` will lead to stuck funds when trying to withdraw
high
Attackers will steal the reserve from the `Vault` by receiving `ra` in `FlashSwapRouter::__swapDsforRa()`
high
Users redeeming early will withdraw `Ra` without decreasing the amount locked, which will lead to stolen funds when withdrawing after expiry
high
Users repurchasing will transfer funds to the vault without tracking the `Ra` deposited which will leave stuck `Ra` in the `Psm`
high
Users redeeming with `Ds` in the `Psm` will not decrease the correct amount of locked `Ra`, leading to stolen funds on withdrawals
high
`VaultPoolLib::reserve()` will store the `Pa` not attributed to user withdrawals incorrectly and leave in untracked once it expires again
high
`FlashSwapRouter` assumes the `Psm`'s `Ra:Ds+Ct` ratio is 1:1 which might not be the case and will lead to loss of funds for users of the router
high
Lack of slippage protection in the `VaultLib` will lead to MEV and users will take losses
medium
Admin will not be able to only pause deposits in the `Vault` due to incorrect check leading to DoSed withdrawals
medium
Admin will not be able to upgrade the smart contracts, breaking core functionality and rendering the upgradeable contracts useless
medium
Withdrawing all `lv` before expiry will lead to lost funds in the Vault
medium
Rebasing tokens are not supported contrary to the readme and will lead to loss of funds
medium
`VaultLib::__addLiquidityToAmmUnchecked()` does not deal with the remaining amounts not sent to the amm, losing them
high
Malicious user will make prize stuck harming the winner/protocol due to `WinnablesTicketManager::cancelRaffle()/propagateRaffleWinner()` not validating `prizeManager` and `chainSelector`
high
`WinnablesTicketManager::refundPlayers()` will not decrease `_lockedETH` leading to stuck `ETH` for the protocol
high
Malicious user will completely DoS the protocol and waste all LINK tokens of the protocol
medium
`WinnablesPrizeManager::setCCIPCounterpart()` allows the admins to freely send messages from other contracts which will steal all `WinnablesPrizeManager` funds
medium
`WinnablesTicket` admin will set itself role `1` to mint tickets and steal prizes
medium
Users buying too many tickets will DoS them and the protocol if they are the winner due to OOG
high
high
high
Jul '24
9,877.59 USDC • 12 total findings • Sherlock • 0x73696d616f
medium
Depositing to another receiver othan than `msg.sender` will lead to stuck funds by increasing `avgStart` without claiming
medium
Attackers will reset `avgStart` of any user making rewards stuck for longer and get lost to savings
medium
Reward rate rounding error will cause significant loss of funds for all users
medium
Frozen/paused Market that is harvested from in StakedEXA will DoS deposits leading to loss of yield
medium
Setting a new market will make depositing to the market impossible when harvesting, DoSing deposits
medium
Market utilization ratio near 100% will DoS deposits as harvest tries to withdraw and reverts
medium
Anyone will DoS setting a new rewards duration which harms the protocol/users as they will receive too much or too little rewards
medium
Having no deposits in `StakedEXA` will lead to stuck rewards when harvesting
medium
Liquidating maturies with unassigned earnings will not take into account floating assets increase leading to loss of funds
medium
Liquidations will leave dust when repaying expired maturities, making it impossible to clear bad debt putting the protocol at a risk of insolvency
medium
Liquidator will leave a pool with unassigned earnings on `Market::clearBadDebt()` free to claim for anyone when the repaid maturity is not the last
medium
Some bad debt will not be cleared when it should which will cause accrual of bad debt decreasing the protocol's solvency
Jun '24
low
May '24
high
`DrawManager::finishDraw()` may hand out more rewards than the reserve if RNG requests fail
high
Vault portion calculation in `PrizePool::getVaultPortion()` is incorrect as `_startDrawIdInclusive` has been erased
medium
`Claimable` is vulnerable to return gas bomb attacks, DoSing claiming for all other winners
medium
Witnet is not available on some networks listed
medium
`Claimer::claimPrizes()` fee is incorrect and incurs very signficant costs whenever it is frontrunned
medium
Winners in `Claimable` may game claimer bots by claiming the prize when the `beforeHook` is called on the hook
medium
DoSed liquidations as `PrizeVault::liquidatableBalanceOf()` does not take into account the `mintLimit` when the token out is the asset
medium
`PrizeVault::deposit/mint()` will always revert due to lossy deposits in yield vaults due to rounding errors when the yield buffer is depleted
medium
Current Tpda liquidations can not deal with upwards yield fluctuations, leading to yield loss in some scenarios
medium
Estimated prize draws in TieredLiquidityDistributor are off due to rounding down when calculating the sum, leading to incorrect prizes
medium
`Requestor` uses `to.transfer()` to withdraw the balance of the creator, but the creator may not be able to receive it
medium
`DrawManager::canStartDraw()` does not take into account failed requests, returning false when it should return true and harms bots
medium
medium
Apr '24
high
Incorrect withdraw queue balance in TVL calculation
high
Withdrawals logic allows MEV exploits of TVL changes and zero-slippage zero-fee swaps
high
ETH withdrawals from EigenLayer always fail due to `OperatorDelegator`'s nonReentrant `receive()`
high
DOS of `completeQueuedWithdrawal` when ERC20 buffer is filled
medium
Withdrawals and Claims are meant to be pausable, but it is not possible in practice
medium
Withdrawals can fail due to deposits reverting in `completeQueuedWithdrawal()`
high
`LenderCommitmentGroup_Smart` picks the wrong Uniswap price, allowing borrowing at a discount by swapping before withdrawing
high
Interest rate in `LenderCommitmentGroup_Smart` may be easily manipulated by depositing, taking a loan and withdrawing
high
Stuck tokens in `TellerV2` if `bid.loanDetails.lendingToken.transferFrom()` fails as `LenderCommitmentGroup_Smart` can not withdraw from `EscrowVault`
high
`LenderCommitmentGroup_Smart` does not use `SafeERC20`, which could lead to DoS or permanently loss funds
high
`LenderCommitmentGroup_Smart::burnSharesToWithdrawEarnings()` wrong exchange rate due to burning `poolSharesToken` before calculating it
high
Drained lender due to `LenderCommitmentGroup_Smart::acceptFundsForAcceptBid()` `_collateralAmount` by `STANDARD_EXPANSION_FACTOR` multiplication
high
`LenderCommitmentGroup_Smart::liquidateDefaultedLoanWithIncentive()` will lead to stuck collateral in `LenderCommitmentGroup_Smart`
medium
Interest rate in `LenderCommitmentGroup_Smart` does not take into account the currently taken loan which will could lead to huge loans with very small interest rates
medium
Issue #497 'Add parameter to lender accept bid for MaxMarketFee' from previous audit is still present
medium
Incorrect selector in `FlashRolloverLoan_G5::_acceptCommitment()` does not match `SmartCommitmentForwarder::acceptCommitmentWithRecipient()`
medium
`FlashRolloverLoan_G5` will fail for `LenderCommitmentGroup_Smart` due to `CollateralManager` pulling collateral from `FlashRolloverLoan_G5`
medium
`FlashRolloverLoan_G5` will not work for certain tokens due to not setting the approval to `0` after repaying a loan
medium
Missing `__Ownable_init()` call in `LenderCommitmentGroup_Smart::initialize()`
medium
`LenderCommitmentGroup_Smart` does not use `mulDiv` when converting between token and share amounts, possibly leading to DoS or loss of funds
medium
`LenderCommitmentGroup_Smart` does not handle fee on transfer tokens correctly, leading to loss of funds
medium
`LenderCommitmentGroup_Smart_test::addPrincipalToCommitmentGroup/burnSharesToWithdrawEarnings()` are vulnerable to slippage attacks
medium
`LenderCommitmentGroup_Smart` will not work for some `Uniswap` pools due to `sqrtPriceX96` overflow
high
`Edition` referrer never receives any fee, which goes to the `mint` referrer instead
high
`Edition::mintBatch(address[] calldata receivers_, ...)` calculates incorrect fees for minters
medium
`TitlesGraph::checkSignature()` modifier does not implement EIP712 correctly as the `data` argument is not hashed in `ACK_TYPEHASH`
medium
Manipulated `edge.acknowledged` due to signature applying both to `TitlesGraph::acknowledgeEdge()` and `TitlesGraph::unacknowledgeEdge()`
medium
`TitlesGraph::checkSignature()` modifier is vulnerable to signature malleability, allowing the manipulation of `edge.acknowledged`
medium
`TitlesGraph` upgradeability will not work as it is not deployed behind a proxy
medium
`owner` of `FeeManager` is set to `TitlesCore`, which can not perform `onlyOwner` functions
medium
`Edition::transferWork()` does not change the fee receiver to the new `creator`
high
Unassigned pool earnings can be stolen when a maturity borrow is liquidated by depositing at maturity with 1 principal
high
`Market` is vulnerable to inflation attacks
medium
Profitable liquidations and accumulation of bad debt due to earnings accumulator not being triggered before liquidating
medium
Users may reduce their post liquidation health factor by splitting assets in several markets
medium
`TARGET_HEALTH` calculation does not consider the adjust factors of the picked seize and repay markets
medium
`Market::liquidate()` will not work when most of the liquidity is borrowed due to wrong liquidator `transferFrom()` order
medium
Incorrect previewed `totalFloatingBorrowAssets()` on liquidations due to not taking into account repaid maturities
medium
Utilization rates are 0 when average assets are 0, which may be used to game maturity borrows / deposits / withdrawals
medium
Expired maturities longer than `FixedLib.INTERVAL` with unaccrued earnings may be arbitraged and/or might lead to significant bad debt creation
medium
`rewardData.releaseRate` is incorrectly calculated on `RewardsController::config()` when `block.timestamp > start` and `rewardData.lastConfig != rewardData.start`
medium
If a maturity expires before an account handles borrow of the RewardsController, it will not have it's share, leading to lost rewards
medium
In `ZivoeRewards::rewardPerToken()`, in periods where `totalSupply = 0` rewards will be forever lost
medium
`OCC_Modular::amountOwed()` calculates `lateFee` incorrectly if more than 1 payment was missed
medium
`OCL_ZVE::pushToLockerMulti()` assumes router will always pull all the balance, leading to DoS
medium
`ZivoeYDL::earningsTrancheuse()` always assumes that `daysBetweenDistributions` have passed, which might not be the case
Jan '24
high
high
medium
Aug '23
Jul '23
high
Rewards incorrectly use new stake amount when calculating rewards from previous periods
high
Lost rewards in `LMPVault` when withdrawing underlying from destination vaults
high
Anyone can claim rewards from the rewarders to the destination vaults, DoSing `LiquidationRow` and possibly leading to stuck tokens
high
Lost rewards claimed in `LiquidationRow` as the `swap()` function is not delegate called to in `liquidateVaultsForToken()`
medium
Lost rewards when the supply is `0`, which always happens if the rewards are queued before anyone has `StakeTracker` tokens
medium
`previewRedeem()` is not ERC4626 compliant and might cause unexpected losses for users
medium
No more fees minted to sink due to inflated ratio when `totalSupply()` is very low
high
[HF06] `BaseTOFT.sol`: `retrieveFromStrategy` can be used to manipulate other user's positions due to absent approval check.
high
Exercise option cross chain message in the (m)TapiocaOFT will always revert in the destination, losing debited funds in the source chain
high
TOFT and USDO Modules Can Be Selfdestructed
high
Attacker can block LayerZero channel due to missing check of minimum gas passed
high
All assets of (m)TapiocaOFT can be stealed by depositing to strategy cross chain call with 1 amount but maximum shares possible
high
TOFT `removeCollateral` can be used to steal all the balance
high
TOFT in (m)TapiocaOft contracts can be stolen by calling removeCollateral() with a malicious removeParams.market
high
A user with a TapiocaOFT allowance >0 could steal all the underlying ERC20 tokens of the owner
high
triggerSendFrom() will send all the ETH in the destination chain where sendFrom() is called to the refundAddress in the LzCallParams argument
medium
Rebalancing mTapiocaOFT of native token forces admin to pay for rebalance amount
medium
mTapiocaOFT can't be rebalanced because the Balancer in tapiocaz-audit calls swapETH() or swap() of the RouterETH but does not forward ether for the message fee
May '23
Apr '23
Mar '23
Feb '23
Jan '23
Dec '22
medium
wrong reward distribution between early and late depositors because of the late syncRewards() call in the cycle, syncReward() logic should be executed in each withdraw or deposits (without reverting)
medium
any duration can be passed by node operator
medium
slashing fails when node operator doesn't have enough staked `GGP`