LiquidityReserve may break if underlying token is upgraded to have fees

Lines of code Vulnerability details Impact One of the tokens supported by this project is USDC, which is an upgradeable contract, and the code specifically casts addresses to IERC20Upgradeable rather than to IERC20, so the intention is for the code to support upgrades. If USDC ever upgrades to ha...

Forgot to mint Illuminate zcTokens for Element

Lines of code Vulnerability details function lend uint8 p, address u, uint256 m, uint256 a, uint256 r, uint256 d, address e, bytes32 i public unpausedp returns uint256 // Get the principal token for this market for element address principal = IMarketPlacemarketPlace.marketsu, m, p; // the element...

DoS attack on claiming rewards can lead to user never being able to claim

Lines of code Vulnerability details Proof of Concept: the stake function can be called for a different recipient than msg.sender. Each time you stake tokens your warmUpInfo.expiry or the time when you are able to claim rewards grows by warmUpPeriod as is visible the last line here not the line wi...

Yieldy: WarmUp expiry can be prolonged by staking from somebody else

WarmUp expiry can be prolonged by staking from somebody else Staking.sol:406 Staking.sol:439-444 Staking.sol:691 Impact When warmUpPeriod is greater than 1, a third person can stake to the victim to prolong the warmUp expiry. The expiry prolongation also happens with cool down, although a third...

griefing on claim()

Lines of code Vulnerability details Issue: griefing can happen if coolDownPeriod is 0 due to the fact that you can stake for someone else, whenever a stake happens, the expiry variable increases with coolDownPeriod. This can be done either by watching the mempool and frontrun a stake when someone...

arbitrage on stake()

Lines of code Vulnerability details Issue: there is a huge arb opportunity for people who deposit 1 block before the rebase Consequences: then they can call instantUnstakeReserve or instantUnstakeCurve to unstake the staked amount, in this way the profit that needs to be distributed on the next...

[M-01] Cannot set or change curve pool after initialization

Lines of code Vulnerability details Impact Inability to set or change curve pool after initialization will hurt the project liquidity and block the ability to instant unstake from curve. Approving the CURVEPOOL address is done only on initialize and only if non zero address supplied. When using...

instantUnstake function can be frontrunned with fee increase

Lines of code Vulnerability details Impact instantUnstake allows user to unstake their stakingToken for a fee paid to the liquidity providers. This fee could be changed up to 100% any moment by admin. Malicious admin could frontrun users instantUnstake transaction and set fee to any value using...

Fund migration should trigger a rebase to prevent missing out on potential rewards

Lines of code Vulnerability details Impact Rebasing allows the protocol to "distribute" profit/rewards to Yieldy and Foxy token holders by increasing the supply of tokens and increasing the balance of each token holder relative to the token balance creditBalances. The order of rebasing and...

setCurvePool does not approve the new curve pool to transfer the TOKE_POOL token, making it unusable for its intended purpose.

Lines of code Vulnerability details Staking.solsetCurvePool File: Staking.sol 153: / 154: @notice sets the curve pool address 155: @param curvePool uint 156: / 157: function setCurvePooladdress curvePool external onlyOwner 158: CURVEPOOL = curvePool; 159: setToAndFromCurve; 160:...

Arbitrage on stake()

Lines of code Vulnerability details Issue: there is a huge arb opportunity for people who deposit 1 block before the rebase Consequences: then they can call instantUnstakeReserve or instantUnstakeCurve to unstake the staked amount, in this way the profit that needs to be distributed on the next...

IStaking(contracts[i]).canBatchContracts() will revert due to the fact that contracts[i] can contain address(0)

Lines of code Vulnerability details Issue: canBatchContracts will revert due to the fact that contractsi can contain address0 as an address which will revert the whole call. Affected Code File: BatchRequests.sol 33: function canBatchContracts external view returns Batch memory 34: uint256...

Yieldy._totalSupply has different upper bounds.

