Hyperledger Fabric has been the dominant permissioned blockchain platform for nearly a decade. It powers thousands of production deployments across supply chain, healthcare, and government. But the architecture that made Fabric successful in 2018 is showing its age. Monolithic peer processes, crash-fault-tolerant-only consensus, and complex multi-channel configurations have created an operational ceiling that frustrates DevOps teams and limits horizontal scalability.
Fabric-X (also commonly written FabricX or Hyperledger Fabric X) is the Hyperledger community's answer. Incubated under the Linux Foundation Decentralized Trust umbrella alongside classic Fabric, Fabric-X represents a ground-up rethinking of how a permissioned blockchain should work. It decomposes the peer into independent microservices, replaces Raft with the Arma BFT consensus protocol, and moves from multi-channel isolation to a single-channel-with-namespaces model. According to the Linux Foundation Decentralized Trust roadmap (April 2026), Fabric-X has now been benchmarked at 400,000+ TPS with a 4-party, 4-shard deployment — more than two orders of magnitude beyond classic Fabric's 3,500 TPS Raft ceiling.
If you're already running Fabric in production, this guide explains what's changing, why it matters, and how to prepare. If you want to skip to running code, the FabricX quickstart with chaindeploy spins up the canonical 4-party Arma network on your laptop in under a minute. If you're just getting started with classic Fabric, our guide to creating a Hyperledger Fabric network covers the current stable platform.
TL;DR: Fabric-X (FabricX) is Hyperledger Fabric's next-generation architecture. It replaces the monolithic peer with microservices, swaps Raft for Arma BFT consensus, and has been benchmarked at 400,000+ TPS through horizontal scaling (Linux Foundation Decentralized Trust, 2026). As of May 2026, it's available as an MVP via chaindeploy v0.4.0 — production-ready for pilots, still maturing for regulated workloads.
The story of Fabric-X in 2026 isn't only architectural — it's tooling. Three concrete shifts since this guide was first published have moved Fabric-X from "read the design docs" to "spin up a working network on your laptop."
One-command quickstart.chaindeploy v0.4.0 shipped in early May 2026 with first-class FabricX support. A single command — chainlaunch fabricx quickstart --parties 4 — provisions a 4-party Arma BFT committee (4 orderer groups × 4 microservices each, plus 5 committer containers and a shared Postgres) in under five minutes. The same flow runs from the web UI's Quick Start wizard. The wiring that used to take a full afternoon of YAML is now a form fill.
Postgres-bridge auto-attach. The committer's query-service exposes a Postgres-compatible read endpoint per namespace, which means the committer container needs to be on the same Docker network as the shared Postgres database. Earlier beta releases required docker network connect between every committer and the Postgres bridge as a manual post-step. v0.4.0 bakes the bridge attach into the provisioning pipeline. Local-dev mode also auto-rewrites the genesis block to use host.docker.internal, so Docker Desktop installations work without manual host-network configuration.
Plugin x-sources for token-sdk-x. FabricX delegates chaincode execution to token-sdk-x applications running outside the operator. ChainLaunch Pro now ships two reference plugin x-source handlers — fabricx-network and fabricx-identity — that resolve a network ID + organization ID into a connection bundle (router endpoint, query-service endpoint, TLS CA, MSP folder) for token-sdk-x apps. The bundle handles the awkward router TLS ServerName mismatch where dialing chainhost:17000 needs ARMA_ROUTER_TLS_SERVER_NAME=localhost because the router cert SANs don't include chainhost.
Ops integrations. The Node API now exposes FabricX-specific properties (party number, role, MSP, host ports for router/batcher/consenter/assembler/committer). The Prometheus scrape config auto-discovers FabricX monitoring ports. The backup pre-hook runs pg_dumpall inside every managed Postgres container before each snapshot, so backups contain both the live PGDATA directory (for WAL replay) and a transactionally-consistent SQL dump (for psql -f restore).
The deployment story matters as much as the architecture. As of chaindeploy v0.4.0 (May 2026), spinning up a 4-party FabricX network is one CLI command or one UI click. Throughput improvements come from Arma; the time-to-first-transaction improvement comes from the operator layer.
What this means: if you tried Fabric-X six months ago and concluded "interesting architecture, but not ready to evaluate," that conclusion has expired. You can have a running network this afternoon and benchmark your workload against the same Arma consensus the 400,000+ TPS published benchmarks used.
Fabric-X is a new implementation of the Hyperledger Fabric concept, built from scratch with microservices architecture and modern distributed systems patterns. The Hyperledger Foundation's 2025 annual report notes that Fabric remains the most deployed enterprise blockchain, accounting for roughly 46% of permissioned deployments -- but also that operational complexity is the top complaint from adopters.
Classic Fabric bundles endorsement, validation, state management, gossip, and ledger storage into a single peer binary. That monolithic design made early development simpler but created problems at scale. You can't independently scale the endorsement layer without also scaling storage. You can't upgrade the committer without restarting the entire peer. Every performance bottleneck requires overprovisioning the whole node.
Fabric-X addresses this by decomposing the peer into separate, independently deployable services. Each service can scale, update, and fail independently. It's the same architectural pattern that transformed web applications a decade ago -- and it's overdue for enterprise blockchain.
The project emerged from discussions at the Hyperledger Foundation's Technical Oversight Committee in late 2024. Contributors from multiple organizations -- including former IBM Fabric maintainers, academic researchers, and independent developers -- proposed a clean-room implementation that could incorporate lessons from seven years of Fabric production deployments.
Rather than incrementally refactoring classic Fabric (which would require maintaining backward compatibility at every step), the community chose to build a parallel implementation. Classic Fabric continues to receive maintenance updates. Fabric-X develops independently, with the goal of eventually providing a migration path.
The project lives in the Hyperledger Labs incubator as of early 2026. It's not yet a graduated Hyperledger project, which means it hasn't passed the maturity reviews required for production endorsement.
Free resource
3 Config Mistakes That Break Fabric Networks in Production
The checklist our team uses before every Fabric deployment — covers peer gossip, orderer raft settings, and CA enrollment traps that cause 80% of production failures.
Classic Fabric's monolithic peer handles all functions in a single process. Fabric-X splits these into five core microservices, each with its own lifecycle. According to the Fabric-X design proposal (2025), this decomposition enables independent horizontal scaling of each component -- a capability that classic Fabric fundamentally lacks.
Endorsement Service. Receives transaction proposals, simulates chaincode execution against the current state, and returns signed endorsements. In classic Fabric, endorsement is bound to the peer process. In Fabric-X, you can run 10 endorsement instances behind a load balancer while keeping a single committer. High-throughput applications that need fast endorsement but moderate commit rates benefit immediately.
Ordering Service (Arma). Replaces the separate orderer nodes in classic Fabric. Arma handles transaction ordering with Byzantine fault tolerance built in from the start. More on Arma in the next section.
Validation Service. Checks that endorsed transactions meet policy requirements and that read-write sets haven't conflicted. This service runs independently, so validation doesn't block endorsement.
Commit Service. Writes validated blocks to the ledger and updates the state database. Storage-bound workloads can scale this service independently -- more disk I/O capacity without touching the endorsement layer.
State Service. Manages the world state database (key-value store or document database). Query-heavy applications can scale state replicas for read throughput without affecting write paths.
The benefits mirror what the broader software industry learned over the past decade. Independent scaling means you pay only for the capacity each function needs. Independent deployment means you can patch the endorsement service without a full network restart. Failure isolation means a state database crash doesn't take down endorsement.
For enterprise DevOps teams already running Kubernetes, Fabric-X's microservices map naturally onto container orchestration primitives. Each service becomes a Deployment with its own scaling policy, health checks, and resource limits.
Have you ever tried scaling a classic Fabric peer to handle a spike in endorsement requests? You'd need to scale the entire peer -- storage, gossip, and all -- even though only the endorsement layer was under pressure. That's the problem Fabric-X eliminates.
Arma is Fabric-X's native consensus protocol, designed specifically for high-throughput permissioned networks. Classic Fabric relied on Raft (crash fault tolerant only) until version 3.0 introduced SmartBFT. Arma goes further. Early benchmarks from the Hyperledger Performance Working Group (2025) show Arma sustaining over 15,000 TPS with 4 ordering nodes -- compared to SmartBFT's approximately 2,000-3,000 TPS under similar conditions.
Raft was Fabric's primary consensus since version 1.4.1. It's simple, well-understood, and fast. A Raft cluster elects a leader that appends log entries; followers replicate them. If the leader crashes, a new election happens within seconds.
The critical limitation is that Raft is only crash fault tolerant (CFT). It handles nodes that fail or become unreachable. It does not handle nodes that behave maliciously -- sending conflicting messages, withholding blocks, or corrupting data. In a consortium where all participants trust each other completely, CFT is sufficient. But enterprise consortiums increasingly include parties that are business competitors, regulators with different incentives, and third-party auditors. Byzantine fault tolerance isn't paranoia -- it's prudent architecture.
Fabric 3.0 introduced SmartBFT, bringing Byzantine fault tolerance to classic Fabric for the first time. SmartBFT tolerates up to f Byzantine nodes in a network of 3f+1 total nodes. It was an important milestone, but SmartBFT operates within the constraints of Fabric's existing architecture. The ordering service remains a separate set of nodes that receive endorsed transactions, order them into blocks, and distribute blocks to peers.
Arma was designed alongside Fabric-X's microservices architecture, not retrofitted onto an existing system. Several properties distinguish it from both Raft and SmartBFT.
Horizontal scalability. Arma supports partitioned ordering, where different namespaces (Fabric-X's replacement for channels) can be ordered by different subsets of orderers. Classic Fabric orders all channels through the same ordering service cluster. Arma distributes that load.
Pipeline consensus. Arma doesn't wait for one block to fully commit before starting consensus on the next. It pipelines proposals, allowing multiple blocks to be in different consensus stages simultaneously. This is a key contributor to the throughput improvements.
Embedded BFT. Byzantine fault tolerance isn't an add-on. Every consensus round in Arma assumes a Byzantine threat model. The protocol tolerates up to f failures (crash or malicious) in a 3f+1 network, the theoretical maximum for any BFT protocol.
Property
Raft (Classic Fabric)
SmartBFT (Fabric 3.0)
Arma (Fabric-X)
Fault model
Crash only
Byzantine
Byzantine
Node requirement
2f+1
3f+1
3f+1
Throughput
~3,500 TPS
~2,000-3,000 TPS
15,000-400,000+ TPS
Pipelined consensus
No
No
Yes
Partitioned ordering
No
No
Yes
Leader rotation
Election-based
View change
Proactive rotation
Arma is Fabric-X's Byzantine fault tolerant consensus protocol, achieving 15,000+ TPS in early benchmarks through pipelined consensus and partitioned ordering (Hyperledger Performance Working Group, 2025). It replaces Raft's crash-only fault model with full BFT guarantees from the ground up.
Classic Fabric's multi-channel architecture is one of its most powerful features -- and one of its most operationally complex. Fabric-X replaces multiple channels with a single channel that uses namespaces for data isolation. This is a fundamental shift in how privacy and data segregation work.
In classic Fabric, a channel is a separate blockchain -- its own ledger, its own chaincode, its own membership, its own ordering. If three organizations need bilateral data isolation, you create three channels: Org1-Org2, Org1-Org3, and Org2-Org3. Each channel has its own genesis block, its own configuration transactions, and its own set of peers.
This provides strong isolation. But it also means managing N channels with separate configurations, separate chaincode deployments, and separate monitoring. For a consortium of 10 organizations where each pair needs a private channel, that's 45 channels. Operational overhead scales quadratically.
Fabric-X runs a single logical channel. Data isolation happens through namespaces -- logical partitions within the same ledger that enforce access control at the data level rather than the ledger level. Each namespace has its own access policies, its own chaincode (or "smart contract" in Fabric-X terminology), and its own state.
The ordering service sees all transactions but doesn't need to understand namespace boundaries. Privacy enforcement happens at the endorsement and validation layers, where namespace policies determine which organizations can read, write, and endorse within each namespace.
For simple deployments with 2-3 channels, the difference is minor. For large consortiums, it's transformative. Instead of managing 45 separate channels, you manage one channel with 45 namespaces. Configuration changes, upgrades, and monitoring happen in one place.
The trade-off is isolation depth. Classic Fabric channels provide ledger-level separation -- different channels literally have different blockchains. Namespaces provide policy-level separation within a shared ledger. For most enterprise use cases, policy-level separation is sufficient. But if your regulatory environment demands that certain data never coexists on the same ledger as other data, classic Fabric's channel model provides stronger guarantees.
When we evaluate these trade-offs for clients, the question usually comes down to: are you managing more than five channels today? If yes, the namespace model will likely simplify your operations significantly.
Classic Fabric channels isolate at the ledger level (each channel is a separate blockchain). Fabric-X namespaces isolate at the policy level within one shared ledger. Operational overhead drops from quadratic (N² channels for bilateral pairs) to linear (one channel + N namespaces), per the Linux Foundation Decentralized Trust roadmap (2026).
Fabric-X preserves Fabric's execute-order-validate paradigm but distributes each phase across independent services. Understanding this flow is important for anyone planning performance tuning or debugging production issues.
1. Proposal submission. A client application sends a transaction proposal to the Endorsement Service, specifying the namespace (equivalent to channel + chaincode in classic Fabric). The endorsement service routes the proposal to the appropriate chaincode container.
2. Simulation and endorsement. The chaincode executes against the current state (read from the State Service) without committing any changes. It produces a read-write set -- which keys it read and what values it proposes to write. The Endorsement Service signs this result and returns it to the client.
3. Endorsement collection. The client collects endorsements from enough organizations to satisfy the namespace's endorsement policy. This step is identical in concept to classic Fabric, but the Endorsement Service's independence from other peer functions means it can handle more concurrent proposals.
4. Ordering. The client submits the endorsed transaction to the Arma ordering service. Arma orders it relative to other transactions, groups it into a block, and runs BFT consensus among ordering nodes. Pipelining means this step overlaps with consensus on previous blocks.
5. Validation. The Validation Service receives the ordered block and checks each transaction: Do the endorsements satisfy the policy? Have the read-set keys changed since simulation (MVCC conflict)? Invalid transactions are marked but still included in the block for auditability.
6. Commit. The Commit Service writes the validated block to the ledger. The State Service updates the world state database with the valid transactions' write sets.
Because each step runs in a separate service, bottlenecks are isolated and addressable. If endorsement is the bottleneck, scale endorsement instances. If state queries are slow, add state replicas. Classic Fabric requires scaling the entire peer, even if only one function is constrained.
This decomposition also enables better resource allocation. Endorsement is CPU-intensive (chaincode execution). Commit is I/O-intensive (disk writes). State queries are memory-intensive (database caching). Separating them lets you run each on hardware optimized for its workload.
Fabric-X preserves Fabric's execute-order-validate paradigm but distributes the six-step transaction lifecycle (proposal → endorsement → collection → ordering → validation → commit) across five independent microservices. Each service scales separately, so bottlenecks are addressable per-function rather than per-peer (Hyperledger Foundation, 2025).
Free resource
3 Config Mistakes That Break Fabric Networks in Production
The checklist our team uses before every Fabric deployment — covers peer gossip, orderer raft settings, and CA enrollment traps that cause 80% of production failures.
Not yet for regulated production, but yes for pilots and benchmarks. As of May 2026, Fabric-X is in MVP / preview state. chaindeploy explicitly labels its FabricX quickstart card "PREVIEW," and the Linux Foundation Decentralized Trust roadmap (April 2026) targets ultra-scalability use cases — high-frequency tokenization, real-time payments, market-data ledgers — that classic Fabric fundamentally cannot reach. Use it today for development, pilots, and integration tests against your own workload. Hold off for now on regulated production deployments where security audits and operational runbooks are non-negotiable.
The picture has shifted meaningfully in the last six months.
Working operators.chaindeploy v0.4.0 (May 2026) is the first open-source operator with first-class Fabric-X support — single Apache 2.0 Go binary, web UI, CLI, single-node SQLite or Pro federation. Provisioning, certs, genesis, joins, namespaces, backups, and Prometheus monitoring all work end-to-end.
Endorser tooling.token-sdk-x sample apps run against single-MSP Fabric-X networks out of the box. Plugin x-source handlers (in ChainLaunch Pro) resolve network + identity bundles for token-sdk-x apps automatically.
Postgres-protocol query service. Every committer exposes a Postgres-compatible read endpoint per namespace. Applications SELECT against committed state directly — finally not behind CouchDB.
Honest gap list, because the gap matters more than the marketing.
No graduated Hyperledger status. Fabric-X is still in Hyperledger Labs incubation. Graduation requires passing maturity reviews; that hasn't happened yet.
No formal security audit of the Arma consensus codebase or the operator integrations. The benchmarks are real; an independent audit isn't.
No migration tooling from classic Fabric. If you're running 2.x / 3.0 today and want to move workloads to Fabric-X, you're rewriting the deployment from scratch — chaincode logic transfers, lifecycle does not.
Chaincode lifecycle is delegated to token-sdk-x. chaindeploy provisions the network but does not install or upgrade chaincode. That's by design (Fabric-X's execution model differs fundamentally from classic Fabric's chaincode-as-a-service), but it means you carry the chaincode-deployment story yourself.
Single-node operators. chaindeploy uses an embedded SQLite database; there's no HA mode for the operator itself. Federate via Pro Sharing for multi-instance setups.
Updated against May 2026 reality, not the older March 2026 estimate:
Today (May 2026): MVP / preview. Run pilots, benchmark your workload, contribute bug reports.
Late 2026 - early 2027: Likely graduation reviews and the first independent security audits, given the current Hyperledger Labs activity cadence.
2027: Realistic window for regulated-production deployments once audits and migration tooling land.
In our experience with early-stage blockchain infrastructure, the gap between "MVP works on my laptop" and "I'd put my bank's money behind this" is 12-18 months of careful production hardening. That gap is now actively being closed.
Run the quickstart. Spin up a 4-party Fabric-X network on your laptop with the chaindeploy quickstart. It takes under five minutes. The 60 seconds of typing buys you a much better mental model than another hour of design-doc reading.
Benchmark your workload. The 400,000 TPS headline number is real but workload-specific. Run your transaction shape against an MVP network and learn what your numbers actually look like. The 4-party quickstart shape matches IBM Research's Arma paper, so your numbers stay comparable.
Plan, don't migrate yet. Document your classic Fabric channel architecture and endorsement policies — that's the blueprint for namespace design later. Keep chaincode in Go or Java. Abstract integration through a middleware layer. Stay on classic Fabric for production.
You can build a Fabric proof of concept today using classic Fabric and have Fabric-X running in parallel for evaluation — they don't conflict.
As of May 2026, Fabric-X is MVP-grade — production-ready for pilots and benchmarks, not yet for regulated workloads. chaindeploy v0.4.0 provisions a 4-party Arma BFT network with one command. Run it, benchmark it, and plan migrations toward a likely 2027 production-readiness window.
The differences are architectural, not incremental. A Hyperledger Foundation technical briefing (2025) describes Fabric-X as "a reimagining of Fabric for the next decade of enterprise blockchain." The table below captures the most important distinctions across every dimension that affects deployment and operations.
Dimension
Classic Fabric (2.x / 3.0)
Fabric-X
Peer architecture
Monolithic binary
5 independent microservices
Consensus
Raft (CFT) or SmartBFT (BFT)
Arma (BFT with pipelining)
Data isolation
Channels (separate ledgers)
Namespaces (single ledger)
Horizontal scaling
Limited (scale whole peer)
Per-service scaling
Throughput (benchmark)
~3,500 TPS
400,000+ TPS (4 parties × 4 shards, LF DT 2026)
Smart contract language
Go, Java, Node.js
Go, Java, Node.js (planned)
Deployment model
Docker / Kubernetes
Kubernetes-native
Maturity
Production-ready (since 2017)
MVP / preview (Hyperledger Labs, chaindeploy v0.4.0 GA May 2026)
Maturity matters enormously in enterprise software. Classic Fabric has years of production hardening, comprehensive documentation, a large community of maintainers, and extensive tooling. Hundreds of organizations have deployed it successfully. That institutional knowledge doesn't transfer automatically to a new implementation.
Classic Fabric's channel model also provides stronger data isolation guarantees. If your regulatory environment requires that certain datasets exist on physically separate ledgers, classic Fabric's architecture delivers that directly.
For organizations hitting operational ceilings with classic Fabric -- managing dozens of channels, struggling to scale endorsement independently from storage, needing BFT consensus without SmartBFT's throughput limitations -- Fabric-X addresses the root causes rather than applying patches.
The Kubernetes-native deployment model is also significant. Classic Fabric predates widespread Kubernetes adoption, and deploying it on Kubernetes requires custom operators (like the Bevel Operator Fabric that I created for the Hyperledger Foundation) or significant Helm chart customization. Fabric-X is being designed from day one for container orchestration.
If you're running Fabric in production today, Fabric-X doesn't require immediate action. Classic Fabric isn't being deprecated. The Hyperledger Foundation has committed to maintaining classic Fabric alongside Fabric-X, much like how Python 2 and Python 3 coexisted for years before Python 2's end-of-life.
Several strategies reduce future migration effort.
Keep chaincode language-agnostic. Write business logic in Go or Java, which Fabric-X plans to support. Avoid deep dependencies on Fabric-specific SDK features that might not map to Fabric-X's API.
Document your channel architecture. Map which organizations participate in which channels, what endorsement policies govern each, and what data flows between them. This documentation becomes the blueprint for namespace design in Fabric-X.
Abstract your integration layer. If your applications talk to Fabric through a clean API gateway or middleware layer, switching the underlying blockchain requires changes only in that layer -- not in every consuming application.
Monitor the project. Join the Hyperledger Discord and follow the Fabric-X working group. Early feedback from production Fabric operators is exactly what the project needs, and it gives you influence over design decisions that will affect your eventual migration.
Fabric-X preserves the core concepts that define Fabric. Execute-order-validate transaction flow. Endorsement policies. Chaincode as the smart contract model. Identity-based permissioning. The changes are in how these concepts are implemented, not what they are.
If you've invested in training your team on Fabric's conceptual model, that knowledge transfers directly to Fabric-X. The operational model changes (microservices, Arma, namespaces), but the programming model and governance model remain familiar.
Fabric-X plans to maintain backward compatibility with classic Fabric chaincode, though the execution model changes underneath. The Fabric-X design documents (2025) specify that existing Go, Java, and Node.js chaincode should run on Fabric-X with minimal or no modification -- though this hasn't been fully validated yet.
In classic Fabric, chaincode runs in Docker containers or as external services (chaincode-as-a-service, or CCaaS). The peer process communicates with chaincode containers over gRPC. Fabric-X moves chaincode execution entirely to the Endorsement Service, which manages chaincode containers independently from other services.
This has practical implications. Chaincode lifecycle operations (install, approve, commit) will work differently -- driven by the Endorsement Service rather than a monolithic peer. Packaging and deployment may change. But the chaincode itself -- the business logic written in Go, Java, or Node.js -- should remain compatible.
The Fabric-X community has discussed several enhancements to the smart contract model that would be difficult to retrofit into classic Fabric.
Parallel chaincode execution. Because the Endorsement Service scales independently, multiple chaincode invocations targeting non-overlapping key ranges could execute in parallel, improving throughput for workloads with low key contention.
Improved state queries. The independent State Service could support richer query capabilities -- full-text search, range queries with pagination, and aggregate functions -- without impacting endorsement performance.
Cross-namespace calls. Invoking chaincode across namespaces (equivalent to cross-channel calls in classic Fabric, which are notoriously complex) could become simpler when all namespaces share a single ordering service.
Arma is Fabric-X's native Byzantine fault tolerant ordering protocol, designed for pipelined consensus and partitioned ordering — multiple blocks reach consensus simultaneously and different namespaces can be ordered by different subsets of orderers, which is how Arma achieves the 400,000+ TPS headline number (Linux Foundation Decentralized Trust, 2026) while still tolerating up to f Byzantine failures in a 3f+1 network.
There's no public date yet. Fabric-X is in active incubation as of May 2026 and would need to pass Hyperledger Foundation maturity reviews for security, stability, governance, and community size before graduating to active or graduated project status. A realistic window based on current activity is late 2026 to early 2027, but graduation timelines depend on independent security audits that haven't been scheduled publicly.
Not in the same way classic Fabric does. The Fabric-X State Service is its own microservice with a Postgres-protocol query endpoint per namespace — every committer exposes a SQL-compatible read interface over committed state. This replaces the CouchDB rich-query path from classic Fabric with native SQL semantics, which most enterprise teams find easier to integrate than CouchDB's selector syntax.
Yes. The project is officially named Fabric-X but the community uses all three spellings interchangeably — FabricX (no hyphen), Fabric-X, and Hyperledger Fabric X. The Linux Foundation Decentralized Trust documentation uses the hyphenated form. chaindeploy's CLI and UI use the unhyphenated fabricx token. They all refer to the same project: Hyperledger Fabric's microservices-based architecture with Arma BFT consensus.
The fastest path is the chaindeploy v0.4.0 quickstart. One CLI command — chainlaunch fabricx quickstart --network-name demo --parties 4 — provisions a complete 4-party Arma BFT network with all certs, genesis block, and node joins. The same flow runs from the web UI's Quick Start wizard at http://localhost:8100. Total time from a clean machine to a running network is under 10 minutes, including the binary download.
Not yet, and not imminently. Fabric-X is a parallel implementation that may eventually supersede classic Fabric, but the Hyperledger Foundation has committed to maintaining both. Think of it as Fabric's next generation, not its immediate replacement. Classic Fabric continues to receive updates, including the important SmartBFT addition in version 3.0. Production deployments should use classic Fabric until Fabric-X graduates from Labs and passes security audits.
The design goal is backward compatibility for Go, Java, and Node.js chaincode. The business logic and state interactions should transfer. However, chaincode lifecycle operations (how you install, approve, and commit chaincode) will differ because of the microservices architecture. Client-side SDK code will likely need updates. Full chaincode compatibility hasn't been validated yet, so treat this as a planned feature rather than a guarantee.
Arma's key differentiator is pipelined consensus with partitioned ordering. Most BFT protocols (PBFT, SmartBFT, QBFT) process one block at a time. Arma overlaps consensus rounds, which is how it achieves 15,000+ TPS in early benchmarks. It follows the standard 3f+1 Byzantine tolerance model -- tolerating up to f malicious nodes in a network of 3f+1 -- matching the theoretical limit for any BFT protocol.
Fabric-X is designed as Kubernetes-native from day one. Each microservice maps to a Kubernetes Deployment with its own scaling policies, resource limits, and health checks. This is a significant improvement over classic Fabric, which predates widespread Kubernetes adoption and requires custom operators or Helm charts for Kubernetes deployment.
No. If you need a permissioned blockchain today, deploy on classic Fabric. It's production-ready, well-documented, and actively maintained. Fabric-X is at least a year from production readiness. Start building now, keep your architecture modular, and plan to evaluate Fabric-X when it matures. The conceptual model (execute-order-validate, endorsement policies, chaincode) carries over, so your team's knowledge investment isn't wasted.
Fabric-X falls under the Linux Foundation Decentralized Trust governance, the same umbrella that governs classic Fabric, Besu, and other Hyperledger projects. It currently sits in Hyperledger Labs, which means it's community-driven with lighter governance than graduated projects. As it matures, it will go through the standard incubation and graduation process with Technical Oversight Committee reviews.
Fabric-X represents the most significant architectural evolution in Hyperledger Fabric's history. The shift from monolithic peers to microservices, from Raft to Arma BFT, and from channels to namespaces addresses the real operational pain points that enterprise Fabric operators have reported for years. The May 2026 benchmarks are no longer "promising" — they're shipped: 400,000+ TPS for a 4-party / 4-shard configuration in the Linux Foundation Decentralized Trust roadmap, and chaindeploy fabricx quickstart puts that architecture on your laptop in under five minutes.
What's still in motion: a formal security audit of the Arma codebase, graduated Hyperledger project status, migration tooling from classic Fabric to Fabric-X namespaces, and battle-testing across multi-year production workloads. For regulated production deployments today, classic Fabric remains the right choice. For pilots, benchmarks, and the next generation of high-throughput permissioned use cases (tokenization, real-time payments, market data), Fabric-X is ready to evaluate.
The smart approach is unchanged from six months ago, but the action items are more concrete: run the chaindeploy quickstart, benchmark your workload against the 4-party shape, keep production on classic Fabric, and plan for a 2027 production-readiness window. When migration tooling and audits land, you'll be positioned to adopt without starting over.
David Viejo is the founder of ChainLaunch and a Hyperledger Foundation contributor. He created the Bevel Operator Fabric project and has been building blockchain infrastructure tooling since 2020.
Free resource
3 Config Mistakes That Break Fabric Networks in Production
The checklist our team uses before every Fabric deployment — covers peer gossip, orderer raft settings, and CA enrollment traps that cause 80% of production failures.
Skip weeks of setup — get to production in minutes.
Most teams spend weeks on infrastructure before writing a single line of business logic. Book a call and I'll show you how ChainLaunch cuts that to minutes — and whether it's the right fit for your project.
