No ERC20 safe* versions called

Handle cmichel Vulnerability details The claim function performs an ERC20 transfer rewardsToken.transferto, claiming; but does not check the return value, nor does it work with all legacy tokens. Some tokens like USDT don't correctly implement the EIP20 standard and their transfer/transferFrom...

Synths minted to the wrong market when initializing

Handle 0xImpostor Vulnerability details Impact Synthetix tokens are not minted to the correct market index since the creation of the synth market and the initialization are 2 separate steps. Proof of Concept 1. Create 2 synth market without initializing them 2. Call initializeMarket twice 3. Synt...

Difficult for the project to be decentralized if the Watsons share one address.

Handle tensors Vulnerability details Impact The Watsons share a single address. As it stands right now the Watsons could be a single person effectively providing insurance with other peoples risk. There should be mechanisms in place to make sure Watson's have an accurate amount of skin in the gam...

Incorrect internal balance bookkeeping

Handle walker Vulnerability details type: Incorrect Assumptions on External Systems The sherlock smart contract system uses internal bookkeeping of arbitrary ERC20 token balances. It doesn't assert that the ERC20 doesn't implement some non-standard behaviour. For example, deflationary tokens, or...

Missing slippage checks

Handle cmichel Vulnerability details The Router and Pool does not implement any slippage checks with comparing the swap / liquidity results with a minimum swap / liquidity value. Impact Users can be frontrun and receive a worse price than expected when they initially submitted the transaction...

Router.zapLiquidity(uint256,address,address) has unchecked transfers

Handle heiho1 Vulnerability details Impact Router.zapLiquidityuint256,address,address has unchecked transfers on lines 65, 67 and 69. Several tokens do not revert in case of failure and return false. If one of these tokens is used in Router, deposit will not revert if the transfer fails, and an...

Unchecked transfers found in 3 contracts

Handle maplesyrup Vulnerability details Impact This is a high priority vulnerability because it definitely affects the way that funds are transferred and sent between the contracts. You want to make sure that you check the boolean value from these transfer functions in order to make sure that the...

Missing input validation in realise()

Handle 0xsanson Vulnerability details Impact In synth.sol, the function realisepool can be called using any existing pool as input. From my understanding, it's supposed that pool and synth must have the same underlying token. With the current implementation an user can call various synth contract...

SynthVault withdraw forfeits rewards

Handle cmichel Vulnerability details Vulnerability Details The SynthVault.withdraw function does not claim the user's rewards. It decreases the user's weight and therefore they are forfeiting their accumulated rewards. The synthReward variable in processWithdraw is also never used - it was probab...

Router.removeLiquidityExact(uint256,address) has unchecked transfers

Handle heiho1 Vulnerability details Impact Router.removeLiquidityExactuint256,address line 114 does not check the boolean return of a token transfer. This is a brittle implementation because it relies on the boolean return value being hard-coded to true. Tokens may not revert in case of failure a...

Pool._addPoolMetrics(uint256) is subject to potential miner manipulation

Handle heiho1 Vulnerability details Impact Pool.addPoolMetricsuint256 on line 334 relies on block.timestamp and is potentially vulnerable to miner manipulation. This could lead to erroneous pool metrics. Proof of Concept Tools Used Slither Recommended Mitigation Steps An external time oracle like...

ChainLink price data could be stale

Handle cmichel Vulnerability details There is no check in UniswapV3Oracle.ethPrice if the return values indicate stale data. This could lead to stale prices according to the Chainlink documentation: under current notifications: "if answeredInRound roundId could indicate stale data." under...

Lending Pair initialize function can be front run.

Handle jonah1005 Vulnerability details Impact LendingPair does not initialize tokenMaster, controller, tokens. A hacker can listen the deployer address and front run the initialize transaction. The initialized contract would look almost exactly the same if the hacker only replace lpTokenMaster wi...

addLiquidity transfers tokens from the wrong sender

Handle pauliax Vulnerability details Impact In addLiquidity function, a router is passed as a sender in LibERC20.transferFrom, not msg.sender, so it basically transfers assets from the router to the contract. Recommended Mitigation Steps requireLibERC20.transferFromassetId, msg.sender, addressthi...

Signatures use only tx ID instead of entire digest

Handle 0xRajeev Vulnerability details Impact The signature check in recoverFulfillSignature only uses transaction ID along with the relayer fee which can be accidentally reused by the user, in which case the older signatures with the older relayer fees can be replayed. The signature should be on...

Funds can be stolen because of approval + send

Handle cmichel Vulnerability details Vulnerability Details The fulfill transaction on the receiving chain first approves the txData.callTo contract with the toSend amount. It then tries to call the addFunds and execute actions on txData.callTo. When any of the calls reverts, the funds are sent to...

addLiquidity can be denied

Handle cmichel Vulnerability details Vulnerability Details The addLiquidity function can be called by anyone to transfer funds from the router address specified as a function argument. These funds must be approved first by the router prior to calling this function. There are different griefing...

Flash loan risk mitigation is optional and not robust enough

