OptionBlitz security record

### Treasury In the contract `Treasury` 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: - set the staking and formula contract addresses to malicious addresses. However, these can only be done once, so the contract just need to be verified after `configure()` is called; - set the gap amounts to any value they wish;  In the contract `Treasury` the role `_trustedcaller` has authority over the functions shown in the diagram below. Any compromise to the `_trustedcaller` account may allow the hacker to take advantage of this authority and do the following: - steal any BLX or USD tokens held by the contract; - use any approval a user has given to the contract to steal users USD; - lock/unlock bet collateral to potentially allow options who will not be covered; - burn any BLX held by the contract;  In the contract `Treasury` the roles `platformBeneficiary1` and `platformBeneficiary2` have authority over the functions: - withdrawPlatformOwnIncome(); - setPlatformBenificary(); Any compromise to the `platformBeneficiary1` or `platformBeneficiary2` account may allow the hacker to take advantage of this authority and steal the platform income for themselves or to set the platform beneficiary to an account that only they control. In the `Treasury` contract, the `burner` address, which is designated to receive burned tokens, is set during deployment by the deployer. While this address cannot be altered once set, if it's initially established incorrectly or if the address gets compromised, a hacker could take advantage of this authority and interfere with the burning mechanism of the protocol, for example by stealing tokens meant to be burned. --- ### AccessContract In the contract `AccessContract` 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 add themselves as a trusted addresses allowing them to execute any functions that use the `onlyTrustedCaller` modifier or to remove addresses as trusted addresses to perform a denial of service attack.  --- ### StakingRewards In the contract `StakingRewards` 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 pause or unpause the contract. Moreover, `StakingContract` inherits `StakingRewards`, giving this privileged role the ability to pause or unpause the `StakingContract`, which could be used in a denial of service attack.  --- ### StakingSnapshot In the contract `StakingSnapshot` 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 set the `stakingContractAddress` which has the privileges explained below. However, this can only be called once and then ownership is renounced, so that one needs only to verify the set contract cannot use the privileges maliciously.  In the contract `StakingSnapshot` the role `stakingContractAddress` has authority over the the following functions: - `addLoss()` - `addReward()` - `increaseTotalUSDDeposits()` - `decreaseTotalUSDDeposits()` - `updateDepositAndSnapshots()` Any compromise to the `stakingContractAddress` account may allow the hacker to take advantage of this authority and update rewards, losses, total USD deposits, user deposits, and user snapshots. This can be used by the hacker to gain more rewards than they are entitled to and drain the treasury of funds and/or it can be used to drain users deposits.  --- ### L2Burner The deployer of the contract `L2Burner` sets the layer 1 addresses of `BLX`, `L1Burner`, and the `l2GatewayRouter`. As such these can be set to malicious contracts so that tokens are not burned as designed. However, these are set upon deployment and need onl