Why Yano X

Choose Yano X when several organizations need shared records, workflows, or integrations with independently verifiable results. Start with existing capabilities, then add custom Java rules only where your application needs them.

Yano supplies the host. Yano X adds application behavior through JVM plugins and reusable libraries. The dependency runs one way: yano-x → yano.

The boundary

Yano and Yano XConcept

• Yano X · application behavior: State machines, Composition, Connectors, Products, SDKs and tools, JVM distribution.
• Yano · the host: Cardano node, Consensus, State and proofs, Anchoring, Effect runtime, Plugin SPI, ordered-log.
• Yano X · application behavior → Yano · the host (plugins, through the catalog).

State machines

Every stock state machine except ordered-log: kv-registry, approvals, balances, doc-trail, authenticated-map, role-approvals, and more, as JVM plugins. State machines →

Composition

Composite state machines, governed profile evolution, and declarative bindings, which connect existing machines with YAML instead of Java. Declarative bindings →

Connectors

Optional effect executors for Kafka, S3-compatible object storage, IPFS, and Cardano payments, and a Kafka sink for finalized blocks.

Products

Evidence, Cardano History, Attest, Trust Registry, Verifiable Explorer, DPP Starter, Attestation Feed, and the eUTxO ledger. Products →

SDKs and tools

The Java client SDK, a Spring Boot starter, testkits, the appchain command-line tooling, the deployment tool, and App-Chain Studio. These are libraries and tools, not runtime plugins.

JVM distribution

yano-x-jvm-<version>.zip: the Yano JVM distribution with the Yano X bundles, tools, App-Chain Studio, and the local showcase already in place. Release downloads →

Cardano node

Yano is first a Cardano data node: chain sync, relay, and the L1 chainstate.

Consensus

Message ordering, membership, the two-phase round, and threshold finality certificates. Consensus and finality →

State and proofs

Authenticated state with MPF or JMT profiles, proofs and proof subjects, catch-up, and replay. State and proofs →

Anchoring

Anchoring certified roots to Cardano, in transaction metadata or a threshold-signed script anchor. Cardano anchoring →

Effect runtime

The effect runtime: gates, retries, receipts, and result incorporation, plus the webhook executor and sink. Effects →

Plugin SPI

The plugin SPI, the schema-v1 manifest, catalog validation, and plugin lifecycle. Plugins run in the node’s process as trusted code; the catalog is not a sandbox. Plugin framework →

ordered-log

The only built-in state machine: an append-only log of opaque messages with per-message proofs.

The dependency runs one way: Yano X depends on a released Yano, never the reverse. Everything optional that a running node selects reaches it through the plugin catalog.

• Yano X
• Yano

What “batteries included” means

For a first run, choose the local showcase. Each release ships one archive, yano-x-jvm-<version>.zip: the standard Yano JVM distribution with the Yano X plugin bundles already laid out, the command-line and deployment tools, App-Chain Studio, the local showcase, and identity manifests for both projects. The release download guide shows where each part lives. Operators who already run the matching Yano release can take bundles from its plugins/ directory or download the standalone plugin pack; the deployment tool and Studio also ship as standalone archives.

The plugins/ directory is conflict-free: no two bundles claim the same contribution, so the whole directory activates together.

Everything optional is a plugin

Any behavior that a running node can select or manage independently is a plugin:

• The node activates it through its plugin catalog (PluginProviderRegistry), from a schema-v1 plugin manifest.
• A runtime plugin ships as one dependency-complete bundle that does not embed host SPI classes, and its manifest declares the plugin API range it supports (yanoApi: min and max API major, and minLevel).
• Plugins run in the node’s process as trusted code. The catalog checks manifests, compatibility, and lifecycle; it is not a sandbox.

Pure libraries, DTOs, clients, codecs, testkits, CLIs, on-chain validators, and deterministic helpers are ordinary JARs. They become plugins only if the host selects or manages them.

JVM only, on purpose

Yano X is JVM-only: no GraalVM or native-image tasks and no native executables. Yano’s native image is core-only and starts with ordered-log, but it cannot load Yano X bundles. ./yano.sh appchain doctor reports a custom JVM plugin as incompatible with a native distribution.

Namespaces

Use the namespace of the artifact you consume:

• Yano X uses Maven group org.yanoproject.x and Java packages org.yanoproject.x.*. Yano host artifacts use org.yanoproject and host packages use org.yanoproject.*. Third-party Cardano libraries keep their own groups, including com.bloxbean.cardano.
• The plugin directory property is yano.plugins.directory.

What you work with

Whatever you build, the surface is the same:

• ./yano.sh appchain …: the main command line, shipped inside the distribution. The deployment tool and some products add their own commands under tools/.
• The REST API and the server-sent event stream on each node.
• The Java client SDK, and a Spring Boot starter, for typed commands and proof verification.
• App-Chain Studio, for building and exporting a blueprint visually.

Next: Try the local showcase, then choose a recipe.