ERC1155Enumerable._removeTokenEnumeration() checks the removal condition wrongly.

Lines of code Vulnerability details Impact ERC1155Enumerable.removeTokenEnumeration checks the removal condition wrongly. As a result, the tokens with 0 total supply won't be removed from allTokens array at all. Proof of Concept removeTokenEnumeration checks the removal condition like below when ...

A Malicious User can Lock All Funds in an Option

Lines of code Vulnerability details Impact By calling the mint and burn functions with the 'amount0' and 'amount1' equal to the the option pair's respective balances of token0 and token1, a user can cause a given option's "Option.totalLong0" and "Option.totalLong1" to both be set to 0. The effect...

Allows burning from other accounts

Lines of code Vulnerability details Impact Anyone can burn the liquidamount before maturity by calling burn in Pool.sol Proof of Concept 364 : liquidityPosition.mintliquidityAmount; liquidityAmount is minted by liquidityPosition but when burned, it is not clear who will burn liquidityAmount 452: ...

TOKEN CAN BE LOCKED WHEN THE _mint function is called to mint token to a contract that does not support the ERC1155

Lines of code Vulnerability details Impact Use safeMint intead of mint. The mint function of the TimeswapV2Token.solL110 calls the mint function of the ERC1155. If the token receiver is a contract that does not support ERC1155, the token is locked. Proof of Concept see: If the recipient contract...

Incorrect totalSupply() function design

Lines of code Vulnerability details Impact In ERC1155Enumerable.solL36-L37 line, totalsuppyl of ERC1155 is calculated packages/v2-token/src/base/ERC1155Enumerable.sol: 34 35: /// @inheritdoc IERC1155Enumerable 36: function totalSupply public view override returns uint256 37: return...

reentrancy in TimeswapV2Option.collect()

Lines of code Vulnerability details Impact collect function doesn't respect the check-effect-interaction pattern, where in the case if a param.data is provided it makes an external call to the caller, right after that, it updates option short amount state. in the case if the caller calls back int...

Rebalance logic is wrong and this distorts the pool's important states

Lines of code Vulnerability details Impact The important states including long0Balance, long1Balance, long1FeeGrowth, long1ProtocolFees are wrongly calculated and it breaks the pool's invariant. Proof of Concept The protocol provides a rebalancing functionality and the main logic is implemented i...

Loss of Long tokens when users send excess tokens to pool while minting LP tokens

Lines of code Vulnerability details Impact Protocol currently uses 2 levels of callbacks for minting: Inner Level callback: timeswapV2PoolMintChoiceCallback function in Line 349 of Pool.sol that allows users to choose Long0 and Long1 amounts such that long0 + long1converted based on strike = long...

STORAGE LOCATION OF liquidityPosition OF ONE USER IS OVERWRITEN BY THE liquidityPosition OF ANOTHER USER

Lines of code Vulnerability details Impact In the pool.sol contract under the transferFees function, the pool liquidity position of the msg.sender is assigned to the storage variable liquidityPosition. And this liquidityPosition is updated for new fee allocation and fee burning. The transaction f...

_currentIndex is incorrectly updated; breaking the ERC1155 enumerable implementation

Lines of code Vulnerability details Impact When minting and burning tokens,the ERC1155Enumerable implementation does not correctly update the following states: uint256 private allTokens; mappinguint256 = uint256 private allTokensIndex; mappingaddress = uint256 internal currentIndex; In particular...

Burn will not work if positions below to different owners

Lines of code Vulnerability details Impact When an option is created, the caller has an option of choosing any address to mint these three option positions to long0, long1, short or if the caller chooses the options can be added for the caller alone . The positons could be transferred through...

Burning a ERC1155Enumerable token doesn't remove it from the enumeration

Lines of code Vulnerability details The ERC1155Enumerable base contract used in the TimeswapV2Token and TimeswapV2LiquidityToken tokens provides a functionality to enumerate all token ids that have been minted in the contract. The logic to remove the token from the enumeration if the last token i...

Improper check for Zero Address

