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
- 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
Possible reasons for failed tests
For most of the tests at non-ABI level, we will initialize tokens to dummy users for each test before we test the intended property. In the event where many of non-ABI tests fails, you can click and refer to the reason of each failing tests to find out the possible
reason why it failed:
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. Thus, the results from the test evaluation are inconclusive.
EvmError: Revert- Some functions reverted when called during the execution of the test suite. Please check if the subjected function in the contract revert unexpectedly.
The 'vm.assume' cheatcode rejected too many inputs- The test suite cannot generate appropriate inputs required for the functions called in the test. Please check if there is any inappropriate limit set for the inputs of the subjected function.
Arithmetic over/underflow- Some inputs caused the subjected function to have arithmetic over/underflow. This usually occurs when there is some issue with the arithmetic operation within the function, e.g., the
redeemfunction of ERC-4626 token. Please check that the limits as specified by the respective EIP standard is followed. Note that our test suites follow limits (if any) from Openzeppelin implementations. If your contract is implementing other forms of limits, the results from the test evaluation are inconclusive.
- Any other reasons, e.g.,
Error: Assertion Failedor
NULL- 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.
If there are too many unexpected failed tests, please contact us so that we can resolve the issue ASAP.
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).
Tests of level ABI (Signature) check the signatures (i.e., name, inputs, and outputs) of the token functions/events.
delta-approximation" in their test descriptions. These are the tests where calling of functions such as
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
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.