ERCx Test suites

What's being tested in ERCx

Details of the test levels

ERCx runs property tests. The properties and the corresponding tests are described in the tables below. Each test has its own row, indicating the conformance level of that test (ABI, Minimal, Recommended, and Desirable) the name of that test (as displayed in the report) and an informal description of the property being tested. Test levels are understood as follows.

  • Tests of level ABI (Signature) check the signatures (i.e., name, inputs, and outputs) of the token functions/events.

  • Tests of level Standard check obligations and recommendations from the standard, i.e., the properties that contain the keywords MUST and SHOULD respectively, but also any property stated in the respective EIP specification.

  • Tests of level Security check properties we deem important to the sane functioning of a token and complement the standard specification. Some of these properties were violated in ERC-20 hacks. Some othesr consider additional functions not in the standard. Examples of security properties include (i) self-transferring tokens is allowed but must not modify the balance (ii) increase of allowance should rely on an increaseAllowance function.

  • Tests of level Features check feature properties of the contract; these are neither desirable nor undesirable properties but indicate implementation choices of the contract. Examples of fingerprint properties include the infinite approval property; which holds if once the approval is set to type(uint256).max, it is not decreased by transferFrom operations.

Outcomes of test results

  • Pass: The token has passed the check as stated in the property description.

  • Fail: The token has failed the check as stated in the property description. To know more about the possible reason/s of the failed test, you can simply click on the failed test's feedback description and find out more from the json output displayed. Fields such as reason, decoded_logs could provide more insights to why the test failed. Some possible reasons that you could see are:

    • stdStorage find(StdStorage): Slot(s) not found. - There are some inaccessibility issues with the storage slots of the token and as a result, we are unable to initialize tokens to the intended dummy users.

    • EvmError: Revert - Some functions reverted when called during the execution of the test suite.

    • Any other reasons, e.g., Error: Assertion Failed - The token indeed does not satisfy all these properties OR there are some issues with the token's transfer or minting function which result in insufficient tokens to test the intended property.

    However, if the test failed unexpectedly, i.e., false negative, please contact us so that we can resolve the issue ASAP.

  • Inconclusive: A test is inconclusive if EITHER (a) it is an ABI test of an optional function OR (b) its result is inconclusive as certain conditions are not met while testing the said property test. Some possible reasons for a test to be inconclusive are failure to deal tokens to dummy users before running the test and failure to call the required function before making the property check especially in cases where large values of inputs are used in the test. Note that inconclusive tests from non-ABI levels are still important property tests that a token should satisfy. Thus, it is essential to manually check whether the token satisfies those properties. If the reason The 'vm.assume' cheatcode rejected too many inputs (65536 allowed) is shown in the reason field, then the test is considered as inconclusive as the test suite cannot generate sufficient appropriate inputs required to satisfy the assumptions in the test.

Specifications of property tests

In the below description of properties, we use the following terminology:

  • tokenSender: address that sends tokens (usually in a transaction);

  • tokenReceiver: address that receives tokens (usually in a transaction);

  • tokenApprover: address that approves tokens (usually in an approval);

  • tokenApprovee: address that tokenApprover approves (usually in an approval).

ERC-20 test suite

ERC-721 test suite

ERC-1155 test suite

ERC-4626 test suite

For ERC-4626 test suite, there are several tests with the phrase "up todelta-approximation" in their test descriptions. These are the tests where calling of functions such as deposit,withdraw, etc, are being carried out and conversation of shares to assets, and vice-versa, will take place. As math operations in Solidity is done entirely using fixed-point (i.e., no decimal value), rounding errors may occur if the contract does not follow the required rounding rules stated in the EIP-4626 standard. However, in the event where the contract does not follow the required rounding rules, there is a global uint256 variable, delta, for the test suite where the user can set to provide some leeway for such errors. This delta value represents the maximum approximation error size (an absolute value given in the smallest unit such as Wei) whenever equality assertion check is carried out. For example, x - y <= delta is being checked whenever there is a check for x == y. It is important to note that delta should only be set to a reasonable small value so that the adversarial profit of exploiting such rounding errors stays relatively small compared to the gas cost. The default value of delta is set to 0 as all tests are supposed to pass at this value if the contract follows the required rounding rules.

Last updated