Handle 0xRajeev Vulnerability details Impact The switchEoaOnly allows the owner to disable preventSmartContracts the project’s plan apparently is to do so after the beta-period which will allow any smart contract to interact with the protocol and potentially exploit any underlying flash loan...

distributeStrategyGainLoss can be abused

Handle gpersoon Vulnerability details Impact The function distributeStrategyGainLoss does the following check to allow access to the function: requireindex 0 || index = NCOINS + 1, "!VaultAdaptor"; However the expression index 0 || index = NCOINS + 1 is always TRUE, because the OR || is used shou...

Wrong funding index in settle when no base?

Handle cmichel Vulnerability details The TracerPerpetualSwaps.settle function updates the user's last index to currentGlobalFundingIndex, however a comment states: "// Note: global rates reference the last fully established rate hence the -1, and not the current global rate. User rates reference...

Wrong trading pricing calculations

Handle 0xsanson Vulnerability details Impact In the Pricing contract, an agent can manipulate the trading prices by spamming an high amount of trades. Indeed an agent can create an high amount of orders at an arbitrary price and with a near-zero amount so the agent doesn't even need large funds;...

No check transferFrom() return value

Handle s1m0 Vulnerability details Impact The smart contract doesn't check the return value of token.transfer and token.transferFrom, some erc20 token might not revert in case of error but return false. In the TracerPerpetualSwaps:deposit and Insurance:deposit this would allow a user to deposit fo...

Awarding takes reserve fee several times

Handle cmichel Vulnerability details The PrizePool.captureAwardBalance function takes fees repeatedly on the same interest. One would expect unaccountedPrizeBalance to be 0 in any repeated calls, but it's not. Assume the following example scenario with a 10% reserve fee: user calls...

Initialization functions can be front-run with malicious values

Handle 0xRajeev Vulnerability details Impact Most contracts have public visibility initialization functions that can be front-run, allowing an attacker to incorrectly initialize the contracts. Due to the use of the delegatecall proxy pattern, PrizePool/YieldSourcePrizePool/StakePrizePool,...

User could deposit for free

Handle s1m0 Vulnerability details Impact deposit function doesn't check the return value of transferFrom that means if the erc20 token return false instead of reverting the user could deposit for free. Tools Used Manual analysis Recommended Mitigation Steps Use openzeppelin's SafeERC20 library. -...

Market-specific pause is not checked for sponsor

Handle cmichel Vulnerability details Vulnerability Details The treasury only checks its globalPause field but does not check its market-specific marketPaused field for Treasury.sponsor. A paused market contract can therefore still deposit as a sponsor using Market.sponsor Impact The market-specif...

Deposit whitelist enforced on msg.sender instead of user

Handle 0xRajeev Vulnerability details Impact The Treasury deposit function credits amount to the user address in parameter instead of the msgSender that is actually making the deposit whose rationale as explained in the Natspec comment is that this may be called via contract or L1-L2 bot. However...

transferFrom result not checked

Handle gpersoon Vulnerability details Impact The function deposit of SafeERC20.sol relies on the fact that transferFrom will revert if it can't transfer the erc20 tokens. However, depending on the ERC20 token, this doesn't happen and you have to check the result of transferFrom. With the wrong...

Join Factory Contract Replacement

Handle 0xsomeone Vulnerability details Impact The JoinFactory contract is utilizing the create2 OPCODE via syntactic sugar to deploy a new Join instance, however, no sanitization occurs on the inputs allowing contracts and thereby ownerships to be replaced at will. Proof of Concept If the...

stir to self

Handle gpersoon Vulnerability details Impact The function stir of Cauldron.sol can be manipulated when from == to. In that case the balance of "to" is increased while the balance of "from" isn't decreased. This is due to the fact that a temporary variable is used and the balance of "to" overwrite...

pendingWithdrawals not decreased after a withdraw

Handle shw Vulnerability details Impact The variable pendingWithdrawals in the contract Withdrawable is not decreased after the function withdraw is called, which causes the return value of function getReserveBalance less than it should be. This bug could cause incorrect results in several critic...

ChainLink price data could be stale

Handle cmichel Vulnerability details Vulnerability Details There is no check in FSDNetwork.getEtherPrice if the return values indicate stale data. This could lead to stale prices according to the Chainlink documentation: under current notifications: "if answeredInRound roundId could indicate stal...

Call to swapExactTokensForETH in liquidateDai() will always fail

Handle 0xRajeev Vulnerability details Impact liquidateDai calls Uniswap’s swapExactTokensForETH to swap Dai to ETH. This will work if msg.sender, i.e. FSD contract, has already given the router an allowance of at least amount on the input token Dai. Given that there is no prior approval, the call...

Locked funds are debited twice from user during tokenization leading to fund loss

Handle 0xRajeev Vulnerability details Impact During tokenization of conviction scores, the user can optionally provide FSDs to be locked to let it continue conviction accrual. However, the amount of FSDs specified for locking are debited twice from the user leading to fund loss for user. This, in...

gracePeriod not increased after membership extension

