YoloRekt security record

Functions updateTracking and bumpDuringUpgrade are supposed to be called by NFTTracker and YoloNFTPack respectively. However, the modifier utilized i.e onlyAuthorized expands this capability to anyone having: • NFT_TRACKER or YOLO_NFT_PACK role in BiddersRewards • NFT_TRACKER or YOLO_NFT_PACK role in associated YoloRegistry of BiddersRewards • DEFAULT_ADMIN_ROLE or ADMIN_ROLE role in associated YoloRegistry of BiddersRewards can call the concerned functions. This widens up the attack surface, as authorized roles may take advantage of their privileged roles and may use these functions to exploit rewards.

It is possible to bid 0 amount or even very low amounts via the makeMarketBid function. Thus the MAX_BIDS limit can be reached quickly if one is allowed to bid 0 amount of tokens. This could result in manipulation of gamerounds in order to win or deny other people from bidding.

updatetracking is done in bidInYolo based on the nft id for tracking bids for cumulative rewards which is fetched from usersTokens. But usersTokens from yoloNFTPack (which inherits from ERC1155SemiFungible) is used to fetch the token id which could get overwritten each time a token is transferred to an account.A user can exploit this by minting new nft for himself, then placing a bid such that bidCount increases by 1, then claiming rewards from BiddersRewards by calling harvest, then again minting a new nft that overwrites its previous nft tracked by usersTokens, then placing a bid such that bidCount increases by 1(possible because the id of this new nft is different) and then claiming rewards by calling harvest again. harvest() function gives more weight to the bidCount. So this exploit can be highly profitable to any user.

The withdraw function allows the admin to withdraw all the funds from the contract at any point of time. A malicious admin can exploit this and drain the contract of all the funds.

Referring to L3, releaseFunds has a strict condition, that rewardsMultiplier should be set for all the levels, and if any level’s rewardsMultiplier is not set, the entire function will revert. Authorized roles may take advantage and set any existing level’s rewardsMultiplier as 0, thus disallowing the release of funds

yolosharetokens contract comes with burnFrom function as well, which imposes the same risk of unintended share manipulation. If devs plan to revert this function as well, then ERC20Burnable can be removed from yolosharetokens as there will be no more use afterwards.

The uint space for bidCount and cumulativeBidAmount for a single NFT Id is considered as uint64 and uint192 respectively, whereas, for level tracking, the same uint space has been considered. However, logically, a level is supposed to have a bigger uint space as it will be accommodating all the NFT IDs of this level.

The settlementPrice and nextStrikePrice parameters can be manipulated by admin in order to favour specific bidders.

Functions encodeNewNonFungibleBaseType and encodeNewSemiFungibleBaseType allows encoding new basetypes. The functions expect and allow a uint256(0 - 2^256-1) value to be encoded. However, the maximum value that can be encoded or the last available nonce that can be encoded as a basetype is 2^126-1, which means values >=2^126, will start overlapping/colliding with existing baseTypes.

Referring to A.1, _nftNonce and _semiFtNonce are supposed to act as counter/nonce to create new baseTypes. They are of type uint120 and the maximum value they can hold is 2^120-1. However, the possible base types that can be created are 2^126-1 (considering 1 as the first baseType), as a consequence, the nonces will not able to accommodate all the possible base types. Contrary, it acts as a protection to avoid collisions(Refer. A.1) of base types that can happen after value 2^126-1, as the next uint type after uint120 is uint128, now opting to uint128 will open doors for collisions as the values can go more than 2^126-1