Skip to main content

Fabric-X Networks

Fabric-X is a high-throughput, linearly-scalable variant of Hyperledger Fabric that separates ordering from committing and replaces in-band endorsement with an application-layer signing layer (token-sdk-x). ChainLaunch provides first-class support for deploying and operating Fabric-X networks alongside Fabric and Besu.

What is Fabric-X?

Fabric-X re-architects the classic Fabric transaction flow to break the peer bottleneck. Where classic Fabric bundles endorsement, ordering, and committing into a single peer process, Fabric-X splits them into independently-scalable services:

  • Orderer group — establishes total order of transactions using Arma consensus.
  • Committer — validates and commits blocks, serves queries from a relational store.
  • token-sdk-x — lives in the application layer and handles per-transaction signing (what endorsing peers did in classic Fabric).

The result is a network where you can scale ordering, committing, and application signing independently, and where committers can serve rich SQL-style queries directly from postgres.

Key differences from Hyperledger Fabric

DimensionClassic FabricFabric-X
Ordering consensusRaft, SmartBFTArma (pBFT-derived, purpose-built for ordering)
EndorsementEndorsing peers sign proposals in-bandHandled by token-sdk-x in the application layer
Commit pathPeers validate and commitDedicated committer pipeline (sidecar → coordinator → validator → verifier)
State backendLevelDB / CouchDB per peerPostgres per committer, queryable via a query-service
Channel modelMany channels per networkSingle channel (arma) per network, partitioned by namespace
ChaincodeIn-band execution on peersNot applicable — business logic lives in token-sdk-x applications
Throughput~1,000 TPSDesigned for 10,000+ TPS with independent horizontal scaling

When to choose Fabric-X

Fabric-X is a good fit when you need:

  • High throughput — tokenized assets, payments, high-frequency supply-chain events.
  • Rich queries — reporting, analytics, and compliance workloads that benefit from SQL against committed state.
  • Separation of concerns — dedicated ops teams for ordering vs. committing vs. application logic.
  • Token-native use cases — any workload built on the token-sdk-x programming model.

Stay on classic Fabric when you need:

  • Multi-channel isolation.
  • Existing chaincode investments.
  • Lower-footprint deployments where the split-service architecture is overkill.

Architecture at a glance

A single Fabric-X party (one organization's stake in the network) runs two node groups managed by ChainLaunch:

A 4-party network therefore runs 40 containers across 8 ChainLaunch nodes (4 orderer groups + 4 committers), sharing a single arma channel.

For the full data flow and port layout, see Architecture.

What ChainLaunch manages

ChainLaunch owns the infrastructure side of Fabric-X:

  • Orderer groups and committers — lifecycle (create, join, start, stop, delete), crypto material, container orchestration.
  • Genesis block generation — from the network's party list.
  • Namespace management — creating and listing logical partitions within the arma channel.
  • Block and transaction explorer — read-only view over committed state via the query-service.
  • Network templates — export and import reproducible network definitions.

ChainLaunch does not manage:

  • Application signing / endorsement — handled by token-sdk-x outside of ChainLaunch.
  • Chaincode — Fabric-X does not use chaincode; business logic lives in token-sdk-x applications.

Getting started

  1. Quickstart — provision a full 4-party network from the web UI in one click.
  2. Architecture — understand the components, ports, and data flow.
  3. Create a network manually — step-by-step via API for production deployments and multi-network setups.
  4. Namespaces — logical partitioning within a Fabric-X network.

Operating a network

  1. Monitoring — Prometheus /metrics endpoints for every role, plus a starter scrape config.
  2. Certificate renewal — same-keypair renewal of signing and TLS certs without genesis regeneration.
  3. Backup and restore — what's snapshotted by restic, what's not, and how to restore.

See also