The most common opening question our team gets in a blockchain scoping call is also, almost always, the wrong one: “should we use a private chain or a public chain?” The question feels rigorous. It sounds like an architecture decision. In reality it is a category error — it assumes the project has a single chain at its centre, and that the work of design is to pick the correct one. For real-world asset projects, that assumption breaks the moment the engineering gets serious. The honest answer almost always involves two chains doing two different jobs, joined by a deliberately designed bridge with human verification sitting on top.

Our consultants have shipped this pattern across carbon-credit registries, exchange order books, and asset-provenance systems. The same shape recurs every time: Hyperledger Fabric (or a similar permissioned chain) carries the operational state — the high-volume, sensitive, governance-heavy data that the consortium needs to run the asset. A public chain like Polygon carries the small subset of that state which needs to be globally tradeable, transferable, and provable to counterparties outside the consortium. The bridge between them is where the real engineering lives, and where most projects either succeed quietly or fail expensively. This piece sets out how our engineering team thinks about that hybrid, and why we now propose it as the default reference architecture before a client has even told us which asset class they want to tokenise.

Key Takeaways
  • “Private chain or public chain?” is the wrong question for real-world asset projects — the right question is which layer of state belongs on which chain.
  • Hyperledger Fabric is the right home for high-volume, sensitive, governance-heavy operational data; a public chain like Polygon is the right home for tradeable, globally-visible token state.
  • The hardest engineering in any hybrid design is the bridge: signer custody, mint authorisation, provenance receipts, and reverse event listening must all be designed deliberately.
  • Independent human verification (auditors, registries, notaries, custodians) is a first-class system actor in this pattern, not an afterthought bolted on at the end.
  • The same hybrid pattern applies cleanly to carbon credits, regulated securities, real estate, commodities, supply chain provenance, and asset registries — it is asset-agnostic by design.

The False Choice: Private vs Public

The private-versus-public framing persists because it is easy to explain in a single slide. A private chain offers privacy, throughput, and governance; a public chain offers censorship resistance, market access, and immutability. Pick the column that matches the use case, the story goes, and the architecture is settled. The problem is that real-world asset projects do not have a single use case. They have at least two, and the two have opposite requirements.

Private-only architectures lose the property that made blockchain interesting in the first place: trust without a trusted operator. If every node in the network is run by members of a single consortium, the integrity of the ledger collapses back to the integrity of that consortium — which is a governance problem, not a cryptographic one. A buyer outside the consortium has no independent way to verify that the recorded state has not been edited, replayed, or quietly reorganised. For internal operations that is acceptable. For tradeable assets that need to move between strangers, it is not.

Public-only architectures break in the opposite direction. Putting high-volume operational data on a public chain forces every read and write through gas auctions, throughput ceilings, and a public mempool. Commercially sensitive data sits in the open. Privacy patches (mixers, zero-knowledge proofs) add cost and complexity that almost never repay themselves for ordinary business state. Worse, the consortium loses the ability to apply governance — to suspend, correct, or partition data — because the chain itself has no concept of a regulator or an auditor with elevated rights.

The real answer for almost every real-world asset project our team works on is both chains, at different layers, with a deliberate bridge between them. Each chain does what it is genuinely good at, and the architecture stops trying to force one chain to play a role it was never designed for.

The reframing: The architecture question is never “which chain?” It is “which state belongs on which chain, and how does state move between them safely?”

What Belongs on a Private Chain (Hyperledger Fabric)

The private chain is where the operational reality of the asset lives. Most of the data a tokenisation project generates is sensitive, high-frequency, and only relevant to the consortium of operators, regulators, and auditors who actually run the asset. Putting that data anywhere else is a category mistake. Our team uses four criteria to decide whether a piece of state belongs on Hyperledger Fabric: write frequency, sensitivity, governance access, and finality requirements.

State that is written thousands of times a day — meter readings, order book updates, audit events — needs a chain that does not charge per write and does not auction block space. State that contains commercial, personal, or regulatory information needs a chain that can partition visibility by channel and by identity. State that auditors or regulators need to access on demand, but that should not be globally browsable, needs a chain that understands the difference between a member and the public. State that must finalise deterministically, without the risk of a reorganisation or a stuck transaction in a congested mempool, needs an ordering service rather than a probabilistic consensus.

