Pre-release · build from source

Application ledgers that prove themselves.

Several organizations run one replicated ledger: the same ordered commands, the same deterministic state machine, the same signed state root — provable by anyone and settled on Cardano. Yano X is the Java ecosystem that makes it something you configure rather than build.

Run a 3-member chain → What is an app chain?
How a Yano app chain finalizes a command A signed command is relayed to three member nodes. Each independently re-executes it and derives the identical state root 9f3c…a17b. A threshold-signed app block commits that root, which is then anchored on Cardano and released to external effect executors. 1 · SIGNED COMMAND orders-chain order-created ed25519 2 · EVERY MEMBER RE-EXECUTES node-0 · proposer root 9f3c…a17b node-1 root 9f3c…a17b node-2 root 9f3c…a17b identical, byte for byte 3 · THRESHOLD-FINAL app block #1042 root 9f3c…a17b 3 of 3 signed Cardano anchor 4d80…c2e9 Effects Kafka · S3 IPFS · HTTP
0
Reviewed recipes
0
Selectable capabilities
0
Runtime plugin bundles
0
State machines

What an app chain gives you

Not every business event belongs on a public blockchain. An app chain supplies the shared application layer, and Cardano supplies independently observable settlement for the state it commits to.

◆ Deterministic execution

Every member applies the same ordered messages through the same state machine and derives the same state root, byte for byte. No operator's database is the truth.

Determinism rules

✓ Threshold finality

A block is final only once the configured member threshold has signed the root it independently computed. Hash-linked history makes a rewrite detectable.

How finality works

⌘ Provable state

State lives in an MPF trie. A client verifies a record — present or absent — against a finalized root without trusting the node that served it.

State and proofs

⚓ Cardano anchoring

A certified root can be written to a metadata or threshold-script anchor, binding app-chain evidence to public L1 history an auditor can check.

Anchoring

↗ Controlled side effects

State machines authorize external work by emitting immutable effect records. Kafka, S3, IPFS, webhooks, and Cardano payments run outside consensus and report back exactly once.

The effect runtime

⊞ Extend without forking

Ordering, finality, proofs, anchoring, and lifecycle stay in the host. Your domain logic ships as a signed, versioned plugin JAR.

The plugin framework

Three members, one command

Yano X has no published release yet, so you build it once from source. The build downloads the matching Yano 0.1.0-pre13 JVM distribution for you — no second checkout, no Maven Local, no flags.

bash 
# 1. Build the batteries-included JVM distribution$ git clone https://github.com/bloxbean/yano-x.git$ cd yano-x$ ./gradlew clean build -PskipSigning=true # 2. Unpack it$ unzip distribution/jvm/build/distributions/yano-x-jvm-<version>.zip -d ~/yano-x$ cd ~/yano-x/yano-x-jvm-<version> # 3. Start a self-contained 3-member chain on a local devnet$ ./yano.sh appchain cluster start 3$ ./yano.sh appchain cluster statusorders-chain:   AGREED  (height 12, root 9f3c…a17b)registry-chain: AGREED  (height 12, root 4d80…c2e9) # 4. Submit a business event through a non-proposer member$ ./yano.sh appchain cluster submit orders-chain orders \    '{"event":"order-created","orderId":"A-1001"}' --node 1
1

Build once

Java 25 and Gradle. Everything else is resolved for you.

Build from source
2

Pick a recipe

6 bundled recipes cover audit logs, owned registries, approval workflows, and evidence ledgers without any code.

Recipe catalog
3

Prove it

Pull an MPF proof for a record, verify it offline, and anchor the root on a Cardano test network.

Registry and proofs

Climb only as far as you need

Most applications never write a line of consensus code. Yano X is organized so that the cheapest rung that models your outcome is the correct one.

0

Configuration only

Select a stock state machine or a committed composite profile identically on every member — yano.app-chain.state-machine: kv-registry. No JAR, no build.

1

A small composite plugin

All the components you need already exist, but you need a new ordering, routed topics, quotas, or terminal transitions. Declare the composition; reuse the transitions.

2

A custom state-machine plugin

Genuinely new state or rules. ./yano.sh appchain plugin scaffold generates a buildable, closed-by-default provider; you implement, sign, pin, and install it on every member.

3

Executors, sinks, APIs, observers

Independent SPIs for external delivery and read surfaces. These run outside consensus, so they never affect the state root.

Read the plugin framework guide →

Built for coding agents too

Yano X is new enough that no model has trained on it. Every page here is also published as agent-ingestible markdown, and the recipe, capability, module, and configuration catalogs are generated from the repository itself.

◇ AI Starter Pack

The extension ladder, the determinism rules, the plugin lifecycle, and the invariants agents get wrong — in one file.

curl -o CLAUDE.md https://yanox.dev/ai/starter-pack.md
Read it

≡ llms.txt

A curated index following the llmstxt.org convention, plus llms-full.txt with every page concatenated for full-coverage ingestion.

/llms.txt

{} catalog.json

11 recipes, 43 capabilities, 52 Gradle modules, and 44 configuration properties as structured JSON.

/ai/catalog.json
Yano is pre-release. The architecture and devnet workflows documented here are implemented and tested, and there is no published Yano X release yet — you build from source. Production rollout still needs the normal network, security, operations, load, and domain validation. Use a local devnet or a Cardano test network with disposable data and non-production credentials.