A hybrid blockchain combines a permissioned environment, where known participants control access and see private data, with a public blockchain that provides shared integrity, settlement or proof. Institutions use it when data must stay confidential but the result has to be verifiable by others, for example in tokenised securities, payments and regulated registries.
Choosing a hybrid model is the easy part. We know, because at Neti we build the hard part. We connected stablecoin rails to a bank-grade double-entry ledger for Damisa. We put invoices and USDC payouts on-chain for MaxxChain while keeping driver KYC in a private backend. We designed on-chain escrow fed by off-chain construction data for BOHM. And we were called in to rebuild a private blockchain that looked healthy while carrying a million-scale backlog of unconfirmed blocks.
In every one of these projects the chain was not the risk. The risk sat at the boundary: where the on-chain world meets core banking, custodians and regulators. In September 2026 the FCA and the Bank of England published Feedback Statement FS26/1, built on 123 responses from banks, asset managers and market infrastructures. It confirms what we see in delivery: those boundaries are exactly where hybrid projects break.
This guide is written from that experience. It covers what a hybrid blockchain is, the patterns that work, what we learned on real projects, and the four decisions you have to get right before you write code: coexistence, settlement, interoperability and regulatory control.
Public, private, consortium and hybrid blockchains: what is the difference?
The four models differ in who can join, who validates and who can read the data.
| . | Public | Private | Consortium | Hybrid |
|---|---|---|---|---|
| Who can join | Anyone | One operator decides | Members decide | Permissioned layer controlled, public layer open |
| Who validates | Open validator set | Operator | Member nodes | Depends on layer |
| Data visibility | Everyone | Operator and invited users | Members | Private by default, selectively public |
| Typical use | Open settlement, public tokens | Internal ledgers | Industry utilities | Regulated assets, payments, registries |
| Main risk | Confidentiality | Single point of trust | Governance deadlock | Integration points between layers |
Ethereum and the XRP Ledger are public and permissionless. A consortium network is permissioned end to end. A hybrid blockchain always has a public component that outsiders can verify.
How does a hybrid blockchain architecture work?
A hybrid blockchain architecture has three parts: a permissioned execution layer, a public verification or settlement layer, and a bridge that decides what crosses between them and who can trigger it. Designing that split is a blockchain architecture decision, not a technology pick.
Five patterns cover most designs:
- Anchoring. A private ledger writes hashes of its state to a public chain, so anyone can prove records were not altered without seeing them.
- Permissioned assets on a public chain. ERC-3643 tokens can only be held by verified identities, and issuers can freeze or recover them. See our ERC-3643 glossary entry and tokenized securities work.
- Permissioned zones in a public network. The XRP Ledger's Permissioned Domains restrict trading to credentialed participants on a public ledger.
- Selective disclosure. Zero-knowledge proofs show a rule was followed without revealing the data. See Confidential yet compliant and our zero-knowledge proof privacy work.
- Synchronised settlement. The asset moves on a DLT platform, cash moves in another system, and both legs complete together or not at all.
Hybrid blockchain examples in finance
- Canton Network describes itself as a public blockchain with privacy for regulated markets, and DTCC's tokenization service is launching on it.
- ERC-3643 tokens issued on public EVM chains are a hybrid at the asset level.
- XRP Ledger is public, but institutional applications using its credential controls can be hybrid.
- UK Digital Securities Sandbox. Digital securities depositories settle on DLT while cash stays in traditional systems.
- IBM Food Trust is often called hybrid but is a permissioned Hyperledger Fabric network. Labels are not architecture.
What we learned building on-chain and off-chain systems
None of these published Neti projects is a textbook hybrid blockchain. But each client came to us with the same pain underneath: a process that had to live partly on a public chain and partly in controlled systems, and nobody had decided where the line runs.
Damisa: "Whose money is it right now?"
Damisa is a UK cross-border payments company moving money across banking and stablecoin rails. Its hardest question came before any code: "A payment stops halfway. The money has left one place and not arrived at the other. Whose is it right now?"
A single transfer passed through five balance positions: wallet, master wallet, liquidity provider, customer account, external bank. Bank rails settle on T+1. Blockchains settle on confirmation thresholds. Payments could arrive on the wrong chain. Without clear ownership at every hop, reconciliation was impossible and the regulator's questions had no answer.
We did not start with smart contracts. We started with a money model: what each object is allowed to own, and every transfer broken into hops with an owner, a ledger entry and an exception path. Stablecoins run on Ethereum and Tron through MPC wallets. The ledger of record is a self-hosted double-entry ledger tied to virtual IBANs and FX providers. A six-person team shipped the MVP in four and a half months. Today Damisa settles over $25 million a month across 70+ currencies, with fund ownership provable at every stage. Read the Damisa case study.
MaxxChain: drivers waiting weeks to get paid
In US trucking, most carriers are small, and cash flow is one of their tightest daily constraints. Drivers finished a shipment and then waited weeks for payment, while fuel, insurance and payroll kept running. Factoring helped, but it still depended on document checks, broker confirmations and back-office approvals, with little visibility into where an invoice stood.
The design decision was to keep blockchain out of the driver's way. Invoice records and USDC payouts run through smart contracts on an EVM chain. KYC, bills of lading and broker confirmations stay in a private backend with an admin review flow. Drivers use a simple mobile app and never touch a wallet. The result was one workflow from document upload to payout, replacing "a slow, manual freight factoring process". See the freight factoring case study.
BOHM: a token contract cannot build a house
BOHM wanted to tokenize construction and real estate. The problem: materials, vendor qualifications, work orders, milestone approvals and payments were disconnected processes with no verifiable record, and no proof that work was actually done. As the case study puts it, "a single token contract would not be enough to represent the complexity of a construction lifecycle". Building token features first would have created provenance, compliance and investor-confidence problems later.
We designed the layers before the code. Milestone escrow and multi-signature approvals sit on-chain. Construction data, material provenance and vendor identity stay off-chain and enter through oracles and verifiable credentials. BOHM got a delivery-ready architecture that connects construction data, vendor accountability and payments in one system. See the BOHM architecture case study.
In all three, the chain choice was never the hard part. The boundary was.
Why hybrid is the default
UK regulators expect tokenised and traditional infrastructure to co-exist "potentially indefinitely". Your ledger will not replace the CSD, the custodian or core banking. It will run beside them, and that is where projects fail.
Before you pick a chain, answer three questions:
- Which record is the legal source of truth when the same asset exists on DLT and in a traditional register?
- How do the two reconcile across custody chains, and who fixes a break?
- Can every asset be identified and returned if an intermediary fails?
These are the questions FS26/1 respondents flagged, and the same ones we answered for Damisa before writing code. It is the core of our stablecoin payments and settlement work.
How does settlement work between DLT and traditional systems?
Every hybrid trade has two legs: the asset moves on a ledger, the cash moves somewhere else. The design question is how you make both legs finish together. There are three models.
- Cash on the same ledger. Stablecoins or tokenised deposits settle against the asset in one atomic transaction. Simple, but you inherit the cash token's issuer and regulatory risk. UK authorities have confirmed stablecoins can be settlement assets in the Digital Securities Sandbox, subject to conditions.
- Synchronised settlement. The asset stays on DLT, cash stays in central bank money, and a coordinator locks both legs before releasing them. The Bank of England is building this as its synchronisation service, with a testing lab planned for 2026.
- Cash off-chain, reconciled after. The most common model today, and the riskiest. Bank rails settle on T+1, chains settle on confirmations, and someone has to own the gap. That was Damisa's problem, and the reason we build settlement middleware between chains and core banking.
Check finality before you promise speed. FS26/1 respondents warned that contractual finality does not protect against third parties in insolvency. Until statutory finality applies, assets pending settlement usually cannot be lent or used as margin. See atomic settlement.
Interoperability breaks on data, not bridges
Most interoperability failures are not technical. The token moves fine. What breaks is that the other side cannot recognise it, process it or treat it as the same asset. FS26/1 respondents said legal and regulatory interoperability matter as much as the technology.
Four checks before you connect a hybrid system to anything else:
- Identifiers. Does the token map to the instrument's existing identifiers, for example via the ISO 24165 Digital Token Identifier?
- Messaging. Can on-chain events be translated into ISO 20022 messages your bank's systems already process?
- Legal equivalence. Is the token legally the same asset as its record in the traditional register?
- Jurisdiction. Does it keep its status when it crosses a border?
Skip these and you get liquidity fragmentation: the same asset in pools that cannot talk to each other. The UK's Wholesale Digital Markets Champion is pushing for common APIs, messaging and reference data for this reason.
What regulators expect from a hybrid setup
Regulators do not approve architectures. They hold the regulated firm accountable for outcomes, and FS26/1 makes clear that using a protocol or a vendor does not move that responsibility. Each expectation below turns into a concrete design requirement.
| What regulators expect | What it means for your design |
|---|---|
| A regulated firm stays accountable, even when it uses third-party technology | Every admin key, upgrade path and incident runbook has a named owner inside the firm, not "the protocol" |
| No solutions where "customers have no recourse when assets are lost or stolen" | Freeze, forced transfer and key recovery functions, as in ERC-3643, instead of immutable-only tokens |
| Infrastructure can detect financial crime and support trading suspensions | Identity checks at transfer level, monitoring hooks and a tested pause function |
| Synthetic tokens keep the link between issuer and investor | Prefer native, identity-bound tokens tied to the official register over wrappers |
| Tokenised assets get the same prudential treatment where legal rights are identical and risks comparable (PRA, May 2026) | Document the legal rights and risk controls so your risk team can prove equivalence |
In the EU the same logic applies under MiCA, MiFID II and the DLT Pilot Regime. If a control is not in the architecture, it will not be there when a supervisor asks.
Where hybrid designs break
More boundaries mean more failure points. A permissioned validator set running consensus such as PBFT removes anonymous 51% attacks but adds key compromise and collusion risk among known operators. The permissioned layer also fails quietly: we rebuilt a private blockchain that looked healthy while carrying a million-scale backlog of unconfirmed blocks, and brought it down to double digits.
FS26/1 names the weak points that recent incidents exposed. Here is what to design for at each one:
| Failure point | What to design for |
|---|---|
| Bridges | Limits on what can cross, and a way to halt the bridge without halting both chains |
| Key management | Separated validator, issuer and recovery keys, with custody that meets traditional safeguarding standards |
| Governance | Written rules for who can upgrade, change validators or freeze, and an audit trail of every use |
| Oracles | More than one data source and a defined fallback when data is late or wrong |
| Cross-chain messaging | Idempotent settlement instructions and reconciliation that catches duplicates |
On custody, most FS26/1 respondents want tokenised securities held under the same rules as traditional ones, plus extra controls for private keys. Design for that now; the FCA consults on the detail in H1 2027. More in our blockchain security guide.
When should you choose a hybrid blockchain?
Choose hybrid when data is confidential, the outcome must be verifiable by parties you do not control, and you must connect to infrastructure that will not go away.
- Nobody external needs to verify? Use a private ledger or a database. We will tell you that.
- Institutions trust each other contractually? Consider a consortium. Our enterprise blockchain consulting starts there.
- Regulated asset needing public liquidity and identity controls? Go hybrid.
- Settling against cash in a traditional system? Decide the settlement model and check finality first.
How Neti helps
Bank architects know SWIFT and ISO 20022. Blockchain teams know on-chain flows. Hybrid projects need both in the same room. Neti designs the connection between on-chain assets and existing financial infrastructure, as we did for Damisa, MaxxChain and BOHM, and we are an XRPL Partner and contributor to the XRP Ledger core.
Book a free blockchain architecture consultation. You leave with answers to the four decisions above for your case, a layer map, and a recommendation, including "don't use a blockchain" when that is the right answer.
