A permissioned blockchain has a gate. Privacy needs a few more walls.
Let’s suppose five banks decide to work from the same building.
It is not an ordinary office building. It has one shared record room where every deal, payment, and movement of money is entered. Whenever one bank adds a new record, copies are made for the others too.
The banks like this arrangement because nobody can quietly change an old record. If Bank A says a payment happened and Bank B later denies it, the other copies settle the matter.
This shared record room is our blockchain.
Of course, the banks do not let anybody walk into the building. There is a guard outside with a list of approved names. Only the five banks, their chosen employees, and a few operators are allowed in.
This is a permissioned blockchain.
The building is closed to the public, so everyone calls it private. There is only one small problem. After passing the guard, a person can still see almost everything inside.
The record room is open. The screens in the hallway show recent activity. Copies of the records are kept in each bank’s office. Even a technician who came to fix one screen may find that the other screens are working perfectly well for him too.
So yes, the building has a gate. But does it have privacy?
Not really. At least, not yet.
Because permissioning answers who is allowed to enter the network? It does not answer what they can see once they are in.
That leaves four separate privacy jobs linked with different layers of blockchain architecture.
Application level privacy, network level privacy, asset level privacy, and ledger level privacy. A bank may need two of these layers or all four. It depends on who shares the network and what kind of business is happening there.
Keep the building in mind. We will keep coming back to it.
Before privacy, understand what a blockchain exposes
A blockchain is usually spoken about like it is one machine. It is actually several things put together.
There are servers running the nodes. A network connects those nodes. Validators agree on the next block. The ledger keeps transactions and smart-contract state. Then there are all the tools people use to reach the ledger, such as wallets, RPC endpoints, APIs, explorers, indexers, and dashboards.
These tools do different jobs, but they also create different ways to see information.
A full/validator node keeps a copy of the ledger. An RPC endpoint answers questions about accounts and transactions. A block explorer puts the same information into a neat, searchable screen. An indexer copies blockchain data into another database so applications can search it faster. Smart contracts publish events, and other systems can sit there listening to them all day.
None of these tools are doing something wrong. They are built to make blockchain data available.
The trouble starts when the bank has not decided who the data should be available to.
Back to our building for a moment. Stopping strangers at the main gate is useful. But it does not help much if every room inside has a glass wall. Nor does putting a lock on one filing cabinet help if the same papers are being shown on a screen in the hallway.
Each privacy layer deals with a different opening.
Layer 1: Application privacy decides who can use which door
Suppose Bank A brings in a technology vendor to manage a payment application.
The vendor needs access to payment records. Fair enough. But it does not need to see Bank A’s treasury movements, client settlement history, and every contract being used by the other four banks.
Still, that can happen quite easily.
Most people do not interact with a blockchain by reading raw blocks. They use an explorer, a dashboard, an API, or some business software connected through an RPC endpoint. These are the doors through which ledger data is normally reached.
If every door opens into the whole building, the guard at the entrance is not doing enough.
A standard JSON-RPC endpoint may answer a query about any account or transaction. A normal block explorer may give every user the same view. An indexer may copy the complete ledger into a database. Event subscriptions may send contract activity to any system that has been connected.
No hacking is needed here. A vendor can see too much simply because nobody narrowed its access. A support engineer may be checking a failed node and end up browsing customer transactions. An analytics company hired for one report may quietly receive a copy of data from several other business lines.
Application-layer privacy is meant to stop this kind of overexposure.
Role-based access decides what each employee, vendor, application, or auditor is allowed to read. A private RPC gateway applies those rules whenever someone sends a request. The explorer can show different views to different people instead of treating every signed-in user like the owner of the place.
The same idea applies to smart contracts and event feeds. A user may be allowed to view a contract but not call an important function. An indexer may receive payment events but not treasury events. An auditor may receive a wider view, with every visit recorded in an audit log.
A simple diagram that shows the vulnerabilities and how this is being addressed.
In our building, application privacy is the set of keys and access cards used after a person has entered. The vendor gets the key to the payment office. It does not get one giant master key because that was easier to configure.
For an internal blockchain run by one bank, this layer may do most of the privacy work. It is also important when outside vendors, auditors, support teams, or several business units use the same network.
But there is a limit.
An access card can stop someone from opening a room. It cannot make that room invisible to another bank that already has a complete copy of the records in its own office. For that, we have to look at the network and the ledger itself.
Layer 2: Network privacy decides who is allowed in the building
Most institutions start with network privacy.
The network has an approved set of validators. New nodes go through an onboarding process. Old members are removed when they leave. Peer rules decide which nodes can connect to one another, and mutual TLS helps confirm that each node is speaking to the right machine rather than an impostor.
The infrastructure can also be kept away from the public internet. Operators, cloud providers, and managed-service teams can be placed under clear access and confidentiality rules.
All of this matters. A bank should know who is running the machines that hold its records. A consortium should know which member is allowed to validate transactions. A regulator will probably want to know too.
But let’s return to the building.
The guard outside checks names carefully. He keeps strangers away. He even records what time every approved person enters and leaves.
That makes the building secure from outsiders. It says nothing about what the five banks can see about one another.
This is why the line “we use a permissioned blockchain, so the data is private” is incomplete. Permissioning is membership control. Once a member joins and runs a full node, it may receive the same ledger as everyone else.
For one bank running all the nodes (a private ledger), that may be acceptable. For five competing banks (a shared network/ consortium), it is a different story. Each member could watch the others’ activity, not because it broke any rule, but because receiving ledger data is part of running the node.
Blockchain replication is the reason members can verify the history instead of trusting one central record keeper. But replication and confidentiality pull in different directions. If every participant receives the same information, every participant can potentially study it.
Network privacy gives the building a proper gate, and no institutional blockchain should be without one. It just does not put curtains on the windows inside.
Layer 3: Asset privacy decides what is inside the payment envelope
Now suppose Bank A sends money to Bank B.
The payment record shows the sender, the receiver, the asset, and the amount. Banks C, D, and E are not part of the payment, but their nodes may still receive the record.
One payment may not tell them much. After six months, they can begin to notice patterns.
They may see that Bank A sends large amounts to Bank B every Friday. They may notice its treasury moving funds at certain times of the month. They may work out which corridors are busy, which counterparties trade often, and where liquidity appears to be tight.
The ledger slowly becomes a map of Bank A’s business.
This is where asset privacy comes in. It hides the value being moved: the balance, the amount, the type of asset, and sometimes the identities of the parties.
One way to do this is with a zero-knowledge proof.
Suppose Bank A puts a payment instruction in a sealed envelope. The other banks cannot read the amount. However, attached to the envelope is a special proof showing that Bank A has enough money, the numbers balance, and the payment follows the agreed rules.
The network only can check the proof, but can’t read any private numbers inside the envelope.
That is roughly what a zero-knowledge system does. It allows the network to confirm that a transaction is valid without showing every detail used to create it.
This can mean confidential balances, hidden transfer amounts, private counterparties, and confidential minting or burning of tokens. It can also cover deposits and withdrawals when tokenized money moves in or out of the network.
There is an obvious question here though. If the transaction is hidden, how does an auditor verify it?
The answer is selective disclosure. The envelope is not sealed forever and for everyone. A regulator, auditor, or compliance officer can be given the right to inspect particular evidence under an agreed policy following the standard messaging standards. The other banks still do not get to look inside merely because they share the network.
Banks need asset privacy when the thing on the blockchain is money, or close enough to money that its movement reveals commercial information. Tokenized deposits, settlement assets, stablecoins, cross-border payments, and treasury transfers all fall into this area.
So now our shared building has a guard, access cards, and sealed payment envelopes. It sounds quite private.
We are still missing one room.
Layer 4: Ledger privacy decides who can see the meeting
A financial deal is rarely just a payment.
Take a repo between Bank A and Bank B. First, the parties agree on terms. Then collateral is locked. Cash is settled. The position is managed for a period, and later the whole thing is unwound.
Asset privacy can hide the amount of money in this deal. But the other banks may still see that a repo contract was used, which addresses interacted with it, when the steps happened, and how the contract changed from one stage to the next.
They cannot read the payment envelope, but they can stand outside the meeting room, see who went in, hear when people move around, and watch them leave with a collateral file.
Sometimes that is enough information.
A competitor may not know the exact terms, but it now knows that Bank A and Bank B completed a certain kind of transaction at a certain time. In institutional markets, that is not harmless metadata as it can reveal a trading relationship or a funding need.
Ledger-layer privacy makes the meeting itself private. The contract state and its execution are visible only to the parties involved and to others who have a proper reason to see them.
There is more than one way to arrange this.
- A private sub-ledger lets a smaller group of participants keep a shared record that the others cannot read.
- A private Layer 1 gives a defined group its own chain or chain segment.
- A ZK rollup carries out activity away from the base chain and sends back proof that the result is correct.
- A bilateral workflow keeps contract state between the two parties doing the deal.
- Privacy-scoped execution lets the wider network verify that a contract ran correctly without giving everyone the details.
The technical design may change from one platform to another. The purpose is the same: sharing a blockchain should not mean sharing every business process happening on it.
This matters in syndicated lending, where lenders may take part in the same facility without seeing one another’s private terms. It matters in repo and collateral management. It matters in OTC trade confirmation, where two parties do not want the rest of a consortium reading the history of their deal.
Asset privacy hides what was in the envelope. Ledger privacy closes the meeting-room door.
That is the difference.
Putting the four layers together
Our imaginary bank building now looks a little more sensible.
The guard at the main gate decides who belongs to the network. That is network privacy.
Access cards decide which rooms and screens each person can use. That is application privacy.
Payment details travel in sealed envelopes that can still be checked for validity. That is asset privacy.
Private deals happen in rooms where only the relevant parties can see the process. That is ledger privacy.
Here is the same idea without the building:
| Application | Who can query the chain, use an explorer, call contracts, or receive indexed data | Role-based access, private RPC, scoped explorer views, contract permissions, event filtering, audit logs | Staff, vendors, and applications may see more ledger data than their role requires |
| Network | Who can run nodes, connect as a peer, and validate blocks | Permissioned validators, node onboarding, peer rules, mTLS, private infrastructure | Outsiders or unapproved operators may gain access to the network |
| Asset | Who can see balances, amounts, assets, and counterparties | Confidential tokens, zero-knowledge proofs, selective disclosure | Other members may reconstruct transaction flows and commercial relationships |
| Ledger | Who can see contract execution and workflow state | Private sub-ledgers, private domains, ZK rollups, bilateral workflows | Deal metadata may reveal who is transacting and what they are doing |
Does a bank need all four layers?
Not always.
If one bank runs an internal blockchain for its own teams, application access and network controls may be enough. There are no competing banks operating nodes, so hiding every transaction with cryptography may create more work than value.
If several banks share a tokenized deposit platform, asset privacy becomes much more important. Members may trust one another to follow the network rules without agreeing to share their balances and payment history.
A consortium settlement rail carrying real volume may need all four layers. It has several node operators, many users, outside vendors, sensitive transactions, and regulators who require access of their own. A single privacy control will not cover all of that.
The blockchain platform changes the starting point too.
Networks such as Canton include privacy in the protocol. That gives institutions a ready-made privacy model, which is useful when the use case fits it. The same model may be less flexible when a bank wants very different privacy rules for different products.
Custom chains offer more freedom. A bank may build with Hyperledger Besu, a dedicated Cosmos-based Layer 1, an EVM chain, or a ZK-powered Layer 2. These networks often start with permissioned membership. The remaining privacy controls still have to be designed or added.
The better approach is to decide early which information may become sensitive as the network grows. Then the privacy layers can be added in a sensible order.
A few common questions
Isn’t a permissioned blockchain already private?
It is private from people who are not allowed to join. It may still be transparent to the approved members running nodes. Permissioning tells you who is inside the building, not what they can see there.
Can a regulator audit a confidential transaction?
Yes. Selective disclosure can give a regulator or auditor access to the required evidence without showing the same data to every network member. A zero-knowledge proof can also confirm that a transaction followed the rules while keeping its private details hidden.
Does every bank need ZK proofs?
Not really. If it’s a private ledger and the main concern is employee or vendor access, standard policy controls are sufficient. ZK is useful when it’s a shared infrastructure but should not see one another’s balances, amounts, or workflows.
Which layer should come first?
Start with the place where information is leaking. If too many employees and vendors can query the chain, begin at the application layer. If competing institutions can read one another’s payments, asset privacy is the urgent problem. Network controls are a basic requirement in both cases.
Where Zeeve Tegaris fits into this
Zeeve Tegaris, the Zeeve Privacy Layer, is built around these four separate privacy needs.
The suite is modular and can be integrated with any chain type.The modules cover access governance, identity-aware private RPC, role-scoped private explorers, and ZK-based confidential tokens. They also include selective disclosure for auditors and regulators, custom ZK circuits for business-specific workflows, and audit dashboards for oversight.
Tegaris works across EVM-based environments, including Hyperledger Besu, custom EVM chains, ZK rollups, public-permissioned networks, and hybrid architectures.
So an institution does not need to abandon the network it already has just to improve privacy. It can look at the missing walls and add them where they are needed.
And that is probably the easiest way to begin.
Who is standing at the gate? Who has keys to each room? Which payment details are exposed? Which meetings can other members watch?
Once those four questions are answered honestly, the privacy gaps are usually not difficult to find.
Talk to Zeeve blockchain experts to discuss your requirements.