Lines of code Vulnerability details Impact Yieldy.totalSupply has different upper bounds. Yieldy.mint will revert when totalSupply is exactly same as MAXSUPPLY. Proof of Concept From L91-L98, we can see totalSupply can be same as MAXSUPPLY and I think "totalSupply = MAXSUPPLY" is reasonable also...

Yieldy._storeRebase() saves and emits wrong values.

Lines of code Vulnerability details Impact Yieldy.storeRebase saves and emits wrong values. I don't think the asset will be lost directly because of this but the rebase storage will have wrong values and it might affect the system later. Proof of Concept The previousCirculating must be a previous...

Wrong parameter passed inside _storeRebase() in Yieldy Contract

Lines of code Vulnerability details In Yieldy contract, while calling storeRebase in function rebase, updatedTotalSupply is passed instead of currentTotalSupply. Filing this as medium risk , due to two impacts, in the way this parameter is used in storeRebase function. 1. The rebasePercent is...

wrong passing value in rebase function

Lines of code Vulnerability details Impact wrong information in rebases array Proof of concept rebase function should pass the totalStakedBefore the totalSupply before adding the profit to function storeRebase, but as in the code rebase pass the updatedTotalSupply Tools Used Manual review...

Cannot mint to exactly max supply using _mint function

Lines of code Vulnerability details Impact Cannot mint to exactly max supply using mint function Proof of Concept requiretotalSupply MAXSUPPLY, "Max supply"; if totalSupply == MAXSUPPLY this assert will be failed and reverted. But is shouldn't be reverted as totalSupply == MAXSUPPLY is valid. Too...

Upgraded Q -> H from 215 [1656255310294]

Judge has assessed an item in Issue 215 as High risk. The relevant finding follows: L-09 wfCashERC4626 contract does not conform to EIP4626 Description The wfCashERC4626 contract implements the EIP4626 standard EIP-4626: Tokenized Vault Standard. However, according to EIP4626, the below-mentioned...

Upgraded Q -> M from 104 [1656258768065]

Judge has assessed an item in Issue 104 as Medium risk. The relevant finding follows: L01: Silent overflow of fCashAmount Line References Description If a fCashAmount value that is greater than uint88 is passed into the mint function, downcasting it to uint88 will silently overflow. Recommended...

[H-05] Not minting iPTs for lenders in several lend functions

Lines of code Vulnerability details Impact Using any of the lend function mentioned, will result in loss of funds to the lender - as the funds are transferred from them but no iPTs are sent back to them! Basically making lending via these external PTs unusable. Proof of Concept There is no mintin...

Principal token is not transferred

Lines of code Vulnerability details Impact When redeeming from APWine and Tempus here, the principal token is not transferred to the redeemer, so may be stuck on the lender contract. Proof of Concept Instead of Safe.transferFromIERC20u, lender, addressthis, amount; it should be...

Funds may be stuck when redeeming for Illuminate

Lines of code Vulnerability details Impact Funds may be stuck when redeeming for Illuminate. Proof of Concept Assuming the goal of calling redeem for Illuminate here is to redeem the Illuminate principal held by the lender or the redeemer, then there is an issue because the wrong balance is...

[M-03] Wrong minting on lend for Tempus

Lines of code Vulnerability details Impact Will result in either failure to lend or loss of funds for the lender Proof of Concept Not very clear what was the original intention, but I find it hard to believe that subtracting the whole balanceOf iPTs from the return result from Tempus, is what was...

ERC5095 redeem must check allowance with principalAmount instead of underlyingAmount

Lines of code Vulnerability details Impact ERC5095 redeem must check allowance with principalAmount instead of underlyingAmount. Allowing any user to redeem token of anybody freely. This is very critical, anyone can lost their money everytime without their acknowledgement. Proof of Concept functi...

Transfer the original underlying token back to the user but actually transfer from lender to redeemer

Lines of code Vulnerability details Impact Transfer the original underlying token back to the user but actually transfer from lender to redeemer. Underlying token may be locked forever and user may not receive their fund after redeeming. Proof of Concept // Transfer the original underlying token...

