ChainDeploy is the open-source binary (Apache 2.0); ChainLaunch is the paid managed cloud product built on top of it.
Insurance has been on every "blockchain use case" slide deck since 2018. The pitch writes itself: a shared policy ledger between primary insurers, reinsurers, brokers, and a regulator collapses reconciliation, cuts treaty-settlement disputes, and makes fraud detection a join instead of a phone call. The reason it hasn't shipped at scale is unglamorous. Premium and claim amounts are commercially sensitive, classic Hyperledger Fabric's private-data-collections add operational complexity that scares actuaries, and the throughput needed for real-time premium settlement across millions of policies has been out of reach for permissioned chains.
Fabric-X (also written FabricX or Hyperledger Fabric X) changes the throughput half of that equation. Linux Foundation Decentralized Trust benchmarks (April 2026) clock Fabric-X at 400,000+ TPS with a 4-party / 4-shard configuration. Combined with token-sdk-x for Pedersen-commitment-based private value transfer, you get a permissioned ledger where the consortium sees that a premium was paid without seeing for how much — and where the regulator holds the audit key to decommit selected transactions for solvency review.
This guide walks through running that exact demo on your laptop in roughly 10 minutes using ChainLaunch's fabricx-build-usecase skill. Five organizations, four namespaces, private token-sdk-x settlement, and a browser UI you can click through. Nothing in this post is theoretical — every flow is implemented in the open-source scaffold.
TL;DR: The fabricx-build-usecase skill provisions a 5-org P&C insurance consortium (InsurerA, InsurerB, Reinsurer, Broker, Regulator) on a Fabric-X network. Policy issuance and claim metadata go to public namespaces; premium and treaty-cession settlement uses token-sdk-x Pedersen commitments with the Regulator holding the audit key. One command stands up the network, mints identities via the ChainLaunch KEY_ISSUE_EXTERNAL API, brings up the Go sidecar and Vite UI, and prints a URL to open. Total time: under 10 minutes on a 16 GB laptop.
If you haven't run a Fabric-X network before, start with the chaindeploy FabricX quickstart — this post assumes you have one running. For the architectural background on Fabric-X itself, the What Is Fabric-X guide covers Arma BFT, namespaces, and the microservices model.
Three properties make Fabric-X a better fit for insurance consortia than classic Fabric or public chains, and the trade-offs matter when you're explaining the architecture to a head of underwriting.
Throughput at consortium scale. A mid-sized European motor-insurance market processes roughly 20,000 policy events per second at peak. Classic Fabric's 3,500 TPS Raft ceiling (ACM, 2024) requires shard-by-region workarounds that defeat the cross-border-reinsurance use case. Fabric-X's 400,000+ TPS Arma BFT throughput (Linux Foundation Decentralized Trust, April 2026) handles real-time premium settlement and claims fan-out without architectural gymnastics.
Single-channel namespaces, not channel-per-pair. Classic Fabric's "one channel per private relationship" model means a consortium of N insurers needs roughly N² channels for bilateral treaty settlement. Fabric-X uses on-chain namespaces inside a single channel — policies, settlement, claims, treaties — each with their own access policy. The operational difference is that you manage one ordering service, one set of TLS certs, and one monitoring dashboard for the entire consortium.
Native private value transfer. Premium amounts and claim payouts are commercially sensitive. token-sdk-x provides Pedersen commitments — cryptographic blinding of token amounts such that the consortium sees a transfer happened and a regulator with the audit key can decommit it, but no other party sees the value. This is the same primitive Bank of Canada used in the SX1 CBDC research, applied here to insurance settlement.
A 5-org Fabric-X insurance consortium combines Arma BFT throughput (400,000+ TPS), single-channel namespaces, and token-sdk-x Pedersen commitments to deliver real-time premium settlement that's confidential to other carriers but auditable by the regulator. That trade-off is impossible to assemble cleanly on classic Fabric — and not commercially deployable on public chains.
Free resource
87% of Blockchain Projects Die Before Production — Readiness Scorecard
Score your project across 5 dimensions: infrastructure, key management, monitoring, DR, and team readiness. Know exactly where the gaps are before they kill your timeline.
The fabricx-build-usecase insurance skill scaffolds a working five-organization P&C consortium with four namespaces tied to specific transaction types. The shape mirrors the consortium structure most reinsurance treaty markets actually run.
Each namespace has its own endorsement policy, on-chain access control, and visibility scope. The split between "plain KV" (everyone can read the contents) and "token-sdk-x ZK" (amounts are blinded with Pedersen commitments) is the privacy boundary in the demo.
The demo's Go sidecar exposes a REST API that the Vite UI calls. Every endpoint maps to exactly one namespace and is signed by exactly one MSP. The full surface is documented in the scaffold's docs/architecture.md; here's the headline subset:
POST /v1/policies — issuance, signed by an insurer MSP, written to policies
POST /v1/premiums — token transfer insured → insurer in settlement (amount blinded)
POST /v1/claims — FNOL submission to claims (broker or insured proxy)
POST /v1/claims/{id}/decision — approve/deny by the issuing insurer
POST /v1/claims/{id}/payout — token transfer insurer → insured in settlement
POST /v1/treaties — treaty terms with 2-of-2 endorsement between ceding insurer and reinsurer
POST /v1/cessions — token transfer insurer → reinsurer in settlement, per treaty quota share
The whole flow is one skill invocation against a running ChainLaunch instance. The skill handles network creation, identity minting via KEY_ISSUE_EXTERNAL, sidecar build, UI build, and the final smoke test.
cd ~/projects/chainlaunchclaude> /fabricx-build-usecase insurance
Or from a non-interactive shell:
claude --skill fabricx-build-usecase --args "insurance"
The skill prompts for the ChainLaunch base URL (defaults to http://localhost:8100) and admin credentials, then runs through 10 phases without further interaction.
The skill prints a status line per phase. Each one is idempotent — re-running the skill against a partial state picks up where it left off rather than starting over.
Scaffold sibling repo at ~/projects/chainlaunch/fabricx-insurance-demo/
Provision orgs via POST /api/v1/organizations — five MSPs
Create Fabric-X network via POST /networks/fabricx — single MSP orderer committee
Create namespaces via POST /networks/fabricx/{id}/namespaces — four namespaces with their endorsement policies
Mint app signing identities via POST /keys/issue-external — one per org for the sidecar to sign with
Bind chaincodes — token-sdk-x bindings to settlement, plain-KV chaincode to the other three
Build the Go sidecar at fabricx-insurance-demo/server/cmd/main.go
Build the Vite UI at fabricx-insurance-demo/web/
Start sidecar + UI on ports 17500 (REST) and 5275 (UI)
Run smoke test — curl POST /v1/policies with a sample property policy, then verify via the ChainLaunch tx-by-id endpoint
When the skill finishes, the last line prints the demo URL:
✅ Insurance demo running at http://localhost:5275
Smoke-test policy issued: txId=fe9a3c... (block 4)
Open the URL above to explore.
You land on a persona picker: 🏛️ Regulator, 🏢 InsurerA, 🏢 InsurerB, 🌐 Reinsurer, 💼 Broker. Each persona has a colored accent (violet, emerald, emerald, sky, amber) and a tailored dashboard.
The UI is intentionally not a polished SaaS — it's a technical demo. Every action surfaces the txId, block height, endorsers, and (for settlement transactions) the Pedersen commitment plus range/ownership proof summary. Hiding the on-chain machinery would defeat the purpose for the technical audience the demo is built for.
The InsurerA dashboard shows premium and claim totals (token-sdk-x balance from QueryService), recent policy issuances, and a green "Issue policy" button. Click it, fill in coverage type / sum insured / period, and the sidecar:
Builds an envelope and signs with the InsurerA-minted key
Sends to the Fabric-X orderer router on its router port
Polls the committer's namespace state via the Postgres-protocol query endpoint
Surfaces the new policy in the table once status flips to COMMITTED
The side panel pops open with the technical detail: txId, channel, namespace policies, block height, endorsing org IDs, read set, write set. For a technical reviewer, that side panel is the demo.
The Broker dashboard has a "Submit claim" button. The flow signs the FNOL with the Broker key and writes to claims. The interesting bit is what happens next: the claim is now visible to InsurerA and InsurerB simultaneously, so a fraud-detection join across both insurers' policy books can run on shared on-chain state instead of through an off-chain data clearinghouse. The demo doesn't ship a fraud-detection engine — it ships the data substrate that one could read from.
Once the broker submits and the insurer approves, the "Pay claim" action triggers a token transfer in the settlement namespace. This is where token-sdk-x does its real work. The transfer is signed by InsurerA's owner key, builds a Pedersen commitment for the payout amount, generates a range proof (amount > 0) and an ownership proof (InsurerA actually held the tokens), and submits to the orderer.
The side panel for this transaction shows:
The standard chain detail (txId, block, namespace settlement)
The Pedersen commitment hash on the ledger
The range and ownership proof verification status
What the consortium sees: a transfer happened, the proofs verified, the commitment is on-chain. What the consortium does not see: the payout amount.
Private settlement uses token-sdk-x Pedersen commitments — a binding-but-hiding cryptographic commitment C = aG + bH where a is the amount and b is a blinding factor. Other consortium parties see the commitment and verify range + ownership proofs but cannot extract a. The Regulator holds the audit key to decommit selected transactions for solvency review.
From the Regulator's view, every settlement namespace transaction shows up with status pills but no amounts — the same view every other party sees. What's unique is the "Decommit" action: click any settlement row, the sidecar uses the Regulator's audit key to decrypt the commitment, and the actual amount appears in the UI.
This is the property that makes the demo plausible for real insurance compliance: commercial confidentiality between competing carriers, transparency to the supervising regulator, all in the same ledger.
On the reinsurer side, the view splits into treaty positions (quota share percentages from the treaties namespace) and cession history (token transfers in settlement). The interaction worth walking through is the treaty-create flow: it's a 2-of-2 endorsement between an insurer and the reinsurer. The sidecar collects both signatures before submission, and the chain commits the treaty only if both sigs are present. Recurring cession transfers afterward sign with the ceding insurer alone, per the treaty's quota-share rule.
Free resource
87% of Blockchain Projects Die Before Production — Readiness Scorecard
Score your project across 5 dimensions: infrastructure, key management, monitoring, DR, and team readiness. Know exactly where the gaps are before they kill your timeline.
A scaffold isn't a production deployment. Here's what the demo intentionally leaves out so you know where the scope ends:
No ISO 20022 message mapping. Real insurance settlement integrates with bank payment rails using ISO 20022. The demo skips this entirely; you'd add a separate gateway.
No Solvency II or IFRS 17 calculations. The Regulator dashboard shows audit decommits, not solvency capital ratios.
No actuarial pricing. Policy premium amounts are inputs, not derived. Plug in a pricing engine elsewhere.
No reinsurance treaty math at the validator. The scaffold records treaties and processes cessions according to user-supplied amounts; it does not enforce quota-share or excess-of-loss math on-chain.
No claims adjuster workflow beyond approve/deny status transitions. Real claims processes have 10-20 status states plus document attachments.
ChainLaunch's POST /networks/fabricx/{id}/namespaces API in May 2026 accepts exactly one endorsementPublicKeyPEM. For the settlement namespace, that means only one MSP can mint premium credits. The demo sets InsurerAMSP as the sole issuer in v0 and documents the limitation. For a multi-issuer settlement namespace (so both InsurerA and InsurerB can mint premium credits independently), the namespace endorsement policy proto needs extension — there's an open issue tracking that follow-up.
The scaffold is a starting point, not a production deployment. Three concrete extensions match what real insurance pilots ask for:
Add a claims-adjuster persona with multi-step status transitions (Reported → Investigating → Adjusted → Approved → Paid → Closed), each persisted as append-only events to the claims namespace. Five-minute UI extension, valuable for showing audit lineage.
Wire premium-receipt webhooks to a bank rail. When a POST /v1/premiums transaction commits, fire a webhook to a payment processor stub. This makes the demo plausible for an ops audience that cares about the on-rails / off-rails handoff.
Plug in a fraud-detection rule engine that joins policies and claims namespaces and surfaces "same insured at two carriers within 30 days" patterns in the Regulator dashboard. The on-chain state is already shared — the rule engine is straightforward Postgres queries against the committer's query-service.
All three names refer to the same project. The Linux Foundation Decentralized Trust documentation prefers Fabric-X (hyphenated). chaindeploy's CLI and UI use the unhyphenated fabricx token (e.g., chainlaunch fabricx quickstart). The official long-form name is Hyperledger Fabric X. The community uses all three interchangeably.
token-sdk-x is the Hyperledger Labs token framework for Fabric-X. It handles the private-value primitives the insurance demo's settlement namespace requires — Pedersen-commitment-blinded amounts, range proofs (amount > 0), ownership proofs (the spending party actually holds the tokens), and auditor-key decommitment. Without token-sdk-x you would build those cryptographic primitives yourself; with it, the sidecar calls a stable API and the on-chain logic ships pre-built.
Throughput depends on machine spec but is bounded by the underlying Fabric-X network, not the demo sidecar. On a 16 GB MacBook running the 22-container single-MSP quickstart, expect 500-2,000 TPS for policy and claim writes (plain KV namespaces) and 100-300 TPS for settlement token transfers (the proofs add CPU cost). For the published 400,000+ TPS (Linux Foundation Decentralized Trust, 2026) headline numbers, you need the 4-party / 4-shard benchmark hardware shape, not a laptop.
Yes. Decommitment is an off-chain cryptographic operation using the auditor key — the on-chain commitment is immutable and stays forever, and any holder of the auditor key can decommit any past transaction at any time. The Regulator dashboard in the demo lists every historical settlement row and lets you click any one to decrypt it. Audit lineage is therefore retroactive and complete, which is the property real regulators ask for.
token-sdk-x uses Pedersen commitments to blind token amounts on-chain. A commitment C = aG + bH (where a is the amount, b is a random blinding factor, and G/H are generator points on a curve) is computationally binding — you can't change the amount without changing the commitment — and computationally hiding — observers can't extract a from C without the blinding factor b. The Regulator holds the auditor key that allows decommitment for compliance. Other parties on the consortium see the commitment but not the amount.
The combination of permissioned governance (the consortium decides who joins), private value transfer (token-sdk-x), high throughput (Fabric-X's Arma BFT), and regulatory audit hooks fits insurance better than public chains (no permissioning), classic Ethereum (gas-priced transactions), or R3 Corda (lower throughput, different privacy model). The choice is workload-driven — if your use case is public assets with retail end users, the answer changes.
Yes for the v0 scope. The policies, claims, and treaties namespaces use a plain-KV chaincode that the scaffold ships pre-built. The settlement namespace uses token-sdk-x's standard token-transfer chaincode. You only write chaincode if you want to extend the demo with rules that need on-chain enforcement — quota-share math, time-bound claim windows, fraud-detection guards.
claude --skill fabricx-build-usecase --args "insurance --teardown" removes the network from ChainLaunch (which stops and removes all Fabric-X containers), kills the sidecar and UI processes, and leaves the scaffold repo for inspection. To also delete the scaffold: rm -rf ~/projects/chainlaunch/fabricx-insurance-demo.
No. As of May 2026, Fabric-X itself is MVP/preview state and chaindeploy v0.4.0 explicitly labels its FabricX support PREVIEW. The demo is meant for pilots, technical evaluations, and procurement RFPs that need a working artifact to evaluate. Production deployment requires the items in the "what's not in this demo" list plus an independent security audit of the Arma consensus codebase, which hasn't landed yet.
Insurance is the use case enterprise blockchain has been promising for seven years. The blockers were never "blockchain doesn't work" — they were throughput, privacy semantics, and operational complexity. Fabric-X resolves the throughput half. token-sdk-x resolves the private-value half. chaindeploy v0.4.0 collapses the operational half into a single CLI command.
A working consortium demo — five orgs, four namespaces, private settlement, regulator audit, on a real Arma BFT network — is now a 10-minute laptop exercise instead of a six-month procurement cycle. That's the whole point of running scaffolds: it lets your underwriting team, your reinsurance broker, and your CISO sit at the same table and click through a working flow before anyone spends real money on a pilot.
If you want to discuss adapting the scaffold for a specific consortium structure — different MSP topology, multi-issuer settlement, ISO 20022 integration, audit-trail extensions for a particular regulator — book a call with David or start running it now with ChainLaunch.
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
87% of Blockchain Projects Die Before Production — Readiness Scorecard
Score your project across 5 dimensions: infrastructure, key management, monitoring, DR, and team readiness. Know exactly where the gaps are before they kill your timeline.
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.