Hyperledger Fabric strengths for this layer

Hyperledger Fabric satisfies all four criteria in ways that map directly to how our consultants design the operational layer:

  • Channels partition data so that only the members of a particular sub-network can see particular state — useful for separating customers, jurisdictions, or commercial sensitivities inside the same consortium.
  • MSP-based identity means every transaction is signed by a known organisation; there are no anonymous writers, and revocation of a misbehaving party is a governance action rather than a fork.
  • Deterministic ordering removes the entire class of failures that come from probabilistic finality: once a transaction is committed, it is committed, with no waiting for confirmations.
  • There are no transaction fees, which means high-volume operational writes do not cost more during a market event and do not require a treasury management process.
  • Governance is a first-class concept: regulators, auditors, and consortium members can be granted differentiated read and write rights, which is what real-world compliance actually demands.

Taken together, that combination is precisely what an operational asset platform needs: a permissioned, deterministic, partitioned ledger that the consortium runs together and that regulators can inspect on their own terms.

Concrete examples from our project base

Across our carbon-credit and asset-registry work, our engineering team has put the following kinds of state on Hyperledger Fabric: high-frequency energy meter readings flowing in from monitoring devices; exchange order books with all the bids, asks, and matches that drive price discovery; full audit event streams capturing every action taken by every operator in the consortium; and internal asset registries that describe what exists, who owns it, and what has been done to it. None of this state belongs in public view, but all of it has to be auditable on demand — which is exactly the brief Hyperledger Fabric was built to satisfy.

What Belongs on a Public Chain (Polygon / EVM)

The public chain is where the small subset of state that genuinely needs global consensus lives. The key word is “small”. Most of an asset platform’s data has no business being publicly visible; only the part that needs to move between strangers does. That subset usually shares four characteristics: it needs to be transferable across counterparties who do not share a consortium membership, it needs market price discovery in venues the consortium does not control, it needs to integrate with public token standards and DeFi infrastructure, and it needs immutable global provenance that no single party can quietly rewrite.

Carbon credits illustrate the test cleanly. The audit trail of how a tonne of CO2 was measured, verified, and registered belongs on the private chain — thousands of meter readings, dozens of verifier sign-offs, internal accounting events. But the final tokenised credit, once issued, must be globally transferable, must trade against other tokens, must be visible to regulators and counterparties outside the consortium, and must carry an immutable provenance hash that proves which audit trail produced it. That single token is what belongs on the public chain. Everything that produced it stays private.

Why Polygon specifically

When our consultants recommend a public chain for the token layer, Polygon is the default. The reasons are practical rather than ideological:

  • EVM compatibility means the entire toolchain — Solidity, Hardhat, OpenZeppelin libraries, established auditors — works without bespoke porting work.
  • Gas costs are low enough that mint, transfer, and retirement events do not introduce friction that kills the user experience.
  • There is an established tokenised-asset ecosystem on Polygon, including major carbon registries and real-world asset projects, which means the chain is not an experiment.
  • Credible bridges to Ethereum mainnet exist, so assets that need to migrate upward for institutional liquidity can do so without a re-deployment.
  • The token standards (ERC-20, ERC-721, ERC-1155) are mature enough that integrators, wallets, and exchanges already know how to handle the assets we mint.

None of those reasons depend on a particular market narrative. They depend on the practical question of whether the public chain will still be around, still maintained, and still interoperable in five years. Polygon currently passes that test for the asset classes our team works with.

What our team does not put on public chain

A surprising amount of project pain comes from teams putting the wrong things on the public chain because the technology felt impressive. Our engineering team explicitly keeps the following off-chain or on the private chain only: user PII (names, identification numbers, contact details), raw operational data such as individual meter readings or order book events, internal accounting balances and reconciliation state, KYC and AML records, commercially sensitive pricing histories, and any draft or in-progress state that has not been signed off by a verifier. Once something is on a public chain it is on a public chain forever; the discipline of deciding what genuinely needs to be there is half the architecture.

The Bridge: Where the Real Engineering Happens

The bridge between the private and public chains is where most of the project risk concentrates. The chains themselves are mature, well-understood, and have large communities of operators who can help when things go wrong. The bridge is bespoke, and bespoke means it is the part most likely to be designed badly. Our consultants treat the bridge as the central engineering deliverable of any hybrid project, not an integration task to be finished in the last sprint.