Able to mint any amount of PT

Lines of code Lender.solL192-L235 Lender.solL486-L534 Lender.solL545-L589 Vulnerability details Impact Some of the lend functions do not validate addresses sent as input which could lead to a malicous user being able to mint more PT tokens than they should. Functions affect: Illuminate and Yield...

Potential interests are not distributed fairly among the zcTokens holders, nor taken as a protocol fee, but will be frozen in the redeemer contract

Lines of code Vulnerability details function authRedeem address u, uint256 m, address f, address t, uint256 a public authorizedIMarketPlacemarketPlace.marketsu, m, 0 returns bool // Get the principal token for the given market IERC5095 pt = IERC5095IMarketPlacemarketPlace.marketsu, m, 0; // Make...

Redeemer.sol#redeem() the principal token from Notional can not be redeemed

Lines of code Vulnerability details int256 amount = IERC20principal.balanceOflender; // Transfer the principal token from the lender contract to here Safe.transferFromIERC20principal, lender, addressthis, amount; if p == uint8MarketPlace.Principals.Swivel // Redeems zc tokens to the sender's...

In Notional case Redeemer's redeem() will not do the position redeeming

Lines of code Vulnerability details Currently no actual redeeeming is done in Notional case as maxRedeem is a balance view function that doesn't close the position. This way one more operation, the redeeming itself, is now committed and in Notional case Redeemer's redeem doesn't perform anything,...

lend() to Tempus will return less than expected or just revert

Lines of code Vulnerability details function lend uint8 p, address u, uint256 m, uint256 a, uint256 r, uint256 d, address t, address x public unpausedp returns uint256 // Instantiate market and tokens address principal = IMarketPlacemarketPlace.marketsu, m, p; if ITempusprincipal.yieldBearingToke...

Lender.sol amountIn is used as returned for Pendle

Lines of code Vulnerability details uint256 returned; // Add the accumulated fees to the total uint256 fee = calculateFeea; feesu += fee; address memory path = new address; path0 = u; path1 = principal; // Swap on the Pendle Router using the provided market and params returned =...

Safe.approve may not work for USDT

Lines of code Vulnerability details Impact Some tokens like USDT do not work when changing the allowance from an existing non-zero allowance value. They must first be approved by zero and then the actual allowance must be approved. Proof of concept: The following function may fail and make USDT...

Improper Upper Bound Definition on the Fee

Lines of code Vulnerability details Impact The feenominator does not have any upper or lower bounds. Values that are too large will lead to reversions in several critical functions or the platform user will lost all funds when paying the fee. Proof of Concept 1. Navigate to the following contract...

Unpaused modifier can be sidestepped in one of the lend functions.

Lines of code Vulnerability details Impact Suppose you tried to pause the lend function that is connected to Swivel. In that case, the attacker could sidestep it because there is no verification that the number input from the user corresponds with the desired input. Proof of Concept Let's say a b...

Uninitialized local variables

Lines of code Vulnerability details Impact Configuration -Check: uninitialized-local -Severity: Medium -Confidence: Medium -Description:.Lender.approveaddress,uint256,address.i Lender.sol87 is a local variable never initialized.A smart contract with uninitialized local variables may lead to...

Uninitialized local variables

Lines of code Vulnerability details Impact Configuration -Check: uninitialized-local -Severity: Medium -Confidence: Medium -Description:Lender.approveaddress,address.i Lender.sol114 is a local variable never initialized.A smart contract with uninitialized local variables may lead to intentional...

Fees should be paid by the user when lend() to Swivel

Lines of code Vulnerability details function lend uint8 p, address u, uint256 m, uint256 memory a, address y, Swivel.Order calldata o, Swivel.Components calldata s public unpausedp returns uint256 // lent represents the number of underlying tokens lent uint256 lent; // returned represents the...

[H-04] Some fees are locked on contract without ever being able to be collected

