Medium

A protocol invariant regarding the holding of an ERC20 token can be broken

Summary

According to the README, we see this:

What properties/invariants do you want to hold even if breaking them has a low/unknown impact?

The invariants can be found in the PredictDotLoan_Invariants contract (PredictDotLoan.Invariants.t.sol).

There, we can see this invariant:

    /**
     * Invariant A: predict.loan should never hold any ERC-20 tokens.
     */
    function invariant_A() public view {
        assertEq(mockERC20.balanceOf(address(predictDotLoan)), 0);
    }

However, this can be easily broken by just transferring an ERC20 token to the contract directly.

Root Cause

There is nothing that can disallow the transfer of an ERC20 token to the contract

Internal pre-conditions

No internal pre-conditions

External pre-conditions

No external pre-conditions

Attack Path

Someone sends ERC20 tokens to the contract

Impact

Core protocol invariant is broken. According to the rules, this is a valid medium:

The protocol team can use the README (and only the README) to define language that indicates the codebase's restrictions and/or expected functionality. Additionally, the protocol team can use only the following question to define the protocol's invariants/properties:

What properties/invariants do you want to hold even if breaking them has a low/unknown impact?

Issues that break the invariants from the above question, irrespective of whether the impact is low/unknown, will be assigned Medium severity.

PoC

No response

Mitigation