For a bank or regulated fintech, a permissioned blockchain is usually the right base. On it, only known, approved organisations can validate transactions. Client data can stay private, and compliance rules can run before anything settles. A permissionless blockchain, where anyone can join as a validator, suits open products that need public reach. Many institutions end up with both: a permissioned core, and bridges (links that move assets between chains) to public chains where it makes sense.
What is the difference between permissioned and permissionless blockchains?
The difference is who can validate: who checks transactions and adds them to the shared record. On a permissionless blockchain, anyone with the right hardware or enough stake (coins locked up as a deposit) can run a validator. Bitcoin (proof of work) and Ethereum (proof of stake since 2022) work this way. Validators are usually pseudonymous: they use an address, not a real name. The network stays honest because an attack costs more than it earns.
On a permissioned blockchain, validators need approval before they join, and each one has a known identity. Hyperledger Fabric and R3 Corda are well-known examples of permissioned platforms. Here the network stays honest through identity, contracts and consensus. Consensus is the protocol by which validators agree on the record. This protocol tolerates a minority of bad actors.
A related but separate question is who can read the data. People often call that public versus private. A chain can be permissioned and still show each record only to the parties involved. That is how Hyper 0X works.
How do they compare?
| Topic | Permissionless | Permissioned |
|---|---|---|
| Who can validate | Anyone | Approved, identified organisations |
| Who is accountable | No one in particular | Each validator, by name |
| Who can see data | Everyone, by default | Can be limited to the parties |
| Finality | Probabilistic or delayed, depending on the chain | Usually deterministic |
| Rule changes | Network-wide governance or forks | Agreed by the members |
| Compliance checks | Each app adds them on top | The network can run them |
| Reach | Global, open liquidity | Members, plus bridges |
Why do banks need known validators?
A bank must know who processes its transactions. The EU’s Digital Operational Resilience Act (DORA) has applied since January 2025. Rules such as DORA expect financial firms to identify and manage the third parties behind their critical technology. On a permissionless chain, the validators that confirm your payment are unknown and can change at any moment. You cannot sign a contract with them or audit them.
A permissioned chain fixes that with PKI, or public key infrastructure. PKI is the system of certificates that ties a cryptographic key to a real organisation. It is the same idea behind the HTTPS certificates that websites use. On Hyper 0X, every validator is PKI-bound, so a known legal entity signs every vote that the validator casts.
Identity alone is not enough, so the consensus must also survive bad actors. Hyper 0X uses leaderless aBFT consensus (asynchronous Byzantine fault tolerance). It stays safe while fewer than one third of validators are faulty or malicious. There is no single leader to bribe or knock offline. Transaction order comes from the median time at which validators received each transaction. So no one node can push its own trade to the front.
How do you keep client data private on a blockchain?
On most permissionless chains, everyone can see every transaction. Addresses are pseudonymous, but chain analysis can often link them to real people and firms. For a bank, that exposes client balances, counterparties and trading patterns. Privacy laws such as GDPR add another problem. They give people rights to have their personal data corrected or erased. A public ledger that stores that data in the clear cannot honour those rights.
A permissioned network lets you limit who sees what. On Hyper 0X, each application runs on its own private L2: a private blockchain that settles on the main chain, the L1. Hyper 0X encrypts every payload (the data inside a transaction) separately for each party, so only the parties to a record can read it. Validators confirm and order the transaction, but they do not see its contents. We explain how this works in blockchain data encryption: the four layers.
How does compliance work on a permissioned blockchain?
On a public chain, compliance usually happens after the fact: a transfer settles, and then monitoring tools flag it. On a permissioned chain, rules can run before a transaction executes. Hyper 0X calls this compliance as code. It checks transfer limits, KYC status (know-your-customer identity checks) and maker-checker approvals first. In maker-checker, one person prepares a transaction and a second person approves it. A transaction that fails these checks never reaches the ledger.
Finality (the point after which nobody can reverse a transaction) matters here too. Regulators and lawyers care about the moment a payment becomes irreversible. A permissioned aBFT network gives deterministic finality: after confirmation, a transaction is final in one pass. See blockchain finality explained for why that matters.
Take a bank that wants to issue tokenized deposits (bank deposits held as tokens) to its corporate clients. On a private L2, only clients who have passed KYC can hold them. Per-client limits apply automatically. Only the sender, the receiver and the bank can see each transfer. If a client needs to move value onto a public network, the value goes through a bridge with its own rules.
When does a public blockchain still make sense?
Permissionless chains are the right tool when openness is the goal:
- Open products that anyone can use without asking.
- Public liquidity, such as stablecoins (tokens tied to the value of a currency) and investors who already hold wallets on Ethereum or Solana.
- Broad distribution of a tokenized asset to investors outside your own client base. See the asset tokenization guide.
- Public proof, where you want anyone to be able to check a fingerprint of a record.
The choice does not have to be all or nothing. Every L2 on Hyper 0X can use bridge adapters to reach EVM chains (Ethereum-compatible chains), Solana and Sui when its rules allow. Treat each bridge as a controlled gateway with limits and approvals. Bridges are among the parts of crypto that attackers target most. The Ronin and Wormhole bridge exploits of 2022 are well-known examples. For a wider comparison of public and private options, read private L2 vs public blockchain.
The diagram above shows the full picture. Bank, fintech and AI workloads each run on their own L2 and settle to the Hyper 0X L1. They reach public chains through bridges.
Where should you start?
- Classify your data. Decide what must stay private and what can safely be public.
- List the organisations that you will allow to validate and approve transactions. Note what your regulator expects to know about them.
- Write down the rules that must run before a transaction settles: limits, KYC and approvals.
- Find where you need public reach. Design those bridges with limits from day one.
- Run a pilot on one private L2 with clear success metrics.
Hyper 0X gives you a permissioned L1 with PKI-bound validators and a private L2 for each application. Our custom blockchain team can set up the pilot with you. Book a call to talk it through.
Architecture in detail
Frequently asked questions
Is a permissioned blockchain still decentralised?
It can be. That is the case when several independent organisations run the validators and every transaction needs agreement from a supermajority of them. It is less open than a public chain. For regulated finance, that is the point: everyone who can approve a transaction is identifiable and accountable.
Can a bank use a public blockchain?
Yes, for the right jobs. Examples are to issue a token that public investors can hold, or to reach stablecoin liquidity. A common pattern is to keep client data and core settlement on a permissioned network. The bank then connects to public chains through controlled bridges.
What is a PKI-bound validator?
A PKI-bound validator signs with a key that a certificate ties to a known organisation. The certificate comes from public key infrastructure (PKI), the same system behind HTTPS certificates. You can trace every vote that the validator casts to a legal entity.
