KANARIdocs
Network
Documentation
Kanari DocsDeveloper documentation
Kanari DocsDeveloper documentationKanari Docs InstallationSet up a content-driven documentation site with Kanari Docs
Welcome to Kanari Docs
Introduction
Quick StartSetup Node
Architecture
Protocol StackCheckpoints and Mysticeti DAGExecution and State
Operations
Multi-node DevnetRPC Gateway and LimitsSnapshot and Validator Backup
Security
Security HardeningTesting and Audit Coverage
CLI
Kanari Node CLIKanari CLIClient OperationsMove DevelopmentKeytool Operations
API Reference
API Reference
Guides
Transferring CoinsGas Model

Kanari Documentation

Execution and State

Move runtime, state access tracking, gas, and persistence model.

Last updated

Execution and State

Kanari execution is built around Move VM state transitions and object/resource effects. The core engine decides transaction order for committed checkpoints; the runtime applies deterministic effects to persistent state.

Runtime responsibilities

  • Load embedded 0x1 Move stdlib and 0x2 Kanari system modules.
  • Execute Move module publish, upgrade, function calls, native transfers, and view calls.
  • Apply object creates, mutations, transfers, deletions, dynamic fields, events, and gas effects.
  • Persist canonical object/resource state through RocksDB-backed stores.
  • Maintain state roots used by checkpoint verification.

Framework loading

Release binaries no longer require operators to run with KANARI_FRAMEWORK_PATH for normal startup. The runtime build embeds framework bytecode when available, and the loader can use embedded modules before falling back to source-tree discovery.

For development, rebuilding frameworks is still useful after changing Move packages:

cargo run -p kanari -- move build

Parallel execution status

The runtime contains scheduler and access-set primitives for deterministic conflict handling. The safe production path remains checkpoint-deterministic: validators must commit the same ordered effects and derive the same state root.

When experimenting with higher throughput, use separate sender/object sets where possible. Transactions that mutate the same coin/object must serialize or retry because object versions conflict.

State root checks

The node stores checkpoint metadata and state roots. RPC and explorer diagnostics can compare roots across nodes. If roots diverge, treat the node as unsafe until it is repaired through snapshot or validator backup recovery.