Limited test suite

When building a complex contract ecosystem with multiple moving parts and dependencies, comprehensive testing is essential. This includes testing for both positive and negative scenarios. Positive tests should verify that each function's side effect is as expected, while negative tests should cover every revert, preferably in every logical branch.

The test coverage for this project should be expanded to include all contracts, not just surface-level functions. It is important to test the invariants required for ensuring security and also verify mathematical properties as specified in the white paper.

Tests should be added for functions that currently have no coverage at all, such as

• both insuranceFundWithdraw functions

• insuranceFundDeposit(address account, uint256 amount)

• setMakerFeeRates

• setAccountFeeTier

• setTakerFeeRates

• setTickSize

• revokeAdmin

• disapproveOperator

Additionally, functions createMarket, settleFunding, insuranceFundDeposit, grantAdmin, and setIndexPrice do not have negative tests for the case that the caller is not an admin.

Therefore, we recommend building a rigorous test suite that includes all contracts to ensure that the system operates securely and as intended.

Good test coverage has multiple effects.

• It finds bugs and design flaws early (preaudit or prerelease).

• It gives insight into areas for optimization.

• It displays code maturity.

• It bolsters customer trust in your product.

• It improves understanding of how the code functions, integrates, and operates — for developers and auditors alike.

• It increases development velocity long-term.

The last point seems contradictory, given the time investment to create and maintain tests. To expand upon that, tests help developers trust their own changes. It is difficult to know if a code refactor — or even just a small one-line fix — breaks something if there are no tests. This is especially true for new developers or those returning to the code after a prolonged absence. Tests have your back here. They are an indicator that the existing functionality most likely was not broken by your change to the code.

A limited test suite may lead to

• an increased risk of undetected bugs, especially in edge cases or complex logic paths (e.g., partial fills, liquidation boundaries, or debt edge states);

• a higher likelihood of regressions when code is changed or optimized; and

• a reduced ability to detect inconsistent or unintended state changes, particularly in critical areas like collateral, unrealized/realized PNL, open interest, user balances, and debt tracking.

We recommend to improve the test suite to ensure the following:

• Full functional coverage of all public and internal functions

• Edge-case scenarios (zero values, minimum and maximum values, underflow/overflow boundaries)

• Error-condition testing (e.g., reverts, unauthorized access, failed transfers)

• State assertions after every action, validating that all relevant variables have changed (or not changed) as expected, no unexpected side effects occurred, and balances, positions, and mappings are updated correctly

Additional test-case ideas are outlined in the threat model, section (), and could serve as a foundation for expanding coverage.