The Xian VM

The Xian VM is the execution layer that lets Xian keep Python as the contract authoring language without tying consensus forever to CPython bytecode.

The Two Layers To Keep Separate

There are always two distinct questions in Xian:

What language does the developer write?
What machine executes that program on validators?

Developers write a restricted Python subset. The network then chooses an execution engine for that authored contract.

Current Execution Mode

Mode	What executes
`xian_vm_v1`	validated Xian VM artifacts under a native runtime

The contract language stays the same. What changes is the runtime beneath it.

What `xian_vm_v1` Actually Uses

Under xian_vm_v1, deployment is artifact-driven.

The important stored artifacts are:

__source__: canonical human-facing source used by explorers, dashboards, and inspection tooling
__xian_ir_v1__: the persisted Xian VM IR used by the native runtime

Client and runtime tooling build and validate deployment_artifacts, which include:

module_name
vm_profile
source
vm_ir_json
content hashes for the canonical artifacts

The runtime validates those artifacts against the canonical compiler output before deployment so forged or mismatched bundles are rejected.

Execution Policy

VM-native execution is the fixed node execution runtime:

toml

[xian.execution.engine]
mode = "xian_vm_v1"

On the current supported branch:

xian_vm_v1 is the only supported node runtime
bytecode, gas schedule, and authority are internal VM constants
submitted contracts must provide deployment artifacts

This keeps the execution contract explicit without exposing alternate engines.

What The Native Runtime Does

The native runtime is not a second unrestricted Python interpreter. It executes validated Xian VM artifacts and delegates explicit host operations back to the Xian runtime boundary.

That host boundary includes things such as:

Variable and Hash reads and writes
ForeignVariable and ForeignHash reads
event emission
contract import and export calls
hashing and signature verification bridges
zk.* verification syscalls

Those operations are deterministic runtime calls, not arbitrary operating-system syscalls.

What Stays The Same For Contract Authors

Contract authors still work with the familiar Xian model:

@construct and @export
Variable, Hash, and foreign state helpers
ctx, now, events, and imports
chi budgeting and deterministic rollback semantics

In other words, xian_vm_v1 changes the execution machine, not the basic developer-facing contract model.

Why The Xian VM Matters

The Xian VM gives the platform a cleaner long-term machine contract:

execution semantics become Xian-defined instead of CPython-bytecode-defined
metering can be attached directly to VM operations and host calls
deployment can be validated from canonical artifacts
replay and parity testing become easier to reason about
performance-sensitive paths can move further into native code without forcing a new contract language on developers

Current Scope

The current VM-native runtime already covers real authored contract behavior, including storage flows, decimals, datetime helpers, hashing, Ed25519 verification, imports, events, and the shielded contract helpers needed by the existing shielded stack.

That means the Xian VM is not just a design note. It is a real execution path that the node stack can select deliberately.

The Xian VM ​

The Two Layers To Keep Separate ​

Current Execution Mode ​

What xian_vm_v1 Actually Uses ​

Execution Policy ​

What The Native Runtime Does ​

What Stays The Same For Contract Authors ​

Why The Xian VM Matters ​

Current Scope ​

Related Pages ​