Lines of code Vulnerability details Impact Detailed description of the impact of this finding. There is an error in the if statement of the referenced line of code. It should check for zero address and return an error. This will prevent the creating a new contract for an existing option pair, eve...

ATTACKER CAN STEAL FUNDS BECAUSE OF REENTRANCY VULNERABILITY IN burn METHOD

Lines of code Vulnerability details Impact In burn method of TimeswapV2Option contract, there is no Reentrancy guard. The method allows a Callback function before updating the State variable, which makes method vulnerable for Reentrancy which can lead to steal of funds. Proof of Concept File:...

Anyone Can Collect The Transaction Fees

Lines of code Vulnerability details Impact collectTransactionFees is a function that should be only calles by the liquidity providers , but the the flow of the function no restriction , lets anyone collect the fees. Proof of Concept 1. Alice decides to collect the fees of pool A for example 2...

Fee on transfer tokens will not behave as expected

Lines of code Vulnerability details Impact According to Whitepaper 1.1 Permissionless: "In Timeswap, liquidity providers can create pools for any ERC20 pair, without permission. It is designed to be generalized and works for any pair of tokens, at any time frame, and at any market state ... If fe...

Using V2-Pool, user can loose money after minting, then burn due to duration calculation

Lines of code Vulnerability details Impact Users loose money over time after mint using V2-Pool due to the protocol duration calculation. The current duration calculation is calculated from now to maturity. So when the user mint, then burn the liquidity, with time the amount of short he get is...

reentrancy in TimeswapV2Option.collect()

Lines of code Vulnerability details Impact collect function doesn't respect the check-effect-interaction pattern, where in the case if a param.data is provided it makes an external call to the caller, right after that, it updates option short amount state. in the case if the caller calls back int...

User receives lesser number of Long Tokens on burning Pool liquidity resulting in loss of user funds

Lines of code Vulnerability details Impact Protocol currently uses 2 levels of callbacks for burning Pool liquidity: Inner callback - timeswapV2PoolBurnChoiceCallback function in Line 438 of Pool.sol allows user to specify long0 & long1 amount such that long0 + long1 longAmount. longAmount here...

Wrong logic in ConstantProduct.sol

Lines of code Vulnerability details Impact Wrong logic when comparing longAmount and shortAmount can lead to unexpected things Proof of Concept 108: if isAdd ? amount = shortAmount : amount = shortAmount longAmount = amount; When amount = shortAmount: If isAdd = amount = shortAmount = longAmount ...

A malicious rebalancer can imbalance the constant sum nature of long token pool by depositing a larger number of input tokens for a smaller number of output tokens. This also imbalances the constant product nature of 3 token pool

Lines of code Vulnerability details Impact Token0 and Token1 follow the properties of a constant sum pool. deltax token0 change is balanced proportionately by deltay token1 change adjusted for strike. Arbitrageurs can use the constant sum property to rebalance the pool based on the level of strik...

Incorrect totalSupply() function design

Lines of code Vulnerability details Impact In ERC1155Enumerable.solL36-L37 line, totalsuppyl of ERC1155 is calculated packages/v2-token/src/base/ERC1155Enumerable.sol: 34 35: /// @inheritdoc IERC1155Enumerable 36: function totalSupply public view override returns uint256 37: return...

Mismatch in if statement check for long0, long1 and shortAmount

Lines of code Vulnerability details Impact Detailed description of the impact of this finding. As stated in the comment of the lines referenced below, long0Amount and long1Amount could be zero but the code is wrongly implemented which could lead to unexpected behavior of the code. The 'shortAmoun...

transferFees forwards liquidityPosition without storage

Lines of code Vulnerability details Impact Currently, the transferFees function assigns in line 196 the following: liquidityPosition = pool.liquidityPositionsto; which is not a storage pointer. Proof of Concept Due to the missing storage pointer, update and mintFees functions will simply change t...

Lack of access control in certain functions within TimeswapV2LiquidityToken & TimeswapV2LiquidityToken contracts

Lines of code Vulnerability details Impact The TimeswapV2Token & TimeswapV2LiquidityToken contracts lack proper access control in sensitive functions such as mint, burn, collectFees, and updateFees. There is no modifier or "require" to check if the caller is allowed to call these functions. This...

