Smart Contracts
Web3 KAIO components
Introduction
The KAIO smart contracts are at the core of the KAIO platform. They implement the main business logic that enables the platform to work. Ensuring their security is of upmost priority, to prevent financial loss, unauthorized access, and disruption of service. The KAIO smart contracts are designed and built with security in mind, and following best practices.
Architecture
An overview of the smart contract architecture can be found here:
Access Control
As mentioned previously, the access control is based on roles. These roles follow a hierarchy, with the KAIO Admin being at the top. The role system has a high level of granularity, since access to functions is granted individually, using their selector. This means that when creating a new role, the functions they can access can be specified in a clear manner. It is also possible to set a role as "Contract Manager", which will make it the default role that has access to features for a specific contract. Users with existing roles can create and grant new roles (sub-roles), but these roles can at most access the functions that the parent role had access to, or they can be more restrictive. This access control system serves to robustly protect functions from the wrong users, and clearly specify which users have access to which functionalities.
Threats & Mitigations
Potential attack vectors always need to be considered when designing and implementing a system. These might be common to the technology, like with smart contracts, or more specific to the system's architecture. In the case of KAIO, these threats have all been reviewed and addressed.
Users
There is a risk of misbehavior by users with powerful roles, since they can access sensitive functions and provide data. For example Dealers are responsible for providing correct Investor data, and Fund Admins are responsible for providing accurate Net Asset Values (NAV). These threats are mitigated by the fact that these users are manually onboarded by the KAIO Admin, after a rigorous compliance process, and thus are subject to legal repercussions for any misbehavior.
Modules
Modules contain custom code from users, and thus their interaction with the rest of the system must be carefully considered. That being said, the modules are only used to check rules, and they can only be more restrictive compared to the KAIO modules, not less. If for example a Fund Admin decides to change the rules in their modules, that is allowed. In a worse case scenario, all they could do is "lock" their instrument if rules are too restrictive, which has the same risk profile as the Users one described previously.
Development Lifecycle
Effort and care were put into the methodology and development lifecycle of the smart contracts, with the goal of achieving the best quality possible.
Testing
The smart contracts were thoroughly tested with a combination of unit and integration tests:
Unit tests: The smart contracts were tested individually, with each function being tested for positive and negative cases to ensure correct behavior. In some tests mocks were used to avoid dependencies, and fuzzing was used to further test inputs.
Integration tests: The entire smart contract platform was tested using integration tests, without using mocks. A complete flow including the setup, multiple Investors and multiple Dealers was carried out. Fuzzing was used to test a wide range of input values. All modules and their rules were also included and tested, with exception of the ones with non-specific implementations. These were given example implementations and tested separately.
Code Reviews
All changes in the smart contracts went through code review. Reviews were done by at least 2 separate people, different than the person who authored the change. The code review process minimizes the chance of bugs or other issues, while also ensuring code quality and consistency. Additionally it guarantees the code is optimized, both for gas spending and for contract size.
Audits
An internal smart contract audit was done by Nethermind, in order to ensure there were no issues with the code. The findings from this audit have been addressed and resolved. The audit report is available below.
Last updated