The first stake is possible after endTime

Lines of code Vulnerability details Impact Users can stake after endTime due to the wrong check. Proof of Concept When a user stakes LP tokens using MuteAmplifier.stake, stake is not allowed after endTime which is set in initializeDeposit by an admin. requireblock.timestamp endTime,...

Award is still distributed when there aren't any stakers, allowing users to get reward without staking

Lines of code Vulnerability details Proof of Concept Consider the update modifier for the amplifier. modifier update if mostRecentValueCalcTime == 0 mostRecentValueCalcTime = firstStakeTime; uint256 totalCurrentStake = totalStake; if totalCurrentStake 0 && mostRecentValueCalcTime endTime uint256...

Malicious user can force victims to waste a lot of gas when they redeem their dMute

Lines of code Vulnerability details Proof of Concept When redeeming, the user must iterate through all the elements of userLock to destroy any redeemed locks. foruint256 i = userLocksmsg.sender.length; i 0; i-- UserLockInfo memory lockinfo = userLocksmsg.senderi - 1; // recently redeemed lock,...

MuteAmplifier.rescueTokens() checks the wrong condition for muteToken

Lines of code Vulnerability details Impact There will be 2 impacts. The reward system would be broken as the rewards can be withdrawn before starting staking. Some rewards would be locked inside the contract forever as it doesn't check totalReclaimed Proof of Concept rescueTokens checks the below...

Params of Lien struct are not emitted when lien is created making it difficult to track

Lines of code Vulnerability details Impact Protocol does not store any information about Lien. When users want to interact, they have to send the whole Lien struct along with lienId, and the protocol will verify if this data is correct by hash. This approach reduces onchain storage and can save a...

MuteBond is susceptible to DOS

Lines of code Vulnerability details Proof of Concept Observe that if timeToTokens is called with locktime = 1 week, amount 52, it will return 0. function timeToTokensuint256 amount, uint256 locktime internal pure returns uint256 uint256 weektime = 1 weeks; uint256 maxlock = 52 weeks;...

Attacker can front-run Bond buyer and make them buy it for a lower payout than expected

Lines of code Vulnerability details The MuteBond contract contains a feature in which after each purchase the epochStart increases by 5% of the time passed since epochStart, this in most cases lowers the bond's price i.e. buyer gets less payout for future purchases. An attacker can exploit this...

Function takeBid() allows attacker to sell any collateral NFT that deposited through function borrowToBuy()

Lines of code Vulnerability details Impact Function borrowToBuy is used by the borrower to take a loan offer and uses the funds to purchase NFT. However, even though it sends ETH along when calling function execute to buy the requested NFT, it approves the collateral NFT to Blur for no reason. /...

A user can 'borrow' dMute balance for a single block to increase their amplifier APY

Lines of code Vulnerability details The amplifier's APY is calculated based on the user's dMute balance delegation balance to be more accurate - the more dMute the user holds the higher APY they get. However, the contract only checks the user's dMute balance at staking, the user doesn't have to...

Logic for RescueTokens is incorrect for muteTokens

Lines of code Vulnerability details Proof of Concept The logic for RescueTokens doesn't take into account the reward remainders. I wanted to write a POC but I'm in a bit of a time crunch. So, imagine the following situation: totalRewards = 100, and staker A, B the only stakers staked for the firs...

Amplifier users might not get all the LP fees they are entitled to

Lines of code Vulnerability details Proof of Concept Observe that there is only one place that the amplifier is calling claimFees, and it's inside an if statement of the update modifier, requiring mostRecentValueCalcTime modifier update if mostRecentValueCalcTime == 0 mostRecentValueCalcTime =...

Attacker can take a loan offer without providing the NFT from requested collection by using function borrowerRefinance()

Lines of code Vulnerability details Impact Function borrowerRefinance allows the borrower to repay the previous loan and take a different loan offer. In the codebase, there is no check to ensure that collateral collection of previous loan and new loan offer are the same. It can be abused by an...

An edge case in amplifier allows user to stake after end time, causing reward to be locked in the contract

