REUP

In the contract `UpgradeableBase`, the role `_owner` has authority over the following functions: - upgradeTo() - upgradeToAndCall() Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and upgrade the contract to malicious implementations. In the contract `SelfStakingERC20` the role `SelfStakingERC20Owner` has authority over the following functions: - setExcluded() - addReward() - setDelegatedClaimer() - setRewardManager() Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and - Nuke owed reward from any account In the contract `RECoverable` the role `RECoverableOwner` has authority over the following functions: - recoverERC20() - recoverNative() Any compromise to the `RECoverableOwner` account may allow the hacker to take advantage of this authority and - Recover stable coins and native tokens from `REUP` protocol contracts In the contract `RECurveMintedRewards` the role `RewardManager` has authority over the following functions: - sendRewards() - sendAndSetRewardRate() Any compromise to the `RewardManager` account may allow the hacker to take advantage of this authority and - set reward rates - mint arbitrary amount of reward tokens and deposit them into the gauge contract In the contract `REStablecoins` the role `_owner` has authority over the following functions. - addStablecoin() - removeStablecoin() Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and - add arbitrary token as a supported stablecoin, which can be swapped 1:1 into REUSD in the `REUSDMinter` contract - remove supported stablecoin In the contract `REUP`, the role `MinterRole` has authority over the following function. - mint() Any compromise to the `MinterRole` account may allow the hacker to take advantage of this authority and mint tokens to any account.

Contracts in the `REUP` protocol are upgradeable contracts, the project owner can upgrade the contract without the community's commitment. If an attacker compromises the account, he can change the implementation of the contract and drain assets from the contract.

The `bridgeable` contract serves as the underlying entity to interact with the external dependency `bridge`. The bridge (an off-chain process) can sign instructions for minting, which users can submit to the blockchain. The scope of the audit treats component that is out of scope as black boxes and assumes their functional correctness.

Linked contracts in this project serve as the underlying entity to interact with the third-party protocol `Curve`. The scope of the audit treats third-party entities(Curve pool, Curve gauge, etc) as black boxes and assumes 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.