Lack of nonreentrant modifier or CEI pattern may lead to reentrancy

Handle 0xRajeev Vulnerability details Impact The Trader contract makes an external call to the market contract TracerPerpetualSwaps as part of executeTrade. The comments in code "// todo this could be succeptible to re-entrancy as // market is never verified” indicate that there could be a residu...

Insurance slippage reimbursement can be used to steal insurance fund

Handle cmichel Vulnerability details The Liquidation contract allows the liquidator to submit "bad" trade orders and the insurance reimburses them from the insurance fund, see Liquidation.claimReceipt. The function can be called with an orders array which does not check for duplicate orders. An...

No support for token with decimals > 18

Handle s1m0 Vulnerability details Impact The smart contract doesn't behave correctly if deployed with token that have decimals 18. Proof of Concept The functions tokenToWad and wadToToken revert if the tokenDecimals is 18. These functions are called in critical places like deposit and withdraw...

SafetyWithdraw can transfer any erc20 token

Handle pauliax Vulnerability details Impact contract TracerPerpetualSwaps is SafetyWithdraw. It allows an owner to transfer all tokens from this contract whenever he wants e.g. no protection against tracerQuoteToken, etc. Tracer representative's answer on Discord: 'safetyWithdraw isn't needed as ...

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;...

Underflow problems occurring when a token has >18 decimals

Handle tensors Vulnerability details Impact The contracts assume that all tokens will have =18 decimals. If the Tracer team are the only people deploying the contracts, and they keep this in mind, this isn't a problem. If the contracts are to be deployed by other people, this assumption should be...

Trader orders can be frontrun and users can be denied from trading

Handle cmichel Vulnerability details The Trader contract accepts two signed orders and tries to match them. Once they are matched and become filled, they can therefore not be matched against other orders anymore. This allows for a griefing attack where an attacker can deny any other user from...

SafetyWithdraw ERC20 return values not checked

Handle cmichel Vulnerability details The ERC20.transfer and ERC20.transferFrom functions return a boolean value indicating success. This parameter should be checked for success. The SafetyWithdraw.withdrawERC20Token function does not check the return value: function withdrawERC20Token address...

Bots can frontrun market maker orders and cancel orders.

Handle tensors Vulnerability details Impact Market makers will not be able to have competitive spreads or cancel their orders to update their strategies. It will be difficult for them to provide liquidity on the platform, which will hurt the platform overall. Proof of Concept In traditional finan...

Lack of return value check or use of SafeERC20 wrappers for token transfers

Handle 0xRajeev Vulnerability details Impact ERC20 tokens are specified to return a boolean value on token transfer and transferFrom. However, tokens may not adhere to the spec and return no value for success/failure. Checking the return values of ERC20 token transfers is therefore important to...

avoid paying insurance

Handle gpersoon Vulnerability details Impact It's possible to avoid paying insurance in the following way: once per hour at the right moment, do the following: ----using a flash loan, or with a large amount of tokens, call deposit of Insurance.sol to make sure that the pool is sufficiently filled...

Use of deprecated Chainlink API

Handle 0xRajeev Vulnerability details Impact The contracts use Chainlink’s deprecated API latestAnswer. Such functions might suddenly stop working if Chainlink stopped supporting deprecated APIs. Impact: Deprecated API stops working. Prices cannot be obtained. Protocol stops and contracts have to...

Malicious owner can drain the market at any time using SafetyWithdraw

Handle 0xRajeev Vulnerability details Impact The withdrawERC20Token in SafetyWithdraw inherited in TracerPerpetualSwaps is presumably a guarded launch emergency withdrawal mechanism. However, given the trust model where the market creator/owner is potentially untrusted/malicious, this is a...

Logic error in fee subtraction

Handle 0xsanson Vulnerability details Impact In LibBalances.applyTrade we need to collect a fee from the trade. The current code however subtracts a fee from the short position and adds it to the long. The correct implementation is to subtract a fee to both see TracerPerpetualSwaps.solL272. This...

Malicious owner can arbitrarily change fee to any % value

Handle 0xRajeev Vulnerability details Impact Tracer protocol like any other allows market creators to charge fees for trades. However, a malicious/greedy owner can arbitrarily change fee to any % value and without an event to observe this change or a timelock to react, there is no easy way for...

erc20 transfers do not check the return value

Handle pauliax Vulnerability details Impact When transfering erc20 tokens, functions transfer and transferFrom are used. These functions return boolean to indicate if the action was sucessfull, however, none of the usages check the returned value: collateralToken.transferFrommsg.sender,...

Insurance ERC20 return values not checked

Handle cmichel Vulnerability details The ERC20.transfer and ERC20.transferFrom functions return a boolean value indicating success. This parameter should be checked for success. The Insurance.deposit and Insurace.withdraw functions dp not check the return value: // deposit...

