Nayms 2024 (Retainer)
Summary
Nayms is a decentralized insurance marketplace built using the diamond pattern (a multi-facets proxy architecture). The project uses three layers: facets, libraries, and storage. Facets are the entry points of the system, libraries handle the main business logic, and application data is stored in a single storage called `AppStorage`. Nayms team requested an audit of the changes in the codebase since the last audits ([Nayms 1](https://certificate.quantstamp.com/full/nayms.pdf) and [Nayms 2](https://certificate.quantstamp.com/full/nayms-2/ae3ff4fd-fac2-4f52-b8eb-d570d730d6a6/index.html)). The changes mainly involve a staking feature, the management of fees, the internal representation of objects and the behavior of the internal market. Also, the business logic of the Naym token was separated from the logic of the rest of the platform into a second repository. Furthermore, this report includes an assessment of the pull request [PR-100](https://github.com/nayms/contracts-v3/pull/100) to support rebasing tokens. A dedicated section below provides details about the scope. As a disclaimer, issues listed in the previous reports ([Nayms 1](https://certificate.quantstamp.com/full/nayms.pdf) and [Nayms 2](https://certificate.quantstamp.com/full/nayms-2/ae3ff4fd-fac2-4f52-b8eb-d570d730d6a6/index.html)) were not the main focus of this audit. The fix status `Acknowledged`, `Mitigated` and `Unresolved` of these past issues should be considered unchanged, except if we make an explicit mention of the contrary in this report. We found four high-severity issues related to the accounting of the staking feature and the overall mechanism to represent objects in the system using `bytes32` identifiers. Medium-severity issues are mainly about the management of privileged roles in the system. In addition to low and informational-severity issues, we have 7 issues with an undetermined severity since we were not able to clearly assess the expected behavior of the system and the associated impact. Regarding the project quality, the audit found that the code was easy to follow with consistent design patterns. The test quality is good but could be improved in terms of coverage, especially for the edge cases related to the new features. Regarding the documentation, users can easily find general information about the project, and the code has an extensive usage of NatSpec. Dedicated but not fully up-to-date documentation describes the ACL (Access Control Lists) rules and different staking scenarios with exact figures. Also, abstraction plays an important role in the design of the system, to make it more flexible. However, more flexibility comes with more edge cases and should come with more specifications describing how the system should work, what should be possible, and what should not be allowed. As a result, the system would benefit from overall visual diagrams describing the main mechanisms of the system (dividends, access control, token flows, staking feature) and improved textual specifications to simplify the work of external observers in charge of understanding and checking the alignment between the expected and the actual behavior of the system. Such specifications would also be a valuable input for the design of the test scenarios for two main use cases: checking that the current codebase is working as expected, and that new features do not introduce breaking changes. In addition to multiple issue recommendations with the aim to better describe how the system should work, we suggest in the section "Adherence to Specification" to make the ACL more visual and verifiable. During the audit, our team frequently interacted with Nayms team to clarify code and expected behavior. Their active engagement in answering our questions was crucial and greatly assisted in completing the audit. Finally, we want to highlight the importance of following best practices for key management of admin addresses. Also, security guidelines related to the diamond pattern should always be considered when the code is modified. **Fix review update** All issues have been addressed, the issues were either fixed, mitigated or acknowledged. Most of the best practices were fixed. Extra tests have been added. In addition, the client identified during the audit an issue related to the way dividends are managed when p-tokens are burned and asked to review this fix as well during the fix review ([PR 104](https://github.com/nayms/contracts-v3/pull/104)).
Issues (33)
Low | Medium | High | Critical | Total | |
|---|---|---|---|---|---|
Not fixed | 13 | 2 | - | - | 15 |
Fixed | 12 | 2 | 4 | - | 18 |
| Total | 25 | 4 | 4 | 0 | 33 |