Lines of code Vulnerability details Proof of Concept Observe that if nobody has staked after the period has ended, it's still possible for a single user to stake even though the period has ended. if firstStakeTime == 0 firstStakeTime = block.timestamp; else requireblock.timestamp if...

In MuteBond.deposit(), users might deposit more LPs than they expected by a malicious user

Lines of code Vulnerability details Impact Users might deposit more LPs unexpectedly if a malicious user increases an epoch by frontrunning. Proof of Concept deposit has a maxbuy param to purchase all remaining amounts. function deposituint value, address depositor, bool maxbuy external returns...

MuteAmplifier.rescueTokens() should check conditions for fee tokens(token0/token1) as well

Lines of code Vulnerability details Impact rescueTokens can be used to withdraw fee tokens without any validations. As a result, the reward logic would be broken due to the lack of fee tokens. Proof of Concept rescueTokens doesn't validate anything for the fee tokens. So if some fee tokens were...

A malicious frontrunner can make the Mutebond contract broken when the owner decreases maxPayout

Lines of code Vulnerability details Impact The Mutebond contract might stop working after the owner decreased maxPayout by a malicious frontrunner. Proof of Concept setMaxPayout can be used to reset maxPayout. function setMaxPayoutuint payout external requiremsg.sender == customTreasury.owner;...

Owner lowering max payout might break the MuteBonds contract

Lines of code Vulnerability details The maxPayout variable can be changed by the owner at any time. In case the owner lowers the maxPayout and the payoutTotal of the current epoch is greater than the new maxPayout the contract will be broken - no further deposit can be made, and most of the view...

Bond max-buyer might end up buying the max buy of the next epoch

Lines of code Vulnerability details The MuteBond.deposit function allows users to specify the amount of value they want to purchase bonds for or to set maxbuy to true. If maxbuy is set to true the amount specified in the value parameter is ignored and instead the maximum amount available for...

MuteAmplifier.sol: multiplier calculation is incorrect which leads to loss of rewards for almost all stakers

Lines of code Vulnerability details Impact This report deals with how the calculation of the multiplier in the MuteAmplifier contract is not only different from how it is displayed in the documentation on the website but it is also different in a very important way. The calculation on the website...

MuteAmplifier.sol: rescueTokens function does not prevent fee tokens from being transferred

Lines of code Vulnerability details Impact The MuteAmplifier.rescueTokens function allows the owner to withdraw tokens that are not meant to be in this contract. The contract does protect tokens that ARE meant to be in the contract by not allowing them to be transferred: Link function...

No slippage control for deposit() with the impact that a user deposits with expected high bond price might end up a deposit with the lowest bond price.

Lines of code Vulnerability details Impact Detailed description of the impact of this finding. There is no slippage control for deposit. Impact: a user deposits with expected high bond price might end up a deposit with the lowest bond price. Scenario: a depositor waits for the end of an epoch,...

MuteBond.sol: deposit function allows no control for payout and value which leads to unexpected purchases of bonds

Lines of code Vulnerability details Impact The MuteBond.deposit function allows the user to purchase a bond with LP tokens and receive MUTE tokens in return. The bondPrice increases linearly over time which I should mention means the bond gets cheaper; the naming is a bit confusing. There is...

An attacker can lower the price of another depositor() by frontrunning

Lines of code Vulnerability details Impact Detailed description of the impact of this finding. The deposit function will bump bond price back by 5% after purchase based on current delta. However, this function can be executed unlimited number of times in the same block and as a result, one can...

There is a race condition betweeen MuteBond#setEpochDuration() and MuteBond#deposit()

Lines of code Vulnerability details Impact Detailed description of the impact of this finding. There is a race condition between MuteBondsetEpochDuration and MuteBonddeposit. The issue is that when a new EpochDuration is set, it will take effect immediately, which will affect the bond price. As a...

MuteBond.sol: When maxPayout is lowered the contract can end up DOSed

