DEFED

In the contract `AssetManagement`, the role `owner` has authority over the following function(s): - function `widthdraw()` and `withdrawETH()`, to withdraw money from the contract. - function `activeToken()` and `pauseToken()`, to manege the supported tokens. In the contract `BridgeControl`, the role `owner` has authority over the following function(s): - function `setVirtualDefedToken()`, to set `virtualDefedToken` and `veDEFE`. - function `transferFromEthereumForDeposit()`, `transferFromEthereumForRepay()` and `transferFromEthereum()`, to mint `vToken` for the user and interact with `LendingPool`(deposit or repay). - function `lockFromEthereum()`, to lock `defe` for the user. - function `turnOutToken()` (added in commit 3dbe95d01202b37aa139702e95f3150705eb8c7a), to withdraw tokens from the contract. Any compromise to the `owner` account may allow a hacker to take advantage of this authority and bring unpredictable damages to the project.

We understand the team needs to receive the parameter `tokenController` to read its configs as the contract is a proxy contract for `userProxy` contracts to perform delegate calls. But it is very dangerous behavior to allow the caller to decide which contract to interact with. The events in the contract `TokenController` are untrusted.

Cross-chain token transfer depends on third-party cross-chain protocol, for example, PolyNetwork. If the cross-chain protocol is hacked, the `BridgeControl` protocol in the source chain cannot confirm the transaction status correctly. As a result, the user deposits tokens in the source chain but cannot receive them in the target chain. The server is responsible for responding to on-chain events, maintaining transaction information, and executing across the chain. It needs reliable logic to support it. This part is not in the audit scope.

Tokens are sent to the address `misc` when deploying the contract. This could be a centralization risk as the address `misc` can distribute tokens without obtaining the consensus of the community.

In Ethereum, `send/transfer/call` can be used for ETH transferring. In the worst case, the `receive` and `fallback` functions can only rely on 2300 gas being available (for example when `send` or `transfer` is used), leaving little room to perform other operations except basic logging. If the contract `AssetManagement` is going to be deployed with proxy, since the certain version of proxy codes will do delegate calls in the receive() function, the below code in the function withdrawETH() will revert because of insufficient gas exception. ```solidity IWETH(WETH).withdraw(amount); ```