Four design patterns dominate the bridge layer. The first is signer custody on the public side: the keys that authorise mint, transfer, and burn transactions on the public chain must be held under a custody model that the consortium can defend — usually a multi-signature wallet, increasingly a threshold-signature scheme, with hardware-backed signers and a clear governance process for adding or removing signers. The second is the mint authorisation pattern, which we describe in detail below. The third is provenance: every token minted on the public chain carries, in its metadata, the Hyperledger Fabric transaction hash of the operational event that justified the mint — so a sceptical counterparty can request the audit trail and verify that the public-chain token corresponds to a real, signed-off, private-chain event. The fourth is reverse event listening: the consortium runs services that watch public-chain events (transfers, retirements, burns) and write them back into Hyperledger Fabric as accounting entries, so the operational ledger always knows the current state of every tradeable token.

The mint authorisation pattern we use

The mint authorisation pattern is the single most important design choice on the bridge. Our engineering team has converged on a five-step pattern that consistently survives both audit scrutiny and adversarial testing:

  • Private-chain state is prepared: the underlying operational event (a verified carbon abatement, a confirmed warehouse receipt, a settled share allotment) is fully recorded on Hyperledger Fabric with all supporting evidence.
  • A human verifier signs off: an independent auditor, registry, or custodian reviews the private-chain record and signs a verification transaction inside Hyperledger Fabric, attesting that the underlying claim is real.
  • A mint request is generated and signed by a multi-signature authority that represents the consortium, not any single party — usually requiring at least two of three or three of five signers to approve.
  • The public-chain smart contract executes the mint: the contract checks the multi-signature, optionally checks the provenance hash against an oracle, and creates the new token.
  • The public-chain transaction hash is written back to Hyperledger Fabric as a provenance receipt, closing the loop so that both ledgers can independently prove the lineage of every token in circulation.

That five-step pattern is deliberately conservative. It introduces latency between operational readiness and token issuance, and that latency is the feature, not the bug — it is the window in which fraud is caught and errors are corrected before they become immutable.

Bridge security failures we have seen

Without naming specific projects, our team has reviewed bridge designs that failed for predictable reasons: hot wallets holding mint authority with a single signer (one compromised laptop becomes an unlimited mint exploit); race conditions where a private-chain event triggered a mint before the verifier had finished reviewing (verification became theatre); replay vulnerabilities where the same mint request could be submitted twice because the contract did not track nonce state per request; and oracle dependencies where the public-chain contract trusted an off-chain price feed that had no signature scheme at all. The five-step pattern above is shaped by those failures — multi-signature custody removes the single-signer risk, the explicit verifier step prevents premature minting, nonce tracking blocks replays, and provenance hashes anchored in Hyperledger Fabric remove the need for trust in any unsigned external feed.

Where Human Verification Still Belongs

The most expensive mistake our consultants see in early-stage tokenisation projects is the assumption that human verification can be designed out. The thinking usually runs: if the data is on the blockchain, it must be trustworthy, so the auditor is just a process bottleneck we can remove. That reasoning is exactly backwards. The blockchain guarantees the integrity of the record after it has been written; it guarantees nothing at all about whether the underlying real-world claim is true. Was the carbon actually abated? Does the warehouse actually contain the rice? Does the share certificate actually represent ownership? Those are not cryptographic questions and cannot be answered cryptographically.

Every real-world asset class has an existing verification regime that the hybrid architecture must respect, not bypass. Carbon credits depend on independent verifiers operating under Verra, Gold Standard, or equivalent registries. Real estate depends on notaries, land offices, and title insurers. Regulated securities depend on auditors, registrars, and custodians. Commodity warehouse receipts depend on inspection regimes and bonded operators. In every case, the bridge from private chain to public chain must pause for a sign-off from the relevant verifier before the mint is allowed to proceed. Skipping that pause does not make the system faster; it makes the resulting token unsellable to any counterparty who actually understands what they are buying.

Designing for the verifier, not around them