Lines of code Vulnerability details Impact The maxPayout variable in the MuteBond contract specifies the amount of MUTE that is paid out in one epoch before the next epoch is entered. The variable is initialized in the constructor and can then be changed via the setMaxPayout function. The issue...

Division before multiplication truncate minOut and incurs heavy precision loss and result in insufficient slippage protection

Lines of code Vulnerability details Impact When Calcuting the minOut before doing trade, Division before multiplication truncate minOut and incurs heavy precision loss, then very sub-optimal amount of the trade output can result in loss of fund from user because of the insufficient slippage...

Users might lose their stETH rebased reward due to the weights change

Lines of code Vulnerability details Vulnerability Details Let's consider the following scenario: Bob deposits 10eth with the weights: stETH: weights0 = 90e18, rETH: weights1 = 5e18. sfrxETH: weights2 = 5e18 Now, since the Lido has 80% of liquid staking market, Asymmetry Finance decides to adjust...

Burning rETH at the unstake might revert

Lines of code Vulnerability details Impact Unstaking is blocked. Proof of Concept When unstaking the withdraw of each derivative is called. Reth.withdraw withdraws by calling RocketTokenRETHInterfacerethAddress.burnamount. But RocketTokenRETH.burn reverts if the ETH balance is insufficient for th...

WstEth.withdraw() improper implementation of slippage check

Lines of code Vulnerability details Impact In the current implementation of withdraw, the amount is not controlled by minOut. Impact: Users can get rekt. Proof of Concept function withdrawuint256 amount external onlyOwner IWStETHWSTETH.unwrapamount; uint256 stEthBal =...

And all this assembly shall know that the OWNER SafEth not with derivatives: for the derivative is the OWNER'S, and he will rebalanceToWeights it into his EOA.

Lines of code Vulnerability details Impact The owner of SafEth can at any time steal all staked funds. Proof of Concept SafEth.addDerivative allows the owner to add any derivative contract, such as one where he can withdraw all IDerivative.deposit-ed funds. SafEth.adjustWeights allows the owner t...

Incorrect minOut calculation in SfrxEth.withdraw()

Lines of code Vulnerability details Impact Final value of mintOut will be lower or higher according to the SFRXETH/FRXETH price ratio. This can result in higher slippage where user can loss funds. Else in other case the slippage will be low and transaction gets reverted unexpectedly Proof of...

SfrxEth slippage and fee stealing

Lines of code Vulnerability details Impact The SfrxEth derivative contract calculates the maximum slippage for buying SfrxEth from curve pool by using the current price in the pool at runtime, without considering the price at which the user submitted the transaction to the mempool: uint256 minOut...

An attacker can manipulate the preDepositvePrice to steal from other users.

Lines of code Vulnerability details Impact The first user that stakes can manipulate the total supply of sfTokens and by doing so create a rounding error for each subsequent user. In the worst case, an attacker can steal all the funds of the next user. Proof of Concept When the first user enters...

withdraw function of WstEth derivative contract probably sends wrong ETH amount back to owner contract/user

Lines of code Vulnerability details Impact Sends the wrong amount of ETH back to owner contract/user. In most cases, probably way too much, it sends the entire contract ETH balance. All the other calculations in the withdraw function seem correct, from what can be seen, but, as is the case with...

Derivative Pool Issue can Lead to Loss User Funds when Unstaking

Lines of code Vulnerability details Impact In all withdraw functions of derivatives, there is no check for sending zero Ether back to the safEth contract. It is important to note that the addressmsg.sender.callvalue: 0"" function returns true even when transferring a zero value. On the other hand...

WstEth slippage and fee stealing

Lines of code Vulnerability details Impact The WstEth derivative contract calculates the maximum slippage for buying WstEth from curve pool by using the current price in the pool at runtime, without considering the price at which the user submitted the transaction to the mempool: uint256 minOut =...

Reth slippage and fee stealing

Lines of code Vulnerability details Impact The Reth derivative contract calculates the maximum slippage for buying rETH from the Uniswap V3 pool by using the current price in the pool at runtime, without considering the price at which the user submitted the transaction to the mempool: uint...

