Peerblue Exchange security record

According to the contract logic, the `closeTimestamp` is an important variable for the entire protocol and needs to be accurate. However, if there is an increase in transaction volumes in the blockchain, the network becomes congested. Hence the `closeTimestamp` could be different from the expected value in the lock phase. Additionally, the operator can cause the same result if not executed properly. Then the original `endRound` call at that time might fail because of the check failure `block.timestamp >= rounds[epoch].closeTimestamp` at line 1404. And the admin has to manually execute the rounds, which may be a great concern because the price updates turn out to be manually updated rather than timed triggering, affecting the fairness of the round. The delay of the `closeTimestamp` will always affect new rounds, making time-triggering price updates impossible.

Each round starts when the previous round is locked, and the call time needs to match the time window of the lock phase and end phase. So it seems impossible to implement periodic rounds and it relies on the server or administrator to execute the rounds. Due to the time windows and the fact that prices change all the time, the timing of the operator call becomes very important. If the price change is slight, calling the function at any point within the time window will always make users from one side dissatisfied especially when the price is stable and the price. We would like the team to elaborate more on the operator calls to check if it is reliable and fair enough to satisfy the users' needs.

Addresses should be checked before assignment or external call to make sure they are not zero addresses. ```solidity=900 adminAddress = _adminAddress; ``` - `_adminAddress` is not zero-checked before being used. --- ```solidity=901 operatorAddress = _operatorAddress; ``` - `_operatorAddress` is not zero-checked before being used.