Our team treats the verifier as a first-class system actor with their own identity, their own signing keys, their own user experience, and their own audit interface inside Hyperledger Fabric. The verifier does not log into a separate compliance portal; they sign verification transactions directly into the operational ledger, where their signatures become part of the immutable provenance that the public-chain token will eventually reference. That design has two consequences worth naming. It makes the verifier’s work visible and accountable in a way that paper-based regimes never managed. And it makes the resulting tokens defensible in any future dispute, because the chain of custody from raw operational event to public-chain mint is unbroken and signed at every step.

The trust handoff: The blockchain proves what was written. The verifier proves what was true. A hybrid architecture that takes either half seriously must take both halves seriously.

The Hybrid Pattern Across Different Real-World Assets

The pattern our team has described so far was first sharpened in carbon-credit work, but it is not specific to carbon. The same private-operational-plus-public-tradeable split applies cleanly to every real-world asset class our consultants have scoped. The clearest way to see this is to walk through four examples and note where the chain boundary falls in each one.

Regulated securities split naturally. The cap table, the shareholder register, the dividend history, the corporate actions, and the KYC records all belong on the private chain under the registrar’s governance. The transferable share token — the thing a regulated secondary market actually trades — belongs on the public chain as an ERC-20 or ERC-1400 instrument, with the private-chain registrar acting as the verifier who authorises every mint and transfer.

Commodity warehouse receipts split the same way. The inventory ledger, the inspection reports, the moisture-content tests, the bonded-operator audit trail, and the chain of custody from harvest to warehouse all belong on the private chain. The tradeable warehouse receipt — the instrument a buyer in another country wants to purchase and finance against — belongs on the public chain, with the warehouse operator and inspector acting as the verifiers.

Real-estate fractional ownership splits cleanly too. The title record, the rent-collection history, the maintenance and capex events, the tenant-mix data, and the local-authority filings belong on the private chain under the property manager’s and notary’s governance. The fractional ownership token belongs on the public chain, where it can be transferred between investors and integrated with secondary markets.

Supply chain provenance follows the same pattern at a different granularity. The shipment-level data — container temperatures, customs filings, supplier audit results — lives on the private chain visible only to the parties in that consortium. The product-level provenance claim — the thing a consumer scans on a packet of coffee — lives as a public-chain token or signed claim that anyone can verify without needing access to the underlying commercial data.

The payoff is worth stating explicitly: the hybrid pattern is asset-agnostic. Once our engineering team has helped a client understand the split for one asset class, the same architectural reasoning carries straight across to the next.

The Default Architecture Our Team Now Proposes

When a client now asks our consultants “should we use blockchain for X?”, the answer is no longer a single-chain recommendation. It is a hybrid reference architecture: Hyperledger Fabric for the operational core, a public chain (usually Polygon) for the tradeable token layer, an explicit verifier-gated bridge between the two, and a clear inventory of which state belongs on which side of that bridge. The reference implementations that prove the pattern in practice are already in our portfolio: the MRV platform is our reference implementation of the private-to-public mint pattern with verifier sign-off; the Exchange platform is our reference implementation of Hyperledger Fabric as the operational trading core that issues to a public-chain token layer. Together they cover both halves of the hybrid in a single deployed system.

The reason our team now proposes this as the default is that it saves clients from the two failure modes we see most often. The first is over-publicising sensitive data — teams that put the entire operational ledger on a public chain and discover, six months in, that they have exposed commercial information they cannot retract. The second is over-privatising tradeable state — teams that keep the token layer inside the consortium and discover that no external counterparty is willing to accept a transferable asset that cannot be independently verified on a public network. The hybrid pattern is the architectural answer that avoids both mistakes simultaneously.

The architecture is not free. It requires more engineering than either single-chain approach, particularly on the bridge. It requires the consortium to operate two different infrastructures and to recruit skills in two different ecosystems. It requires the verifier role to be designed in from day one. None of that is trivial. But our consultants now treat it as the honest cost of doing real-world asset tokenisation properly — and we treat any project plan that pretends one chain will do the whole job as a plan that has not yet been pressure-tested.

Bottom line: For real-world asset tokenisation, “private or public?” is the wrong question. The right architecture is Hyperledger Fabric for operational state, a public EVM chain for tradeable state, and a verifier-gated bridge between them. That hybrid is what our team now proposes by default — because it is what survives contact with regulators, counterparties, and time.