> For the complete documentation index, see [llms.txt](https://docs.kaio.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kaio.xyz/product-operations/security/smart-contracts.md).

# Smart Contracts

## 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:

[Architecture](/how-kaio-works/architecture.md#smart-contract-architecture)

## Access Control

<div data-full-width="true"><figure><img src="/files/BtJEgIgBLDxeb71kOxrL" alt=""><figcaption><p><em><strong>Roles overview</strong></em></p></figcaption></figure></div>

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](https://nethermind.io/smart-contracts-audits/), 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.

{% hint style="info" %}
As mentioned in the audit report, there are issues with properly measuring the code coverage of our tests due to issues with Foundry. We have since found some workarounds and improved our coverage, which is now above 95%.
{% endhint %}

{% file src="/files/KTJLFh8aPt76GTGHiiaK" %}
***Smart contracts audit report***
{% endfile %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.kaio.xyz/product-operations/security/smart-contracts.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