Lines of code Vulnerability details Proof of Concept The full amount a is transferFrom lender on L215 The amount - fee is invested on L219 and L229. Unlike other lend function, this one is missing crediting the project with the fees they entitled to. As a result, these fees cannot be collected vi...

Deflationary/fee-on-transfer tokens are not supported

Lines of code Lender.solL215 Lender.solL337 Lender.solL398 Lender.solL456 Lender.solL521 Lender.solL564 Lender.solL617 Vulnerability details Impact When an amount of underlying tokens is sent to the Lender.sol contract during a lend, the actual amount gained by the contract might not be exactly t...

[M-01] Easily bypassing admins 'pause' for swivel

Lines of code Vulnerability details Impact Assuming admin decides to pause an external principle when it's dangerous, malicious or unprofitable, Bypassing the admins decision can result in loss of funds for the project. Proof of Concept The principals enum p is only used for unpausedp modifier, a...

Inaccurate fee calculation

Lines of code Vulnerability details Impact The equation in the calculateFee function has a high degree of inaccuracy Solidity use integers, when divide an uint256 for other uint256 the divition take the floor number and ignore the decimal part In example: a = 1999 ETH feenominator = 1000 the retu...

Fee on transfer tokens not supported

Lines of code Vulnerability details Impact Fee on transfer tokens would lead to sellers getting more PT than what the pool has received in underlying as the difference in balance is not accounted for, only the a input. This is also true for mintWithUnderlying as minters get more in relation to th...

instead of call() , transfer() is used to withdraw the ether

Lines of code Vulnerability details Impact To withdraw eth it uses transfer, this trnansaction will fail inevitably when : - The withdrwer smart contract does not implement a payable function. Withdrawer smart contract does implement a payable fallback which uses more than 2300 gas unit Thw...

lender variable in is not the same as constructory and method in the construcotr ther is no check for address zero

Lines of code Vulnerability details Impact lender variable not the same as constructory and method its no check for address zero Recommended Mitigation Steps check for address zero in the constructor --- The text was updated successfully, but these errors were encountered: 😕 1 KenzoAgada reacted...

Illuminate PT redeeming allows for burning from other accounts

Lines of code Vulnerability details Illuminate PT burns shares from a user supplied address account instead of user's account. With such a discrepancy a malicious user can burn all other's user shares by having the necessary shares on her balance, while burning them from everyone else. Setting th...

Griefing on claim()

Lines of code Vulnerability details Issue: griefing can happen if coolDownPeriod 0 due to the fact that you can stake for someone else. Whenever a stake happens, the expiry variable increases with coolDownPeriod. This can be done either by watching the mempool and frontrun a stake when someone...

Sending batch withdrawal requests can possibly DoS

Lines of code Vulnerability details Impact The function BatchRequests.sendWithdrawalRequests allows calling the sendWithdrawalRequests function on all of the Yieldy contracts at once. However, due to the unbounded for loop, if many Yieldy contracts are added to contracts, this function can...

Possible DoS in Staking.claim() function

Lines of code Vulnerability details Impact In Staking contract, users are allowed to stake for another recipient. And it also updates warmUpInfo.expiry for recipient address so recipient can only claim after this new expiry is passed. Attackers can abuse this to constantly stake 1 wei for another...

Front running Staking can bypass warmUpPeriod

Lines of code Vulnerability details Impact Yieldy implements a warmUpPeriod to prevent new stakers from using freshly minted yieldy tokens in the Staking.sol contract. warmUpPeriod is not initialised in the contract initialisation therefore a user can frontrun when the onlyOwner calls...

It's possible to perform DOS and fund lose in Stacking by transferring tokens directly to contract

Lines of code Vulnerability details Impact Function rebase in contract Staking calls Yieldy.rebaseprofit, and Yieldy.rebaseprofit, would revert if rebasingCredits / updatedTotalSupply was equal to 0. it's possible to transfer some STAKINGTOKEN directly to Stacking contract before or after...