Wemix Retainer 125 WemixPayment Contract

In the contract `PaymentCoreV2` the role `paymentSetter` has authority over the functions shown in the diagram below. Any compromise to the `paymentSetter` account may allow the hacker to take advantage of this authority and: - function `setRouter()`, to set swap router. - function `setDeadline()`, to set swap deadline. - function `setSlippage()`, to set swap slippage. - function `setExp()`, to set refundable period. - function `registService()`, to regist service info. - function `removeService()`, to remove registered service. - function `registToken()`, to regist token address. - function `removeToken()`, to remove token address. - function `changeServiceExecutability()`, to change status of service's selector. - function `changeRoleManager()`, to change role manager address. - function `changeExecuteManager()`, to change execute manager address. - function `changeListManager()`, to change blackOrWhiteList address. - function `changeRecipientRole()`, to change recipientRole address. - function `changeWWEMIX()`, to change blackOrWhiteList address.  In the contract `WemixPaymentLogic` 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.  In the contract `WemixPaymentLogic` the role `paymentSetter` has authority over the functions shown in the diagram below. Any compromise to the `paymentSetter` account may allow the hacker to take advantage of this authority and: - function `removeService()`, to remove registered service. 

In the contracts `PaymentCoreV2` and `WemixPaymentLogic`, the role `admin` has the authority to update the implementation contracts behind the proxy contracts. Any compromise to the `admin` account may allow a hacker to take advantage of this authority and change the implementation contract which is pointed by proxy and therefore execute potential malicious functionality in the implementation contract.

The contract's dependency on a single DEX pair for price feeds in the `swapPay` and `suggestSwapInAmount` functions makes them susceptible to flashloan attacks. An attacker could use a flashloan to exploit this vulnerability, either by amplifying profits or manipulating the token price on decentralized exchanges.

The audited code base interacts with several out-of-scope contracts, including `roleManager`, `executeManager`, `recipientRole`, `listManager`, and `IMSWWithdrawImmediately` etc. The scope of the audit treats out-of-scope entities as black boxes and assumes their functional correctness. However, in the real world, those dependencies can be compromised and this may lead to lost or stolen assets.

The current implementation of signed messages in the contract omits the inclusion of the sender's address and a domain separator. Having no domain separator allows the signature to be reused on other contracts or chains. The `_checkAuth` function is intended to ensure that the sender's address is not blacklisted. However, since the sender's address is not included in the signed message, the signature holder can bypass this check by using any other address during verification. Even if the original signer (who might be blacklisted) holds the signature, they can delegate it to a non-blacklisted address, circumventing the intended security measure. This vulnerability can be particularly exploited in the pay and swapPay functions.

The linked statements do not affect the functionality of the codebase and appear to be either remnants of test code or older functionality.

A state variable is shadowing another component defined in a parent contract. Variable `deadline` in `PaymentStorageV2` shadows the variable `PayInfo.deadline` in `IPaymentSturct`.

The linked functions are equivalent to the compiler-generated getter functions for the respective variables.