Unused return value from transfer()/transferFrom()

Handle JMukesh Vulnerability details Impact return value from transfer/transferFrom ensure success of the call and if not , it describe the reason for. It is usually good to add a require-statement that checks the return value or to use something like safeTransfer; unless one is sure the given...

Use of incorrect index leads to incorrect updation of funding rates

Handle 0xRajeev Vulnerability details Impact The updateFundingRate function updates the funding rate and insurance funding rate. While the instant/new funding rates are calculated correctly, the cumulative funding rate calculation is incorrect because it is always adding the instant to 0, not the...

Single-step process for critical ownership transfer

Handle 0xRajeev Vulnerability details Impact The Tracer Perpetuals Factory contract is arguably the most critical contract in the project given that it deploys all the markets. The ownership of this contract is transferred to governance address, i.e. TracerDAO, in the constructor. This critical...

prb-math not audited

Handle gpersoon Vulnerability details Impact The library prb-math documents that it is not audited by a security researcher. This means its more risky to rely on this library. Proof of Concept // The contracts have not been audited by a security researcher. Tools Used Recommended Mitigation Steps...

executeTrade can be frontrun

Handle gpersoon Vulnerability details Impact An attacker could monitor the mempool and see an executeTrade transaction. He then could checkout the parameters and see if a better trade is possible for himself. He might even create and sign a new trade and then submit the new trade via an...

Unchecked token transfers

Handle Lucius Vulnerability details Impact The functions transerFrom/transer do not revert on failure and instead simply return false. Without checks on the return values, the transfers could potentially fail silently allowing unexpected issues with certain token pools. E.G. If a user calls depos...

rug pull possible via SafetyWithdraw

Handle gpersoon Vulnerability details Impact The contract TracerPerpetualSwaps inherits from SafetyWithdraw, which means the function withdrawERC20Token is possible, This allows the projectowners to withdraw the ERC20 tokens from the contract, which can be seen as a rug pull Also the tvl variable...

User could lose underlying tokens when redeeming from the IdleYieldSource

Handle shw Vulnerability details Impact The redeemToken function in IdleYieldSource uses redeemedShare instead of redeemAmount as the input parameter when calling redeemIdleToken of the Idle yield source. As a result, users could get fewer underlying tokens than they should. Proof of Concept When...

User could lose underlying tokens when redeeming from the IdleYieldSource

Handle shw Vulnerability details Impact This submission is to clarify that the previous submission is invalid Proof of Concept At line 131 of IdleYieldSource, the use of the variable redeemedShare is correct since the input parameter of redeemIdleToken should be the amount of IdleTokens instead o...

SafeMath not completely used in yield source contracts

Handle shw Vulnerability details Impact SafeMath is not completely used at the following lines of yield source contracts, which could potentially cause arithmetic underflow and overflow: 1. line 78 in SushiYieldSource 2. line 67 in BadgerYieldSource 3. line 91 and 98 in IdleYieldSource Proof of...

Return values of ERC20 transfer and transferFrom are unchecked

Handle shw Vulnerability details Impact In the contracts BadgerYieldSource and SushiYieldSource, the return values of ERC20 transfer and transferFrom are not checked to be true, which could be false if the transferred tokens are not ERC20-compliant e.g., BADGER. In that case, the transfer fails...

Manual deposits can manipulate share price

Handle tensors Vulnerability details Impact Increasing/decreasing the balance of tokens in the pool by manually depositing them changes the values of the shares. Proof of Concept Suppose that before I swap my shares S in total for tokens T in total I deposit X tokens to the pool without getting...

Using transferFrom on ERC721 tokens

Handle shw Vulnerability details Editing on a previous submission to correct the details Impact In the function awardExternalERC721 of contract PrizePool, when awarding external ERC721 tokens to the winner, the transferFrom function is called instead of safeTransferFrom. If the winner is a contra...

Using transferFrom on ERC721 tokens

Handle shw Vulnerability details Impact In the function awardExternalERC721 of contract PrizePool, when awarding external ERC721 tokens to the winners, the transferFrom keyword is used instead of safeTransferFrom. If any winner is a contract and is not aware of incoming ERC721 tokens, the sent...

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,...

Unused return value from Transfer()/ TransferFrom()

Handle JMukesh Vulnerability details Impact return value from transfer/ transferFrom confirm the success of that function call, these return should be checked Proof of Concept Tools Used Manual analysis Recommended Mitigation Steps utilise the return value to check the success of the function ---...

The assumption that operator == to (user) may not hold leading to failed timelock deposits

Handle 0xRajeev Vulnerability details Impact The contract uses msgSender to denote an operator who is operating on behalf of the user. This is typically used for meta-transactions where the operator is an intermediary/relayer who may facilitate gasless transactions on behalf of the user. They may...

