Why We Built a Python blockchain

Xian is a Python blockchain (native-Python Layer 1). You write smart contracts in real Python, executed in a deterministic Python runtime and secured by CometBFT. Here’s the thinking behind our architecture—and how it improves DX.

Xian artwork

Our thesis: bring Python directly on-chain

Most chains ask you to learn a new language or a Python-like DSL. We took a different path: make Python itself the smart-contract language—then enforce determinism at runtime.

Why a native Python blockchain?

Python is readable and everywhere—in AI, data, and fintech. Running contracts in a deterministic Python runtime preserves ergonomics while guaranteeing reproducibility, metering, and safety.

Why CometBFT (not homegrown) consensus?

CometBFT gives proven BFT finality plus a clean ABCI boundary. That lets us focus on what’s unique to Xian: the Python state engine, tooling, and developer-aligned economics.

Why a deterministic Python state engine?

Contracts run in a constrained runtime: controlled built-ins, no filesystem/network/clock, and resource metering. Every validator computes the same state transition from the same inputs.

DX first: zero language switching

Contracts are normal Python modules with explicit exports and state. Tooling mirrors familiar workflows—CLI, Python/JS SDKs, and straightforward testing—so you ship faster.

A tiny Python contract

Native Python smart contract on Xian


# savings_vault.py — minimal example
import currency
safe = Hash(default_value=0)

@export
def deposit(amount: float):
    currency.transfer_from(amount=amount, to=ctx.this, main_account=ctx.caller)
    safe[ctx.caller] += amount

@export
def withdraw(amount: float):
    assert safe[ctx.caller] >= amount, 'insufficient funds'
    currency.transfer(amount=amount, to=ctx.caller)
    safe[ctx.caller] -= amount

Full quickstart in the docs.

Architecture in brief

Consensus: CometBFT

Fast finality with BFT safety and a mature validator lifecycle. ABCI separates consensus from app logic.

Predictable blocks, simpler ops.

State Engine: Deterministic Python

Sandboxed runtime with controlled built-ins and strict determinism. Gas metering prevents runaway code.

Reproducible state transitions.

Developer Economics

Developers earn a majority share of gas (currently 68%); 1% burns each tx. Ratios governed by DAO vote.

Aligned incentives for useful dApps.

DX & Tooling

xian-py, xian-js, wallet dapp utils, GraphQL explorer.

Faster from idea to mainnet.

Why not a Python-like DSL?

DSLs add cognitive overhead and split ecosystems. We aim for zero language switching—auditable Python with deterministic constraints.

Safety by construction

No filesystem, sockets, or wall-clock; hermetic execution that’s easier to audit and reproduce.

Performance in practice

For many financial/app workloads, deterministic Python is plenty fast while preserving readability and security.

Evolving sustainably

CometBFT handles consensus; we iterate on DX, runtime, standards, and incentives.

Build on a native Python blockchain

Python blockchain — FAQ

Quick answers for developers exploring Xian.

Q

Is it really Python?

Yes—contracts are Python modules executed in a deterministic runtime. No DSL or transpiler.

Docs
Q

How is determinism enforced?

Constrained built-ins, no external I/O, and resource metering ensure identical results across validators.

Q

Why CometBFT?

Proven BFT engine with a clean ABCI interface for reliability and quick finality.

Q

What do developers earn?

Contracts earn a majority share of gas (currently 68%), with burn and validator allocations by DAO.

Live Earnings
Q

How do I deploy?

Install the wallet, fund, then deploy from wallet IDE—minutes to mainnet.

Quickstart