[H-02] Front-running of first deposit allows attacker to steal funds

Lines of code Vulnerability details Impact Due to the way in which the SafEth share price is calculated, an attacker can front-run the first depositor's transaction and steal funds through an inflation attack. SafEth::stake calculates the share price by dividing the total asset amount by the tota...

Potential reentrancy in unstake function

Lines of code Vulnerability details Impact there is a potential reentrancy vulnerability in the unstake function. After the user's safETH tokens are burned, the function sends ETH to the user's address using the call method. If the receiving address is a contract and it has a fallback function th...

sFrxEth may revert on redeeming non-zero amount

Lines of code Vulnerability details Impact Unstaking is blocked. Proof of Concept When unstaking the withdraw of each derivative is called. SfrxEth.withdraw calls IsFrxEthSFRXETHADDRESS.redeemamount, addressthis, addressthis;. This function may revert if amount is low due to the following line in...

[H-01] RETH oracle manipulation allows attacker to steal funds

Lines of code Vulnerability details Impact The Asymmetry SafEth protocol aims to help diversify and decentralize liquid staking derivatives, exchanging ether staked in the protocol for staked ether derivative tokens based on some relative weighting. A function exposed by these derivative wrapper...

Hardcoded slippage can lead to user's transactions being front run

Lines of code Vulnerability details Vulnerability details Impact Since all the main function that the user execute implement slippage, attackers can front run any user transaction since the slippage amount is set to 1% on all the lines of code listed above. This can lead to sandwich attacks. Proo...

Spot UniswapV3 pricing for rETH when staking in SafEth can lead to loss of user funds

Lines of code Vulnerability details Impact An attacker can craft a set of transactions so that when they are depositing funds in the SafEth contract, using the stake function, they can understate the value of existing deposits preDepositPrice value, while overstating the value of their deposit...

REth token price can be manipulated

Lines of code Vulnerability details Impact Currently, all deposit operations split the received ETH between derivatives. One of them is rETH, trading on Pool 0xa4e0faA58465A2D369aa21B3e42d43374c6F9613 with around 1500 ETH in liquidity for each side. The price calculation for splitting deposits in...

Reth flashloan attack

Lines of code Vulnerability details Impact Using a flashloan to manipulate rETH/ETH price a hacker can receive more SafEth shares for the same amount of ether, thus draining all three derivative contracts rETH, SfrxEth and WstEth. Proof of Concept Reth.poolPrice depends on UniswapV3 pool.slot0...

Zero value used for sqrtPriceLimitX96

Lines of code Vulnerability details Impact In swapExactInputSingleHop in Reth.sol the sqrtPriceLimitX96 parameter is set to 0 which is useful for testing but can lead to price manipulation attacks. From the uniswap docs: In production, this value can be used to set the limit for the price the swa...

Reth griefing

Lines of code Vulnerability details Impact The maximum slippage when buying rETH from the Uniswap V3 pool is calculated in Reth derivative contract by taking the current price in the Uniswap V3 pool at runtime, without taking into account the price at which the user sent the transaction to the...

dMute.sol: Attacker can push lock items to victim's array such that redemptions are forever blocked

Lines of code Vulnerability details Impact This report deals with how an attacker can abuse the fact that he can lock MUTE tokens for any other user and thereby push items to the array of UserLockInfo structs of the user. There are two functions in the dMute contract that iterate over all items i...

Missing critical check of amount minted tokens in stake() -> deposit()

Lines of code Vulnerability details Impact No require to ensure that SfrxEth or WstEth is minted when calling in SafEth.sol stake - IDerivative.deposit function Proof of Concept In the deposit function in Reth.sol has a require statement to ensure that the token was actually minted. But there is ...

Reth deposit conditionally relies on unreliable price source.

Lines of code Vulnerability details Impact Deposits are exposed to unnecessary risk by using Uni v3 Weth/Reth Pool as an oracle. It is also possible for staking to be inoperable due to over/underflow. Proof of Concept In the event of !poolCanDepositmsg.value in Reth.sol deposit, this derivative...