Inside the Kanari SDK
Kanari is organized as a Rust workspace for building a Move-powered execution client. The repository is not a single library. It is a set of focused crates for the CLI, node runtime, RPC services, cryptography, framework packages, state storage, consensus, and client integrations.
This note maps the major parts of the repository and explains how they fit together.
Start with the workspace
The root Cargo.toml is the best place to see the system boundary. Its workspace members include:
| Area | Important crates | Responsibility |
|---|---|---|
| Developer entry point | crates/kanari |
CLI commands and local bootstrap |
| Node and APIs | crates/kanari-node, crates/kanari-rpc-api, crates/kanari-rpc-server, crates/kanari-rpc-client |
Node process and JSON-RPC surface |
| Execution | move-execution/v0/kanari-move-runtime, move-execution/v1/kanari-move-runtime-v1 |
Move VM execution layers |
| Domain types | crates/kanari-types, crates/kanari-common |
Shared blockchain and application types |
| Framework packages | crates/kanari-frameworks, crates/kanari-framework-builder |
On-chain packages and framework build tooling |
| Storage | crates/kanari-db-common, crates/smt |
Persistent state and sparse Merkle tree support |
| Cryptography | crates/kanari-crypto, crates/kanari-auth |
Keys, signing, verification, and authentication support |
| Execution engine | crates/kanari-core |
Blockchain engine and DAG-oriented execution |
| Consensus | crates/centauri |
DAG consensus implementation |
| Supporting services | crates/kanari-faucet, crates/kanari-indexer, crates/run-auth |
Faucet, indexing, and auth services |
This split matters because each layer can evolve without turning every change into a rewrite of the entire node.
The developer path
For a local developer, the CLI is the shortest path into the network.
# Build the CLI
cargo build -p kanari
# Initialize local state and list wallets
cargo run -p kanari -- keytool list
# Create a Move package
cargo run -p kanari -- move new my_token
# Run package tests
cargo run -p kanari -- move test ./my_token
On the first run, the CLI bootstraps genesis state. The root README documents local RocksDB state under ~/.kanari/kanari-db/.
Move is the execution language
Kanari packages are written in Move. A package generated by the CLI contains a Move.toml, a sources/ directory, and a tests/ directory.
my_token/
|-- Move.toml
|-- sources/
| `-- my_token.move
`-- tests/
`-- my_token_tests.move
The generated manifest connects the package to the Kanari framework and Move standard library.
[dependencies]
KanariSystem = { git = "https://github.com/kanari-network/kanari-sdk.git", subdir = "crates/kanari-frameworks/packages/kanari-system", rev = "kanari-sdk" }
MoveStdlib = { git = "https://github.com/kanari-network/kanari-sdk.git", subdir = "crates/kanari-frameworks/packages/move-stdlib", rev = "kanari-sdk" }
That makes the framework part of the developer workflow rather than a hidden node detail.
Execution and consensus are separate concerns
The repository separates transaction execution from network agreement:
- The application layer submits a signed transaction.
- The execution layer runs Move code and updates state.
- The DAG layer propagates vertices between authorities.
- Consensus orders finalized work and produces checkpoints.
The kanari-core documentation exposes two central engine types:
BlockchainEnginefor the base execution engine.DagEnginefor DAG vertex production and checkpoint flow.
The consensus implementation lives separately in crates/centauri. This boundary keeps Move execution logic and consensus logic understandable as distinct systems.
State has a home
Local state is persisted through RocksDB. The root README identifies:
| Item | Value |
|---|---|
| Database directory | ~/.kanari/kanari-db/ |
| Serialized state key | "state" |
| Reset workflow | Remove the database directory and restart |
For verification-oriented state structures, the workspace also includes crates/smt for sparse Merkle tree support.
SDK-first means multiple entry points
The Rust workspace is the core, but the repository also contains SDK-facing packages:
sdk/kanari_payprovides a Flutter/Dart client application and SDK modules.packages/kanari_flutterprovides Flutter integration backed by Rust crypto code.sdk/walletprovides an additional wallet-oriented Rust package.
The result is a layered project: Move packages for on-chain behavior, Rust crates for the node and protocol, RPC services for communication, and Flutter/Dart packages for application developers.
Where to read next
Use these files as a guided tour:
README.mdfor the root quick start and crate map.crates/kanari/MOVE_CLI_GUIDE.mdfor Move package workflows.crates/kanari-core/README.mdfor the execution engine.crates/centauri/DAG_ARCHITECTURE.mdfor consensus concepts.sdk/kanari_pay/lib/src/ARCHITECTURE.mdfor the Flutter/Dart client design.
The repository is broad, but the boundaries are intentional: CLI, Move runtime, state, consensus, RPC, and application SDKs each have a clear place.