SDK notes

Inside the Kanari SDK

A map of the Rust workspace, Move runtime, DAG engine, RPC layers, and developer entry points.

All articles
Kanari Network Technical note

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:

  1. The application layer submits a signed transaction.
  2. The execution layer runs Move code and updates state.
  3. The DAG layer propagates vertices between authorities.
  4. Consensus orders finalized work and produces checkpoints.

The kanari-core documentation exposes two central engine types:

  • BlockchainEngine for the base execution engine.
  • DagEngine for 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_pay provides a Flutter/Dart client application and SDK modules.
  • packages/kanari_flutter provides Flutter integration backed by Rust crypto code.
  • sdk/wallet provides 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:

  1. README.md for the root quick start and crate map.
  2. crates/kanari/MOVE_CLI_GUIDE.md for Move package workflows.
  3. crates/kanari-core/README.md for the execution engine.
  4. crates/centauri/DAG_ARCHITECTURE.md for consensus concepts.
  5. sdk/kanari_pay/lib/src/ARCHITECTURE.md for 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.