Unreal Finance security record

In the contract `Core` 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 change the implementation through `upgradeTo()`. In turn, since this contract is the owner of each futures contract and is meant to be the owner of the `Treasury` contract, tokens can be sent to unintended address from each.  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 send underlying asset tokens to unintended addresses, draining tokens from the contract.  In the contract `AFuture` 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 mint an unbounded number of `oT` tokens, then burning them in exchange for the underlying asset token through the `Core` contract.  In the contract `AaveV3Future` 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 mint an unbounded number of `oT` tokens, then burning them in exchange for the underlying asset token through the `Core` contract.  In the contract `CFuture` 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 mint an unbounded number of `oT` tokens, then burning them in exchange for the underlying asset token through the `Core` contract.  In the contract `YFuture` 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 mint an unbounded number of `oT` tokens, then burning them in exchange for the underlying asset token through the `Core` contract.  In the contract `FutureBase` 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 mint an unbounded number of `oT` tokens, then burning them in exchange for the underlying asset token through the `Core` contract.  In the contract `FutureBase` the role `treasury` has authority over the functions shown in the diagram below. Any compromise to the `treasury` account may allow the hacker to take advantage of this authority and call `expire()` which calls internal `withdraw()`, sending all underlying asset tokens to the `treasury` address.  In the contract `OwnershipToken` the role `MINTER_ROLE` has authority over the functions `burn()` and `mint()`. Any compromise to the `MINTER_ROLE` account may allow the hacker to take advantage of this authority and mint an unbounded number of tokens to an unintended address, which could then be exchanged for the underlying asset via the `Core` contract. Moreover, the hacker could burn any amount of tokens from any holding address. The same `MINTER_ROLE` vulnerability occurs in `YieldToken`. In the contract `OwnershipToken` the role `ADMIN_ROLE` has authority over updating the `MINTER_ROLE`. Any compromise to the `ADMIN_ROLE` account may allow the hacker to take advantage of this authority and change the `MINTER_ROLE` to an unintended address. The same `ADMIN_ROLE` vulnerability occurs in `YieldToken`.

`Core` is an upgradeable contract; the owner can upgrade the contract without the community's consent. If an attacker compromises the account, he or she can change the implementation of the contract and drain tokens from the contract.

The order of external call/transfer and storage updates should follow the check-effect-interaction pattern.

The contract is serving as the underlying entity to interact with one or more third party protocols. The scope of the audit treats third party entities as black boxes and assume their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties, migrating to new LP pools, etc. ```solidity=20 address public immutable underlying; ``` - The contract `FutureBase` interacts with third party contract via `underlying`. --- ```solidity=16 ILendingPoolAddressesProvider private provider; ``` - The contract `AFuture` interacts with third party contract with `ILendingPoolAddressesProvider` interface via `provider`. --- ```solidity=16 IPoolAddressesProvider private provider; ``` - The contract `AaveV3Future` interacts with third party contract with `IPoolAddressesProvider` interface via `provider`. --- ```solidity=15 CTokenInterface private cToken; ``` - The contract `CFuture` interacts with third party contract with `CTokenInterface` interface via `cToken`. --- ```solidity=12 IVault private yVault; ``` - The contract `YFuture` interacts with third party contract with `IVault` interface via `yVault`.