Upgraded Q -> M from #55 [1674745091248]

Judge has assessed an item in Issue 55 as M risk. The relevant finding follows: minimum deposit amount for tokens with non standart decimals value are too high. 0.1 can be quite a lot for tokens with small totalAmount, so this requirement can become too restrictive. For example, WBTC token have 8...

The transferFeesFrom function does not check if the "from" address is the actual owner of the position before transferring the fees.

Lines of code Vulnerability details Impact The code Doesn't check if the from address is the owner of the position before transferring the fees. If the from address is not the owner of the position, an attacker could potentially transfer fees from another user's position without their permission...

Upgraded Q -> M from #598 [1674741121008]

Judge has assessed an item in Issue 598 as M risk. The relevant finding follows: Low: 1.deposit check wrong variant function deposituint256 assets, address receiver public virtual returns uint256 shares requireshares minDepositAmount, "VALUETOOSMALL"; requireassets minDepositAmount,...

[M] TimeswapV2LiquidityToken.sol#collect() Incorrect implementation causing collect always fail

Lines of code Vulnerability details Impact The function collect in the provided code is supposed to transfer transaction fees from a liquidity token position to a recipient address. However, the function currently has an issue where the long0Fees, long1Fees, and shortFees variables are not...

Upgraded Q -> M from #404 [1674736828553]

Judge has assessed an item in Issue 404 as M risk. The relevant finding follows: L‑06 Owner can renounce while system is paused The contract owner or single user with a role is not prevented from renouncing the role/ownership while the contract is paused, which would cause any user assets stored ...

Upgraded Q -> M from #269 [1674743821419]

Judge has assessed an item in Issue 269 as M risk. The relevant finding follows: 269 --- The text was updated successfully, but these errors were encountered: All reactions...

Upgraded Q -> M from #404 [1674736594739]

Judge has assessed an item in Issue 404 as M risk. The relevant finding follows: L‑04 latestAnswer is deprecated Use latestRoundData instead so that you can tell whether the answer is stale or not. The latestAnswer function returns zero if it is unable to fetch data, which may be the case if...

Upgraded Q -> M from #598 [1674741102558]

Judge has assessed an item in Issue 598 as M risk. The relevant finding follows: 2.minDepositAmount When the asset is btc, the minDepositAmount is too large when asset == btc , minDepositAmount = 0.1 btc , equal 2000 usd suggest: function minDepositAmount public view virtual overrideERC4626Cloned...

TimeswapV2LiquidityToken: collect() will always revert because it uses the wrong parameters when calling ITimeswapV2Pool.transferFees()

Lines of code Vulnerability details Proof of Concept collect uses the wrong paramenters when calling ITimeswapV2Pool.transferFees. It uses long0Fees, long1Fees, and shortFees instead of param.long0FeesDesired, param.long1FeesDesired, and param.shortFeesDesired. The former 3 are defined in the...

Upgraded Q -> H from #296 [1674743769839]

Judge has assessed an item in Issue 296 as H risk. The relevant finding follows: Lines of code Vulnerability details A malicious liquidator could cause the NFT auction to fail and steal the collateral after end of auction. Impact Anyone can act as a liquidator and trigger the liquidation of the...

Upgraded Q -> M from #258 [1674661917738]

Judge has assessed an item in Issue 258 as M risk. The relevant finding follows: L-03 Use of deprecated functions Impact The contract uses deprecated function latestAnswer. Such functions might suddenly stop working if no longer supported. Impact: Deprecated API stops working. Prices cannot be...

Upgraded Q -> M from #72 [1674644492627]

Judge has assessed an item in Issue 72 as M risk. The relevant finding follows: Low-03 NTokenMoonBirds may not be able to receive airdrops Impact For most NToken, some airdrops that are actively minted to the holder's address can be withdrawn and later distributed by the PoolAdmin calling the...

Reentrancy attack to swap()

Lines of code Vulnerability details Impact Detailed description of the impact of this finding. A malicious contract can initiate a reentrancy attack to the swap function: it can swap token0 for token1, receiving token0 but without effectively providing the due token1 amount used to mint instead...

