WeMix - bridge audit 1

The following contracts contain Privileged functions that can only call by privileged roles. Privileged functions can be used to modify the bridge's configurations and move assets from the bridge. Any compromise to one or more privileged accounts may allow a hacker to take advantage of this authority and alter the bridge configuration, take full control of the bridge, and withdraw assets from the bridge. In the contract `WERC20`, the role `minter` has authority over the following functions: - mint() - burn() Any compromise to the `minter` account may allow the hacker to take advantage of this authority and - mint WERC20 tokens for any address - burn WERC20 tokens from any address In the contract `WemixWERCDeployer`, the role `_owner` has authority over the following functions: - deployWERC20() In the contract `WemixBridgeStorage`, the role `_owner` has authority over the functions. - addBridgeAddress() - removeBridgeAddress() Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and - add a new bridge address to the `bridge` list - remove the bridge from the `bridge` list In the contract `WemixBridgeStorage`, the role `bridge` has authority over the following functions: - setTokenId() - setToken() - deleteTokenId() - deleteToken() - updateTokenAddr() - updateIncomeFee() - updateFeeAb() - updateMintable() - updateLock() - updateHome() - updateUniDir() Any compromise to the `bridge` account may allow the hacker to take advantage of this authority and - set token id - set token info - delete token id - delete token info - update the configurations of the token In the contract `WemixBridgeV2`, the role `_owner` has authority over the functions. - pause() - unpause() - addToken() - removeToken() - approveTokens() Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and - pause/unpause the contract - add supported tokens to bridge - remove supported tokens from the bridge - approve tokens when WemixBridgeV2 contract is redistributed **In the contract `WemixBridgeV2`, the role `recipient` gains full control of the token deposited in the contract.** Any compromise to the `recipient` account may allow the hacker to take advantage of this authority and - **steal all tokens in the bridge contract** In the contract `WemixBridgeV2`, the role `editor` has authority over the functions. - lockToken() - unlockToken() - changeFeeRate() - updateRecipientAddr() - updateValidatorAddr() - updateEditorAddr() - updateSenderAddr（） Any compromise to the `editor` account may allow the hacker to take advantage of this authority and - **lock/unlock token** - **change the fee rate of the bridge** - **update the address of the recipient role contract** - **update the address of the validator role contract** - **update the address of the editor role contract** - **update the address of the sender role contract** In the contract `RecipientRoleV3`, the role `_owner` has authority over the following functions: - addService() - removeService() - changeRecipient() - changeServiceRecipient() Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and - register the recipient of the service - remove registered service - change the token's recipient of a registered service - change the service's recipient of a registered service

The current signature validation scheme in contract `WemixBridgeV2` is as follows: ```solidity=292 // multi sig validation for(uint i = 0; i < sigNum; i++){ bytes calldata sig = signatures[i*65:(i+1)*65]; bytes memory message = abi.encodePacked(id_, ca_, tokenAddr_, from_, to_, fromChain_, txHash_, amount_); if(_validatorRole.isValidatorSig(message, sig) == true){ validatedSigNum++; } } // count valid signatures num require(validatedSigNum > SafeMath.div(_validatorRole.numberValidators(),2), "WemixBridge: fail to satisfy sufficient number of valid sig"); ``` This scheme does not follow EIP-712 standard. If the contract is intended to be deployed on multiple blockchains, non-standard signature scheme might cause signature collision and cross-chain replay attacks. See [EIP-712 standard](https://eips.ethereum.org/EIPS/eip-712) for more details.

All the contracts in the project use Solidity version 0.6.x, which is a version introduced more than two years ago. Outdated versions might contain security issues and miss the new features and security enhancements included in the recent solidity version.