“Privacy is the one feature that’s critical for the world’s finance to move onchain.”
That statement from Ali Yahya, general partner at a16z crypto, is usually read as an argument for privacy chains, zero-knowledge systems, or encrypted assets.
All of these technologies matter. A lot.
But the question is, do they solve every privacy problem that a bank or financial institution faces when it moves a workflow onchain?
Well, not really.
Before cryptography even enters the picture, an institution must answer a different set of questions, like who is allowed to talk to a shared ledger, what each person or system may read, which contract actions they may initiate, and what evidence must be retained for audit.
This is the domain of application-layer privacy.
Application layer privacy places an identity-aware policy boundary between users and workloads on one side and blockchain infrastructure on the other.
It does not replace cryptographic privacy at the asset or ledger layer, by the way. It sits in a different chair across the table and solves a different problem.
But before we go deeper into application-layer privacy, let’s clear up one common misunderstanding.
Permissioned Does Not Mean Private
A permissioned blockchain controls who may join a network. It can decide which organization may operate a node, which node may connect as a peer, and which participant may help validate transactions.
That sounds private because the network is not open to everyone.
But imagine a building with a guarded entrance. The guard checks every person before allowing them inside. That makes the building restricted. It does not mean every person inside should receive a master key to every office, cabinet, and records room.
The same difference exists on a permissioned blockchain.
Once an organization has been admitted, its node may receive a replicated ledger containing transactions that do not concern it. A node operator may be able to inspect local state. A user with a broad RPC credential may query balances, blocks, receipts, logs, contract storage, or transaction history. An indexer may collect far more information than the application using it needs. A block explorer may also present the same view to every stakeholder, just like a public chain.
Besu, for example, supports private permissioned networks and permissioning controls. These controls decide who may participate in the network. They do not, by themselves, decide that one employee may see a payment while another may see only network health.
This is where two ideas that are often treated as one must be made to sit on two different chairs across the table.
Network permissioning controls who may enter the blockchain network.
Application-layer privacy controls what an admitted identity may see and do through the applications around that network.
There are asset layer and ledger layer privacy as well, but we will not discuss them here in this article.
Read More: The Four Layers of Blockchain Privacy For Banks and Financial Institutions
If Not Zero-Knowledge, What Actually Is Application-Layer Privacy?
Application-layer privacy is the selective control of blockchain data and actions at the interfaces used by people and software.
In simple words, it puts an identity-aware policy boundary in front of the blockchain.
Every request is connected to a known identity. The system examines what that identity wants to read or do. It then checks the request against the rules of the institution before the request reaches a node or the response returns to the user.
The identity may belong to an employee, a bank, a vendor, or any stakeholder. The request may ask for a balance, a block, a contract event, a transaction trace, or permission to call a settlement function.
The policy may allow the request, deny it, filter the response, require stronger authentication, or hold the action until another person approves it.
That is application-layer privacy.
Why Does the RPC Interception Matter So Much?
Applications on EVM networks communicate with blockchain nodes through JSON-RPC.
This interface allows an application to read the current state of the chain and submit transactions. It can return account balances, contract code, storage values, call results, blocks, transactions, receipts, logs, and traces. Through subscriptions, it can also send new events to an application as soon as they occur.
All of this is necessary for a blockchain application to work.
But a raw RPC node understands methods and parameters. It does not understand the organizational meaning behind them.
It does not know that a payments analyst works for one legal entity and should not see the activity of another. It does not know that a vendor may inspect node health but should never receive settlement events. It does not know that a treasury application may call one function below a certain value but may not deploy a new contract. It does not know that an auditor has been appointed for one investigation rather than given permanent access to the whole network.
To the node, these are all valid technical requests. To the institution, they are very different business actions.
Application-layer privacy brings that business context to the RPC boundary.
An identity-aware gateway sits between users and workloads on one side and blockchain nodes on the other. It authenticates the caller, understands the organization and role behind the identity, inspects the request, and applies the relevant policy.
However, securing the RPC endpoint alone is not enough.
If the explorer ignores the policy, the user can view the same information there. If an indexer has unrestricted access, it can make a copy of the data and expose it through another API. If event subscriptions are unfiltered, sensitive information can reach an application even when direct reads are restricted.
The policy must therefore follow the information across every application surface. That includes RPC, events, indexers, explorers, wallets, administrative consoles, and approval workflows.
How Does Application-layer Privacy Work?
But What Are The Application Layer Privacy Controls Institutions Need?
An institutional blockchain has more than one door. Protecting only the front door is not enough.
Let us begin with identity and workload access
Every human and machine should have its own identity. Human users may authenticate through enterprise single sign-on and use stronger authentication for privileged actions. Applications, wallets, indexers, and vendor systems should use separate machine identities with narrow and expiring credentials.
Shared service credentials may appear convenient, but they don’t bring in accountability. If ten systems use the same credential, an audit can show which credential made a request but not which system was actually responsible.
Now let us move to multi-tenant organization handling
A shared financial network contains many institutions, and each institution may have multiple business units. Correct? But the network operator should not become the universal administrator for every bank in the consortium. Each participating organization needs delegated control over its own people, systems, and policies within network-wide guardrails.
This will control the administrative reach. A member bank needs the authority to manage its own employees and systems without seeing the people or policies of another bank. On the other hand, the network operator also needs to maintain common rules without becoming the silent owner of every member’s business information.
Then come smart contracts
Institutions need to govern approved contract addresses, verified interfaces, permitted functions, counterparties, settlement limits, assets, jurisdictions, deployment rights, and sometimes even the integrity of deployed bytecode. A request that falls outside a person’s usual authority may be rejected or sent for approval.
Then come RPC data classes
Blocks, transactions, receipts, logs, traces, contract state, and pending data should not be treated as one harmless category called read access. A trace may reveal internal calls that do not appear in a receipt. Pending data may expose an action before it is finalized. Contract storage may reveal a business state that the application interface never shows.
An institution may therefore allow network health and block-height queries, restrict state reads to approved contracts, deny trace methods to ordinary users, filter logs by participant, and allow transaction submission only through wallet-bound routes.
Then come events
And events are where the need for application-layer privacy becomes very easy to see.
Suppose several banks share a smart contract for cross-border settlement. Every bank subscribes to a Payment Initiated event so it can respond when it becomes the beneficiary.
Without filtering, every subscriber may receive every payment event. Bank C may see a payment from Bank A to Bank B even though it has nothing to do with the instruction. Over time, these events can reveal counterparties, business relationships, transaction patterns, and periods of increased activity.
At the application layer, the event service examines both the event and the identity of the subscriber. Bank B receives events addressed to Bank B. Bank C does not receive Bank A’s instruction to Bank B. Even inside Bank B, different teams receive only the fields and events their work requires.
Then come indexers
An indexer can quietly become a shadow copy of the ledger. It collects events, enriches addresses, reconstructs relationships, and makes the information easier to search. Restricting the explorer while allowing the indexer to ingest the whole chain does not solve the problem. It merely moves the exposure.
An institution must decide which indexing pipelines are approved, which contracts and fields may be ingested, which credential an indexer uses, how long the data is retained, and which downstream applications may query it. Changes to an indexing manifest should be reviewed before new information begins to flow.
Then come explorers.
A traditional block explorer presents one common view of the ledger. An institutional explorer should not.
Treasury staff, a member-bank administrator, a network operator, an external auditor, and a regulator do not automatically need the same view. The explorer may show network health to an operator, one bank’s transactions to its operations team, exception evidence to compliance, and mandate-scoped records to an auditor.
The explorer must apply the same policy as the RPC layer. Otherwise, it becomes a convenient way around the control plane.
Finally, there are approvals and lifecycle changes
Some actions should not execute on the authority of one identity. Contract deployment, high-value transfers, entitlement changes, emergency access, and the viewing of highly sensitive records may require maker-checker approval.
And policies themselves change. Banks onboard participants, reorganize teams, rotate vendors, upgrade contracts, revoke credentials, and respond to emergencies. A small policy error can expose information or stop a critical settlement workflow.
Administrators should therefore be able to simulate a policy change before releasing it. Every version of the policy should remain identifiable so an auditor can determine which rules were active when a decision occurred.
A Cross-border settlement example
Well, let us return to the cross-border settlement network.
Bank A wants to send a payment instruction to Bank B. Bank B must detect the instruction, run its checks, and submit an acceptance. Banks C and D use the same contract for their own settlements.
Without application-layer controls, the network may work exactly as designed while still leaking information.
All four banks subscribe to the same event. Their nodes return all matching events. Their indexers store what they receive. Their explorers and analytics tools make the collected information searchable. Employees and vendors with broad credentials can begin to infer relationships across the consortium.
Nobody needs to defeat encryption or compromise a validator. The application architecture simply distributes too much information.
With application-layer privacy, every human and workload authenticates separately. The control service evaluates the initiating bank, receiving bank, contract, function, arguments, wallet, and approval state. Bank A may send only an instruction within its permitted scope. The event goes only to Bank B and authorized oversight roles. Bank B may accept only an instruction addressed to it. Indexers ingest only approved records. The explorer presents a role-specific view. The policy decisions and approvals are retained for audit.
This protects one bank from another. It also protects one department from another inside the same bank. A retail operations employee should not inherit investment-banking visibility merely because both teams belong to the same institution.
That is why application-layer privacy is not just an access-control feature added to a dashboard. It is the operational privacy fabric around the chain.
The Boundary It Cannot Cross
Application-layer privacy has an important limit.
It works when requests and responses pass through the governed interfaces. It does not turn plaintext on the ledger into ciphertext.
If information has already been replicated to a node, a person with direct access to that node or its database may be able to read it. Application controls do not conceal transaction data from validators that already received it. They do not hide transaction timing, propagation, mempool activity, or other network metadata. They do not make public token balances confidential. They do not restrict public smart contract state after it has been written onchain.
Event filtering makes the delivery of information private. It does not make the underlying ledger state private.
This is not a weakness in the idea. It is simply the boundary of the layer.
If other node operators must not learn the amount of a transaction, asset-layer privacy is required. If parties outside a workflow must not see its contract state or execution, ledger-layer privacy is required. If outsiders must not operate infrastructure or participate in consensus, network permissioning is required.
Application privacy, network privacy, asset privacy, and ledger privacy answer four different questions.
Who may use the applications around the chain?
Who may participate in the network?
Who may learn what value moved and between whom?
Who may see the state and execution of a workflow?
The cleanest privacy architecture begins by asking which observer must be prevented from learning which fact.
A network may begin with application-layer controls because its immediate risk is employee, vendor, or RPC exposure. A settlement platform may begin with asset privacy because amounts and counterparties must remain hidden from other members. A mature financial market infrastructure may need all four layers, together with selective disclosure for supervisors.
The layers can work together. They cannot replace one another.
Even a zero-knowledge transfer needs application governance. The proof may establish that a transaction is valid without revealing its amount. The bank must still decide which employee may initiate it, which wallet may sign it, which contract may be called, which auditor may receive evidence, and which operator may view the outcome.
Application Privacy In a Four-Layer Architecture
| Privacy layer | Governing question | Typical controls | Primary observer addressed |
| Application | Who may query, transact, subscribe, index, or view | Identity-aware RPC, policy engine, private explorer, indexer governance, approvals, audit | Staff, vendors, workloads, and application users |
| Network | Who may operate infrastructure or participate in consensus | Peer and validator permissioning, node onboarding, mTLS, infrastructure policy | Outsiders and unauthorized infrastructure operators |
| Asset | What value moved and between whom | Commitments, zero-knowledge proofs, encrypted balances, confidential tokens, selective disclosure | Other participants and chain analytics |
| Ledger | Who may see contract state and execution | Private sub-ledgers, privacy groups, private domains, ZK execution | Parties outside the workflow |
Tegaris and the Modular Privacy Model
Tegaris is an open-source, full-stack blockchain privacy framework that provides programmable privacy for EVM-compatible networks.
Zeeve built Tegaris to address the rigorous data-privacy requirements of highly regulated financial institutions and contributed it to the LF Decentralized Trust, a project under the Linux Foundation.
The tool is modular in nature and can work with any chain type.
At the application layer, its policy and control plane, private RPC controls, and private explorer are designed to govern identities, wallets, workloads, contract calls, event streams, indexers, approvals, and operational views.
An institution can begin there when its immediate problem is internal access, vendor access, or broad RPC visibility.
When the requirement expands, it can integrate asset layer and ledger layer privacy.
Learn more about Tegaris or book a call for a free privacy layer demo.
