Upgraded Q -> 2 from #898 [1683143849953]

Judge has assessed an item in Issue 898 as 2 risk. The relevant finding follows: Royalty receiver will not get correct royalty as saleprice is not calculated properly uint256 salePrice = outputAmount / sellsi.tokenIds.length; Here the salesprice for an nft is calculated by using the above formula...

Upgraded Q -> 2 from #215 [1683053585771]

Judge has assessed an item in Issue 215 as 2 risk. The relevant finding follows: QA10 Both EthRouterbuy and EthRoutersell do not check whether recipient == address0, as a result, they might send royalty fees to the zero address - loss of funds. --- The text was updated successfully, but these...

Upgraded Q -> 3 from #284 [1683017290576]

Judge has assessed an item in Issue 284 as 3 risk. The relevant finding follows: NFT tokens sent to the EthRouter contract by mistake can be drained by pool contracts. When someone calls sell, deposit or change functions on EthRouter contract, the contract gives the particular pool full approval...

EthRouter large positive slippage stealing via PrivatePool reconfiguration

Lines of code Vulnerability details Impact In a high volatility pool with super valuable NFTs, there may be a large positive slippage that cannot be stolen by regular actors due to the high price step for each individual NFT, but it can be easily stolen by a pool owner's MEV bot that front-runs t...

No check for minPrice and maxPrice in the deposit() function

Lines of code Vulnerability details Impact No check for minPrice and maxPrice in the deposit function could lead to unexpected consequences Proof of Concept In the function deposit function deposit address payable privatePool, address nft, uint256 calldata tokenIds, uint256 minPrice, uint256...