Several Issues Related to Upgradeability of Contracts
We did not find a proxy contract or factory in the repository, but the README contains the following information:\\nREADME.md:L11\\n```\\nEvery Pool is a standalone smart contract. It is made upgradeable with OpenZeppelin's Proxy Upgrade Pattern.\\n```\\n\\nREADME.md:L56\\n```\\nAnd there will be multiple proxies and one implementation of the Pools, and one proxy and one implementation of EventAggregator.\\n```\\n\\nThere are several issues related to upgradeability or, generally, using the contracts as implementations for proxies. All recommendations in this report assume that it is not necessary to remain compatible with an existing deployment.\\nB. If upgradeability is supposed to work with inheritance, there should be dummy variables at the end of each contract in the inheritance hierarchy. Some of these have to be removed when “real” state variables are added. More precisely, it is conventional to use a fixed-size `uint256` array `__gap`, such that the consecutively occupied slots at the beginning (for the “real” state variables) add up to 50 with the size of the array. If state variables are added later, the gap's size has to be reduced accordingly to maintain this invariant. Currently, the contracts do not declare such a `__gap` variable.\\nC. Implementation contracts should not remain uninitalized. To prevent initialization by an attacker - which, in some cases, can have an impact on the proxy - the implementation contract's constructor should call `_disableInitializers`.
Refamiliarize yourself with the subtleties and pitfalls of upgradeable `contracts`, in particular regarding state variables and the storage gap. A lot of useful information can be found here.\\nOnly import from `contracts-upgradeable`, not from `contracts`.\\nAdd appropriately-sized storage gaps at least to `PoolModel`, `NonReentrancy`, and `EventAggregator`. (Note that adding a storage gap to `NonReentrancy` will break compatibility with existing deployments.) Ideally, add comments and warnings to each file that state variables may only be added at the end, that the storage gap's size has to be reduced accordingly, and that state variables must not be removed, rearranged, or in any way altered (e.g., type, `constant`, immutable). No state variables should ever be added to the `Pool` contract, and a comment should make that clear.\\nAdd a constructor to `Pool` and `EventAggregator` that calls `_disableInitializers`.
```\\nEvery Pool is a standalone smart contract. It is made upgradeable with OpenZeppelin's Proxy Upgrade Pattern.\\n```\\n