Handle gpersoon Vulnerability details Impact In the function purchaseMembership of FSDNetwork.sol, when the membership is extended then membershipmsg.sender.creation is increased, however membershipmsg.sender.gracePeriod is not increased. This might lead to a gracePeriod than is less then expecte...

Unchecked return value of transferFrom in function timeLockERC20

Handle shw Vulnerability details Impact In the function timeLockERC20 line 610, the return value of IERC20.transferFrom is unchecked. The return value could be false if the transferred token is not ERC20-compliant, indicating that the transfer fails. In that case, the variable timelockERC20Balanc...

Unbounded loop in function transferERC721

Handle shw Vulnerability details Impact The function transferERC721 loops over an unbounded array, timelockERC721KeysnftContract, whose length never decreases but increases whenever the owner locks an ERC721 token. Therefore, the required gas for executing this loop grows over time and could reac...

Unbounded iteration

Handle cmichel Vulnerability details Vulnerability Details The Visor.removeNft iterates over all nfts. Anyone can add to this array by depositing NFTs, see Visor.onERC721Received. Other occurences that makes an unbounded iteration over arrays: Visor.getBalanceLocked Visor.getNftIdByTokenIdAndAddr...

A malicious receiver can cause another receiver to lose out on distributed fees by returning false for tokensReceived when receiveRewards is called on their receiver contract.

Handle janbro Vulnerability details Summary A malicious receiver can cause another receiver to lose out on distributed fees by returning false for tokensReceived when receiveRewards is called on their receiver contract. Risk Rating Medium Vulnerability Details A malicious receiver can cause anoth...

function receiveNFTs does not check if amount > 0

Handle paulius.eth Vulnerability details Impact When is1155 is true, function receiveNFTs iterates over all the tokens and updates holdings and quantity1155. If the quantity1155 is 0 for that token, it adds this token to the holdings set. However, it does not check that the amount is greater than...

This is a test submission and can be deleted

Handle adamavenir Vulnerability details Impact Detailed description of the impact of this finding. Proof of Concept Provide direct links to all referenced code in GitHub. Add screenshots, logs, or any other relevant proof that illustrates the concept. Tools Used Recommended Mitigation Steps --- T...

Randomnesss can be manipulated

Handle adelamo Vulnerability details Here you have more info: --- The text was updated successfully, but these errors were encountered: All reactions...

NFT can be minted for free after sale ended

Handle s1m0 Vulnerability details Impact The getPrice return 0 after the sale ended and SALELIMIT - numSales nft can be minted for free. Proof of Concept Tools Used Manual analysis Recommended Mitigation Steps Without documentation i'm not sure if it's the expected behaviour or not. If it's not y...

deploySynth does not prevent token to be VADER or USDV

Handle paulius.eth Vulnerability details Impact function deploySynth checks that token is not VADER or not USDV. The condition should be && not || as OR condition always holds when VADER != USDV: function deploySynthaddress token external requiretoken != VADER || token != USDV;...

Anyone Can Call Init() and Lock It Forever For Attack.sol, DAO.sol, Factory.sol, Pools.sol, Router.sol, Vault.sol, and Vader.sol

Handle jvaqa Vulnerability details Impact Anyone Can Call Init and Lock It Forever For Attack.sol, DAO.sol, Factory.sol, Pools.sol, Router.sol, Vault.sol, and Vader.sol When trying to deploy vader contracts, an attacker could call init on each deployed contract and lock it, wasting the deployer's...

Handle transfers of different ERC20 tokens

Handle paulius.eth Vulnerability details Impact Some ERC20 transfers have require checks, e.g.: requireiERC20token.transfermember, amount; some don't, e.g.: iERC20token.transferrecipient, amount; It is a good practice to think about all the possible variations of ERC20s see: . Recommended...

init functions can be frontrun

Handle @cmichelio Vulnerability details Vulnerability Details The init function that initializes important contract state can be called by anyone. Impact The attacker can initialize the contract before the legitimate deployer, hoping that the victim continues to use the same contract. In the best...

Wrong slippage protection on Token -> Token trades

Handle @cmichelio Vulnerability details Vulnerability Details The Router.swapWithSynthsWithLimit allows trading token to token and specifying slippage protection. A token to token trade consists of two trades: 1. token to base 2. base to token The slippage protection of the second trade base to...

flashProof is not flash-proof

Handle @cmichelio Vulnerability details Vulnerability Details The flashProof modifier is supposed to prevent flash-loan attacks by disallowing performing several sensitive functions in the same block. However, it performs this check on tx.origin and not on an individual user address basis. This...

Missing fromToken != toToken check in MarginRouter.crossSwapExactTokensForTokens/MarginRouter.crossSwapTokensForExactTokens

Email address [email protected] Handle @cmichelio Eth address 0x6823636c2462cfdcD8d33fE53fBCD0EdbE2752ad Vulnerability details Attacker calls MarginRouter.crossSwapExactTokensForTokens with a fake pair and the same token0 == tokne1. crossSwapExactTokensForTokens1000 WETH, 0, ATTACKERCONTRACT, WETH,...