What's being tested?

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.
  • The 'vm.assume' cheatcode rejected too many inputs (65536 allowed) - The test suite cannot generate appropriate inputs required for the functions called in the test.
  • 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.

Details 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).