Upgraded Q -> M from #313 [1674663275698]

Judge has assessed an item in Issue 313 as M risk. The relevant finding follows: L-07 centralization risks The owner address of PoolAddressesProvider contract has control over many dangerous functions. Such as: setAddressAsProxy, setPoolConfiguratorImpl and updatePoolImpl which are responsable fo...

Upgraded Q -> M from #80 [1674644981726]

Judge has assessed an item in Issue 80 as M risk. The relevant finding follows: LOW‑10 getPrice and combine will not work if expirationPeriod == 0 The following conditions will fail if expirationPeriod is set to 0. There is currently no limit that it cannot be set to 0. Proof Of Concept 243:...

Upgraded Q -> M from #449 [1674665297296]

Judge has assessed an item in Issue 449 as M risk. The relevant finding follows: L‑03 MintableIncentivizedERC721 does not implement ERC721.safeTransferFrom properly MintableIncentivizedERC721 is described as: 27: @notice Basic ERC721 implementation which will be used as a parent contract for...

Unchecked Token Minting: A Critical Vulnerability in Timeswap V2 Token Contract

Lines of code Vulnerability details Impact It allows an attacker to mint new tokens without proper checks and validations, which can result in an inflation of the total supply of tokens and a loss of funds for the contract's owner or users. The contract's "mint" function allows the attacker to mi...

Unsecured usage of msg.sender in smart contract functions TimeswapV2Pool.sol.

Lines of code Vulnerability details Impact The bug is related to the use of the msg.sender in the smart contract functions. The msg.sender is a built-in variable in the Solidity programming language, which represents the address of the account that called the function, the msg.sender is used to...

Upgraded Q -> M from #229 [1674661441196]

Judge has assessed an item in Issue 229 as M risk. The relevant finding follows: Support for IERC165 interface id is missed Contract: Impact: Contract fails to support a valid interface which could lead to failure of genuine calls Steps: Observe the supportsInterface function...

Missing Access Controls in Liquidity Position Library

Lines of code Vulnerability details Impact function feesEarnedOf LiquidityPosition memory liquidityPosition, uint256 long0FeeGrowth, uint256 long1FeeGrowth, uint256 shortFeeGrowth internal pure returns uint256 long0Fee, uint256 long1Fee, uint256 shortFee ... function updateLiquidityPosition stora...

Upgraded Q -> M from #472 [1674665995647]

Judge has assessed an item in Issue 472 as M risk. The relevant finding follows: L-01 CHAINLINK AGGREGATOR IS NOT SUFFICIENTLY VALIDATED AND CAN RETURN STALE ANSWER As shown below, calling the getAssetPrice function in the ParaSpaceOracle contract can execute price = uint256source.latestAnswer,...

Pool.sol: The collectProtocolFees() function can be called by anyone

Lines of code Vulnerability details Impact As specified in the documentation, the collectProtocolFees should be called only by the protocol owner. However, as this is an external function, an attacker is able to call it and to perform the actions inside the function. Proof of Concept The...

Upgraded Q -> M from #229 [1674661320954]

Judge has assessed an item in Issue 229 as M risk. The relevant finding follows: Centralization Risk Contract: Impact: It seems the poolAdmin holds too much power including changing reward controller, rescue tokens etc. This can allow poolAdmin to impact all users by changing the config or draini...

Upgraded Q -> M from #374 [1674664049404]

Judge has assessed an item in Issue 374 as M risk. The relevant finding follows: L-03 WETHGateway.repayETH will revert if msg.value paybackAmount In the repayETH function, paybackAmount eth will be deposit to WETH contract to get paybackAmount weth back. WETH.depositvalue: paybackAmount; And then...

The getMaxTreeBrackets function does not handle the case when the suffixes array cannot be created due to memory constraints.

Lines of code Vulnerability details Impact if MaxTreeHeight is set to a very large value, such as 10^9, and twoSubstringLength is also set to a large value, such as 100, then the suffixes array would require 10^9 100 bytes of memory to be created. If the contract does not have that much memory...