Architecture
Introduction
At its core, KAIO’s Gateway and APIs enable the issuance, transfer, and settlement of regulated products while linking to fund administration, banking services, liquidity pools, and cross-chain messaging. From subscriptions and redemptions to NAV reporting and collateral use, the architecture illustrates how KAIO integrates compliance, interoperability, and programmability to support both simple and complex tokenised investment strategies.
High Level Architecture
When talking about KAIO’s architecture, the focus is on which components make up the system, and how they interact amongst themselves. The components can be organized into two different layers: the application layer and the infrastructure layer. As described below, the infrastructure layer hosts all the components in the application layer and connects them to the Ethereum mainnet, where KAIO’s smart contracts are deployed.
At its highest level, the KAIO application architecture consists of three main components:
Frontend: Allows end users to interact with KAIO through a GUI in an intuitive manner.
API: Acts as a bridge between the frontend and the smart contracts, simplifying interaction with the logic.
Smart Contracts: Implement the core business logic of the KAIO system and are deployed directly on Ethereum mainnet.
On the other hand, the KAIO Infrastructure provides everything from storage for user data to the supporting cloud services that enable seamless interaction with the Ethereum blockchain where the smart contracts run.
Application Layer
This section provides a more in depth look at the internal architecture for the different components of the application layer.
Frontend Architecture
The frontend application is built with Next.js, and features a modular and hierarchical design. The top level consists of pages, each corresponding to a route in the application. These pages make use of features, which are key functional units of the application. Alongside specific components within each feature, the architecture also includes common components. These are reusable UI elements utilized across various features. Additionally, the application uses custom hooks for shared state logic, and the Context API for global state management.
API Architecture
KAIO uses an API backend system to act as a bridge between the frontend and the smart contracts deployed on Ethereum. In addition to relaying transactions, the API includes supporting functionality such as notifications, user authentication, static data calculations, and custody solutions. These services rely on external cloud components within the infrastructure layer.
Smart Contract Architecture
Smart contracts on Ethereum implement the core business logic of the KAIO protocol. The architecture is registry-based, allowing users to access, store, and interact with information on-chain. Tokenisation, orders, compliance checks, and lifecycle management all reside within instrument registries.
Registries
The main contracts in the system are registries. Registries are used to store information and logic related to particular users or concepts:
Roles Registry: Stores the information and logic related to role management and access control.
Jurisdiction Registry: Stores the information related to Jurisdictions and their compliance requirements.
Investor Registry: Stores the information and logic related to Investors.
Dealer Registry: Stores the information and logic related to Dealers.
Fund Registry: Stores the information and logic related to Funds.
Instrument Registry: Stores the information and logic related to Instruments. Most of the core business logic resides inside each instrument, such as tokenization, compliance checks, and the lifecycle of orders.
Rules
In addition to registries, there is also rule modules. These modules implement specific rules, usually for limits or compliance. They come into play when interacting with an instrument, which can only happen if no rules are violated. The design and management of these modules is left to different users depending on who they impact:
KAIO Modules: Managed by the KAIO Admin. Their rules apply to all Investors using the platform.
Dealer Modules: Managed by Dealers. Their rules apply to a Dealer's Investors.
Instrument Modules: Managed by Fund Admins. Their rules apply to Investors using that Instrument.
These modules are called and managed through the rules engine. This contract makes sure the right module is called whenever a rules check is needed. Modules need to be registered to the rules engine, after which they can be disabled if required. A general rules engine exists for the KAIO Admin and Dealers, while each instrument also has its own rules engine for their Fund Admin.
Order Books
Order books exist for each instrument, and contain the logic for the lifecycle of the tokenized asset, known as the subscription book and the redemption book. Subscribing or redeeming work in phases, and for each one the appropriate rules are checked to guarantee compliance.
Tokens
Each instrument issues a security token on Ethereum, representing the regulated asset. These tokens are permissioned—usable only by approved investors—and cannot move outside the KAIO ecosystem without meeting compliance requirements. A shared settlement token, representing USD, is also used across instruments for payments and reconciliations. There are also rules enforced when transferring the token.
Infrastructure Layer
This section provides a more in depth look at the architecture of the infrastructure layer, and how the components of the application layer fit within it. It also includes a deep dive into the architecture of the blockchain network itself.
Application Components
The components shown above make up the application layer. They all reside within an EKS managed Kubernetes cluster, that provisions resources for them dynamically. In addition some components are not directly part of the application, but are utilities that help support it, such as with continuous delivery or monitoring.
Cloud Service Components
The KAIO infrastructure also contains a large number of cloud service components that are used for a variety of things, such as computing, development, networking, storage, security, and more. Most of these services are part of AWS.
Combined Infrastructure Architecture
The above diagram shows an overview of the infrastructure architecture, including both the application and the service components explored previously. As can be observed, the application components are enhanced and complemented by the cloud services, which allows them to interact and function as intended.
Blockchain Architecture
KAIO’s smart contracts run directly on Ethereum mainnet, leveraging its security, decentralisation, and settlement guarantees.
Dedicated Virtual Private Cloud
A Virtual Private Cloud (VPC) is a logically isolated section of the AWS cloud where resources can be launched in a virtual network. The dedicated VPC provides an isolated environment for hosting all the supporting infrastructure components. This isolation enhances security by preventing unauthorized access from external networks.
Execution & Settlement Layer – Ethereum Mainnet
The execution and settlement of KAIO’s smart contracts occur on Ethereum. All registries, rules, and order book logic are deployed on-chain, ensuring compliance, transparency, and finality without relying on a permissioned chain.
Bridges & L2 Gateway Access
Where scaling or cross-chain connectivity is required, KAIO integrates with Ethereum-based bridges and Layer-2 networks. In addition, the KAIO Gateway provides a bridge infrastructure that connects with both EVM and non-EVM chains, enabling tokenised assets to move across diverse ecosystems with low friction.
Network Load Balancer
The Network Load Balancer (NLB) is a network service provided by AWS. In the context of the blockchain infrastructure, it's used when exposing the JSON-RPC endpoint to the external world. JSON-RPC is a remote procedure call protocol encoded in JSON. This endpoint allows developers to interact with the blockchain network using API calls. The NLB helps distribute incoming API requests across multiple validator nodes, ensuring efficient load distribution and high availability.
Last updated