With the enterprise-driven push for blockchain in 2026, permissioned chains are finding their way back into the conversation. Consortium launches and institutional pilots have brought renewed attention to an architecture banks have been exploring since the early days of Quorum, Corda, and similar chains.
Today there are far more choices. A bank can build on a permissioned Layer 1, run a permissioned Layer 2 that settles to a public chain, or work with enterprise implementations of Besu and Fabric.
A fair assumption often comes with it. A blockchain is permissioned; therefore, it is private.
Well, is it?
Before we conclude permissioning and privacy in the same category, let’s look at what the network actually controls. Because a bank can know every participant on its blockchain and still share more information with them than it intended.
What Does Permissioned Mean From a Blockchain Architecture Point of View?
Let us first give permissioning its due.
It solves an important problem.
If Bank A, Bank B and Bank C are operating a shared blockchain network, they probably do not want Bank D joining tomorrow simply because somebody there managed to download the software and start a node.
Membership has to mean something.
A permissioned architecture therefore puts controls around who can operate nodes, who can validate transactions, which machines can communicate with one another and, depending on the implementation, which accounts are allowed to transact.
There may be node allowlists.
There may be certificates and mTLS between machines.
There may be a consortium process under which every new validator requires approval.
In other words, the network knows its participants like we mentioned before.
For regulated financial infrastructure, that is not some minor feature. It is almost a precondition.
But let us look at what happens after Bank A is admitted.
Bank A’s validator now participates in consensus.
To validate the shared state, that node ordinarily needs to receive the transactions and state necessary to verify what happened.
Bank B does the same.
So does Bank C.
This is where the apparently simple idea of a “private blockchain” starts becoming slightly more complicated.
The network may be private from the outside world.
That tells us nothing yet about privacy between the institutions inside it.
Permissioning has answered who may participate.
It has not necessarily answered what each participant may know.
I think this difference matters far more today than it did during the first generation of enterprise blockchain projects.
A bank may now run a permissioned Besu network. Another network may use Fabric. A financial institution may operate a permissioned Cosmos L1 chain. A consortium may even restrict the sequencers and validators of an enterprise Layer 2.
They all have different architectures.
But the same question is still there today.
Once I have given someone permission to validate my network, how much of my business have I also given them permission to observe?
That is where privacy actually begins.
Where is the privacy problem in a banking transaction
Let us take a banking transaction.
Suppose the investment arm of a bank in India has to buy a stock in the US, and it wants to move the required funds using a tokenized deposit. The transfer happens on the bank’s permissioned blockchain.
Who should see it?
The investment desk needs to see it. Compliance may need to see it. The team settling the stock purchase will also need it. But should the retail banking arm of the same bank see that transaction? Probably not. A large stock purchase, the amount and even its timing can be sensitive information inside the same institution.
Now if every department is connected to the same ledger with the same read access, the transaction becomes visible to all of them. Nothing went outside the permissioned network; still, the transaction is not private.
There is another issue here, which is data residency.
Banks run nodes in different regions for redundancy. If every node stores the same ledger, then a transaction between a US bank and a UK bank might also get stored on a node sitting in a third country. The node is approved, yes, but the data may not be allowed to sit there.
Now let’s see a transaction where more than one bank is involved. And let’s assume both are part of a consortium where multiple banks are there.
Say Bank A has to transfer some tokenized deposits to Bank B. Bank C is also part of the consortium and runs a validator. If all validators receive the same readable transaction, Bank C may see the amount, the two counterparties, and how the balances are moving.
Bank C was allowed to join the network. It was not part of this transaction. There may also be a consortium operator running the nodes and RPC infrastructure for all the banks. The member banks use an application and only see whatever that application shows them. But the operator underneath can still have a complete view of the ledger through RPC.
So when we say a network is private, private from whom? From the public, perhaps. But not necessarily from every other bank on the network.
Wallet allowlisting does not solve this. It controls which wallets can transact. Role-based access also does not hide a transaction once it is written in readable form.
So the conclusion is that once a transaction is written, it’s not necessary that it will be visible to the transacting parties only.
What Honestly A Permissioned Blockchain Solves
Now, none of this means permissioning is inadequate.
Because of permissioning, no anonymous party can run a node and read the full node data, unlike public networks. This is a big reason of why permissioned chains still matter for all kinds of regulated deployments.
What it does not do is because of the structural design of blockchains. It’s because of the layered architecture of blockchains. Once a participant is admitted, a standard transaction reaches every validating node in readable form, because consensus needs every node to check every transaction against the same state.
Here’s one thing you might find interesting. Besu once had a built-in private transaction feature. This was done with Tessera. They later deprecated it in 2024. What could this potentially indicate? Maybe that transaction-level privacy was never something the base chain was going to solve on its own, and that solutions built above or alongside it have to solve it.
Here are a few more ways others tackle privacy and permissioning. Fabric, for example, approaches the problem differently through channels.
And channels are certainly useful.
A subset of institutions can transact without broadcasting that transaction to every member of the wider Fabric network. But within the channel, participants still share the channel’s information.
So now the privacy architecture depends on channel design.
If there are three counterparties, perhaps that is manageable. What about twenty banks with different bilateral relationships?
Different assets? Different regulators?
At some point, the issue is no longer whether a protocol has a privacy feature. It is whether the privacy model matches the operating model of the financial network.
The same consideration applies to permissioned Layer 2 networks.
You may restrict who operates the sequencer.
You may restrict the validator set.
Very useful.
But unless additional mechanisms exist, those permitted operators may still observe the activity they are processing.
What’s missing in privacy then?
The first is application layer privacy for controlling who inside and outside a bank can query the ledger, call a contract, or read a value. It is enforced through an identity-aware gateway that sits between RPC nodes and the user access layer instead of inside the base protocol. This is the layer some asset and ledger-focused privacy stacks, for example Paladin, do not address directly. Their focus on privacy groups and zero-knowledge tokens that work on the asset layer. But application privacy has a very significant role. Let’s take this example. Assume multiple banks are part of the consortium, and everyone has different rules, and when a new bank joins, there is a new rule that needs to be encoded. At the smart contract level, this might be a risky proposition to update the smart contract every time. This can be achieved easily with application-layer privacy.
Application privacy is not a complete privacy solution, though. Because an application only intercepts the request before it reaches the node. These kind of tools that only filters JSON-RPC read access and control application-layer requests can solve the internal-visibility problem, maybe, but it cannot protect what is recorded in the ledger. For example, a transfer happening between two parties can not be open. What asset is being transferred, the amount, and related details should be visible to very limited persons on the network, which makes asset-layer privacy important.
Even that is not enough. Over 90% of blockchain transactions are not asset transfer transactions. For example, when we send an asset, there are at least 3 transactions happening, asset sending request, approval, asset send. Last one is masked through asset layer, but what about others? Their pattern can reveal much also. Ledger privacy brings that. So A bank trying to keep a transferred amount and counterparty confidential from other validators needs asset-layer cryptography for that, not RPC policy. So an RPC-gateway-only product will not cover it on its own. This has to be achieved through ZK circuits.
Privacy-enabled public chains on the other hand takes a different route entirely, separating the ledger so only entitled parties see a given transaction. Canton is built this way, and it is a legitimate answer for use cases built around a defined counterparty set that needs atomic settlement, repo and collateral workflows especially, where a large share of Canton’s live volume already sits. It is a heavier decision for a bank that just needs a tokenized deposit transfer to stay confidential on infrastructure it already runs, since it usually means adopting DAML contracts instead of popular smart contract languages, and it trades away network-wide verification of every transaction to get that confidentiality.
So, the point is, no single layer brings complete privacy by itself. What a bank needs is some combination of these tools.
Choose Zeeve Tegaris For the Missing Privacy Components
Zeeve Tegaris is built because all these privacy problems do not come as a package.
If the problem is that different people inside a bank should see different data, Tegaris provides private RPC access and a role-based explorer. If the amount and balance need to remain confidential from validators, confidential ZK tokens can be used. Ledger privacy with ZK circuits can protect the wider transaction activity and network privacy controls on who is allowed to participate in the network.
These layers can be used together or maybe separately only where needed. A bank running a permissioned Layer 1, a Layer 2, or maybe a Besu chain may also have different privacy requirements. Tegaris is a blockchain-agnostic privacy middleware that can work with any EVM chain or even non-EVM chains. So the bank does not have to leave its existing network just to get privacy.
Want to discuss its fit for your regulated blockchain use case? Schedule a call with our experts today!
