Summary

Protocol assumes that all loan tokens and collateral tokens will be 18 decimals. Since sponsor mentions it has to work with ERC20's without providing any more restrictions, tokens that are not 18 decimals can be used and they are not working as expected.

Vulnerability Details

Calculations in the protocol assumes that both tokens are 18 decimals. Let's examine one example and break the protocols promised functionality.

1- LTV Calculations in Lender.sol:

Since there is a 1e18 multiplier in numerator, we can safely assume that pool.maxLoanRatio parameter is expected to have 18 decimals.
If:

a) collateral token has less than 18 decimals (let's say 8), loanRatio will have 28 decimals. Hence below check will always revert:

and it won't be possible to borrow from that pool.
b) debt token has less than 18 decimals (let's say 8), loanRatio will have 8 decimals. Hence check provided above will never return (unless 1e10*(decimal) amount of token provided) and borrower will be able to borrow much more than lender accepted. Since there is no way to get debt tokens back without borrower's permission (even if lender liquidate it via auction, they will only get collateral token back) lender will lose significant amount of funds.

Impact

Direct loss of funds, hence I consider this as high.

Tools Used

Manual Review

Recommendations

Check for token's decimal before calculations and change calculations accordingly. For example in the provided example one solution can be:

Instead of multiplying with " 10 ** 18 " multiply with " maxLoanRatioDecimal - int256(debtTokenDecimal - collateralTokenDecimal)".