BIDSHOP

## AuctionFactoryUniversal

In the contract `AuctionFactoryUniversal` the role `_owner` has authority over the functions shown in the diagram below.
Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and do the following:

- add a pool, which can be set to a malicious contract pretending to be a typical pool to then steal users bids.
- add and remove operators, which are operators for all pools added to the factory. See the privilege for `isOperator` below in the contracts `PoolBaseLogicSlim` and `PoolRankedLogicSlim.sol`, which an attacker could use. Or an attacker could remove operators necessary to finalize auctions and deny service.
- change the bonus token to one they control, allowing them to make as many bids as the wish paying only the gas fee.
- lock the factory, preventing new pools from being added to it.
- change the `stakingTreasury` address to one they control, allowing them to collect all the rewards that are leftover from an auction after allocating the rewards to the proper ranks.
  
![](https://accelerator-tasks-prod.acc.corp.certik.com/f78d84a3544c4612b0c51c1ae4d0254d/diagrams/centralization_AuctionFactoryUniversal-AuctionFactoryUniversal-_owner.svg)

In the contract `AuctionFactoryUniversal` the role `bidRouter` has authority over the functions shown in the diagram below.
Any compromise to the `bidRouter` account may allow the hacker to take advantage of this authority and do the following:

- change the `bidRouter` address to another they control.
- add to a users volume. This can be used to add a large amount of volume for a user without the user having to make bids. If the volume is used to determine rewards, then this can be used by the attacker to be awarded an unfair share.
  
![](https://accelerator-tasks-prod.acc.corp.certik.com/f78d84a3544c4612b0c51c1ae4d0254d/diagrams/centralization_AuctionFactoryUniversal-AuctionFactoryUniversal-bidRouter.svg)

---

## PoolBaseLogicSlim

In the contract `PoolBaseLogicSlim` the role `factory` has authority over the functions shown in the diagram below.
Any compromise to the `factory` account may allow the hacker to take advantage of this authority and initialize the first round to whatever start time they wish. In addition, the `factory` is called to determine if the `msg.sender` is an operator, which gives access to the privileged functions explained below.

![](https://accelerator-tasks-prod.acc.corp.certik.com/f78d84a3544c4612b0c51c1ae4d0254d/diagrams/centralization_PoolBaseLogicSlim-PoolBaseLogicSlim-_factory.svg)

In the contract `PoolBaseLogicSlim` the role `isOperator` has authority over the functions shown in the diagram below.
Any compromise to the `isOperator` account may allow the hacker to take advantage of this authority and do the following:

- reveal and finalize a round (see PoolRankedLogicSlim for more details as this is where the function logic is implemented).
- set the round extension variables. If these are set to large values then it can prevent a round from being finalized and if they are set to small values, they can ensure that a round does not get extended.
- set the round extension manually. This can be set to 0 so that a round will not have any extension or to a large value to ensure that a round cannot be finalized.
- kill the pool, which will prevent any new bids and allow users to withdraw. If an attacker calls this before a round is finalized and then finalizes the round, then they be able to gain their original bids amount plus any winnings from the auction.
- reset the reveal process, an attacker can use this as a denial of service to continually call and prevent a round from being finalized.
  
![](https://accelerator-tasks-prod.acc.corp.certik.com/f78d84a3544c4612b0c51c1ae4d0254d/diagrams/centralization_PoolBaseLogicSlim-PoolBaseLogicSlim-isOperator.svg)

In the contract `PoolBaseLogicSlim` the role `bidRouter` has authority over the functions shown in the diagram below.
Any compromise to the `bidRouter` account may allow the hacker to take advantage of this authority and submit bids for free to an auction.
![](https://accelerator-tasks-prod.acc.corp.certik.com/f78d84a3544c4612b0c51c1ae4d0254d/diagrams/centralization_PoolBaseLogicSlim-PoolBaseLogicSlim-bidRouter.svg)

---

## PoolRankedLogicSlim

In the contract `PoolRankedLogicSlim` the role `isOperator` has authority over the functions shown in the diagram below.
Any compromise to the `isOperator` account may allow the hacker to take advantage of this authority and do the following:

- reveal all bids, which will reveal the bid amounts for each bid.
- finalize the round, which allocate tokens to the winners of an auction.
- set the ranks, which will specify the amount to be rewarded for each rank in the auction. This can be used to allocate all the rewards to the rank of an exploiter.
- feed the ranks, which takes in bids that must be put in order from higher to lower bids and the finalization process checks tha

The function `forceExpire()` in the contract `AuctionCredit` sets the `userExpiry` of the input `_user` to 0 and then expires them, which will send the funds to the team address. If a user has a large amount of unused credits that they were planning on using before they expired, this could potentially result in a large loss if this function is called before their expiry.

The function `burn()` in the contract `AuctionBonus` burns any input users bonus tokens, without checking if they have expired. If a user was planning on using a large accumulated amount of bonus tokens before they expired and they were burned, then this could potentially result in a large loss if this function is called before their expiry.

Anyone can call `claimRewards()` for any input `_user` to claim their rewards. While the rewards will be transferred to the user, this can cause confusion if a user inputs the wrong address and does not receive any tokens. In addition, if a user's rewards were claimed by someone else and they attempt to claim their rewards the call will revert and may cause confusion for the user.

From Solidity `v0.8.4`, there are more gas-efficient ways to explain to users why an operation failed than through strings. Using custom errors can significantly reduce the size of the deployed bytecode and reduce the gas cost when calls revert.

Lines for the instances of this are given for the contract `AuctionBonus`. However, this optimization can be implemented for all contracts.