Swell Network Addendum

In the contract `SwellAuraVault` 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 `platformFee` value to send 100% of the `tokenBalance` collected in the contract from a call to `auraBaseRewardPool.getReward()` to the `owner()`. 

Functions that affect state variables should emit events as notifications.

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 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. ```solidity IRewards immutable auraBaseRewardPool; ``` - The contract `SwellAuraVault` interacts with third party contract with `IRewards` interface via `auraBaseRewardPool`. --- ```solidity auraDeposit = IDeposit(auraBaseRewardPool.operator()); ``` - The contract `SwellAuraVault` interacts with third party contract with `IDeposit` interface via `auraDeposit`.

The functions `_beforePositionChange()` and `_afterPositionChange()` are called through the `ERC4626` functions `withdraw()` and `deposit()` respectively. In these functions, it is the `msg.sender` whose assets are deposited and whose shares are burned. However, in the functions cited above, the address `tx.origin` is the address that receives any rewards earned. When `tx.origin` is the same as `msg.sender`, this is not an issue; however, if a contract is set up to interact with this vault, the immediate `msg.sender` address may be different than the initiator of the transaction, `tx.origin`. In such a case, the `tx.origin` would benefit from the calculated reward being added to their `record.unclaimedRewards` running sum. This is possible if `tx.origin` initiates a call to `deposit()` since the address will have a recorded balance in the `userRecords` mapping. In the case where `tx.origin` is different from `msg.sender` but `tx.origin` does not have a balance, no one receives a reward update to their record, since reward calculations are based off the balance of the `tx.origin` address.