Liquidity Cap changes for active pools affect winning odds unexpectedly

Handle 0xRajeev Vulnerability details Impact Liquidity cap is useful for a guarded launch where the project gradually increases the pool cap to mitigate newly launched project risks. However, the amount of deposits for this particular protocol has a direct impact on a user's odds of winning...

Yearn vault withdrawals in redeems will always fail leading to lock/loss of user deposits

Handle 0xRajeev Vulnerability details Impact The withdrawFromVault calculates the token balance of contract before withdrawal and saves it in previousBalance. It then withdraws from the Yearn vault and calculates the token balance after withdrawal to save it in currentBalance. So currentBalance...

Test configuration carryover to production deployment limits pool users to 5

Handle 0xRajeev Vulnerability details Impact The project uses a data structure for indexing ticket tokens/users called SortitionSumTreeFactory which as explained in the overview video time 14:20-14:50 is used to capture users’ token balances in the leaves where internal nodes represent their sums...

withdraw timelock can be circumvented

Handle cmichel Vulnerability details One can withdraw the entire PrizePool deposit by circumventing the timelock. Assume the user has no credits for ease of computation: user calls withdrawWithTimelockFromuser, amount=userBalance with their entire balance. This "mints" an equivalent amount of...

BadgerYieldSource balanceOfToken share calculation seems wrong

Handle cmichel Vulnerability details When suppling to the BadgerYieldSource, some amount of badger is deposited to badgerSett and one receives badgerSett share tokens in return which are stored in the balances mapping of the user. So far this is correct. The balanceOfToken function should then...

Missing initialization checks and setters for critical parameters of maxExitFee and maxTimelockDuration

Handle 0xRajeev Vulnerability details Impact maxExitFee and maxTimelockDuration are critical parameters that impact the UX and prize rewards for users. They are initialized once in initialize without any sanity/threshold checks and also lack any setters for modifying their values later in case of...

IdleYieldSource doesn't use mantissa calculations

Handle tensors Vulnerability details Impact Because mantissa calculations are not used in this case to account for decimals, the arithmetic can zero out the number of shares or tokens that should be given. For example, say I deposit 1 token, expecting 1 share in return. On L95, if the...

Use SafeTransfer/TransferHelper for BadgerYieldSource

Handle adelamo Vulnerability details Impact The Badger token will not throw an exception if transfer/transferFrom is unsuccessful. So we could use TransferHelper/SafeTransfer in order to run the validation everything went fine. //...

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...

YearnV2YieldSource wrong subtraction in withdraw

Handle cmichel Vulnerability details YearnV2YieldSource.withdrawFromVault uses a wrong subtraction. When withdrawing from the vault one redeems yTokens for tokens, thus the token balance of the contract should increase after withdrawal. But the contract subtracts the currentBalance from the...

SushiYieldSource ERC20 return values not checked

Handle cmichel Vulnerability details The ERC20.transfer and ERC20.transferFrom functions return a boolean value indicating success. This parameter needs to be checked for success. Some tokens do not revert if the transfer failed but return false instead. It is not checked in...

BadgerYieldSource ERC20 return values not checked

Handle cmichel Vulnerability details The ERC20.transfer and ERC20.transferFrom functions return a boolean value indicating success. This parameter needs to be checked for success. Some tokens do not revert if the transfer failed but return false instead. It is not checked in...

Lack of input validation on onlyOwner critical parameters

Handle 0xRajeev Vulnerability details Impact The owner potentially untrustworthy/malicious of the prize pool is allowed to set a liquidation cap for guarded launch and the credit rate and limit parameters which affect the crucial fairness of the pool. However, there is no input validation on thes...

YieldSourcePrizePool_canAwardExternal does not work

Handle cmichel Vulnerability details The idea of YieldSourcePrizePoolcanAwardExternal seems to be to disallow awarding the interest-bearing token of the yield source, like aTokens, cTokens, yTokens. "@dev Different yield sources will hold the deposits as another kind of token: such a Compound's...

BadgerYieldSource SafeMath not used

Handle cmichel Vulnerability details BadgerYieldSource.redeemToken: no usage of SafeMath can lead to overflows here as the amount parameter is chosen by the attacker. amount.multotalShares + totalShares Impact It does most likely not have an impact, we still recommend using SafeMath. Recommended...

safeApprove() for Yearn Vault may revert preventing deposits causing DoS

Handle 0xRajeev Vulnerability details Impact The depositInVault function for Yearn yield source uses ERC20 safeApprove from OpenZeppelin's SafeERC20 library to give maximum allowance to the Yearn Vault address if the current allowance is less than contract’s token balance. However, the safeApprov...