saviswap

To bridge the gap in trust between the administrators need to express a sincere attitude regarding the consideration of the administrator teamʼs anonymity. The `onlyCommittee` of `Committee` has the responsibility to notify users about the following capabilities: - set `newPerformer` through `setPerformBySigs()` - set `newFeeTo` through `setFeeToBySigs()` - set `newFeeRate` through `setFeeRateBySigs()` - set `newOwner` through `transferContractOwnerBySigs()` - call function with `bytecode` through `functionCallBySigs()` - add new member through `addCommiteeMember()` - remove member through `removeCommiteeMember()` - initial selector mapping through `initSelectorMap()` - set `minimumSigs` through `setMinimumSigs()` - upgrade committee contract through `upgradeToBySigs()` The `Owner` of `Performer` has the responsibility to notify users about the following capabilities: - set `swap` through `setSwap()`

In the contract `AdapterManage` 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: - add the router to the router group through `registerAdapter()` - remove the router from the router group through `removeAdapter()` 

In the contract `FeeTo` 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: - set `feeTo` through `setFeeTo()` - set `feeRate` through `setFeeRate()` - withdraw ETH/BNB through `syncEth()` - withdraw tokens through `syncToken()` 

In the contract `MultiSig` 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: - add member through `addCommiteeMember()` - remove member through `removeCommiteeMember()` - set `sigsMin` through `setSigMin()` - authorize upgrade through `_authorizeUpgrade()` 

In the contract `Swap` 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: - set `performer` through `setPerformer()` - pause the contract through `pause()` - unpause the contract through `unpause()` - authorize upgrade through `_authorizeUpgrade()` 

The contracts `Swap` and `MultiSig` are upgradeable contracts, the 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 tokens from the contract.

When transferring standard ERC20 deflationary tokens, the input amount may not be equal to the received amount due to the charged transaction fee.

The input address is not checked, and if the input address is malicious, an attacker can do something harmful, such as re-enter the function.

Malicious hackers may observe the pending transaction which will execute the `initialize` function, and launch a similar transaction but with the hacker's address of `owner` and gain the ownership of the contract.

The contract is serving as the underlying entity to interact with third-party protocols. The scope of the audit would treat those 3rd party entities as black boxes and assume their functional correctness. However, in the real world, 3rd parties may be compromised and lead to assets being lost or stolen.