Summary

The protocol aims to work with all ERC20 tokens which are accepted in farm contracts, based on the information provided in the readme, however, the permit functions will not work with certain tokens like DAI, which do not follow the EIP2612 standard.

Vulnerability Details

From TokenFacet.sol and TokenSupportFacet.sol , the permit functions can be seem which is intended to allow users to access the permit functionalities of the tokens they'd like to approve. The problem is that the function signature provided doesn't account for tokens with Dai like permit signature which features a nonce in addition to the other parameters.

In TokenFacet.sol, permitToken calls LibTokenPermit.permit using the owner, spender, token, value, deadline, v, r, s parameters.

The same can be observed In TokenSupportFacet.sol, in which the token's permit function is queried using then owner, spender, value, deadline, v, r, s parameters.

However, Dai and its equivalents have a permit function that looks like this.

This means that due to the missing nonce field, DAI, a token that allows permit based interactions, cannot be used with signed messages as the permit transactions will revert.

Some tokens also have phantom permits, WETH for example, which do not revert on call to the permit function even though the tokens lack the permit function, which can lead to malicious approvals on behalf of the token owners.

Impact

Unexpected behaviour due to tokens with non standard permits, including failures and phantom approvals.

Tools Used

Manual Code Review, Reference

Recommendations

Consider introducing a different implementation of the permit functions which allows a nonce variable. An implementation like that of Uniswap Permit2 may also help.