Programmable View Access: The Institutional Privacy Unlock

We have a plethora of privacy protocols that enable funds, addresses, and metadata to be encrypted onchain. Each protocol takes its own approach to various aspects of privacy, such as which details are kept as ciphertexts, which cryptographic technique is used, and who has permission to decrypt.

While privacy maxis aren’t likely to care so much about granting other parties viewing access to their transactions, for institutions and many others this is a key feature. And there are multiple ways of facilitating viewing access that are contingent upon cryptographic and design decisions; those who prioritize flexibility when it comes to decisions like who can view their transactions, how long for, and whether viewing access can be revoked need to be familiar with each approach and its tradeoffs.

The Spectrum of View Access

Crypto has produced a handful of distinct approaches to view access. Each makes different tradeoffs, and those tradeoffs determine whether a system can support payments, DeFi, tokenized real-world assets, or general confidential compute. Let’s go through them.

Public by Default

This is the status quo on Ethereum, Bitcoin, Solana, and every other transparent chain. View access is total and uniform. Everyone sees everything. The "viewing key" is just the block explorer.

The strength is obvious: auditing is trivial. The weakness is equally obvious: every kind of onchain activity that depends on discretion—payroll, trading strategies, RWA valuations, institutional settlement flows—leaks to competitors, counterparties, and the public.

User-Derived Viewing Keys (Commitment-Based Protocols)

Commitment-based protocols, whether they be dedicated private chains or app-layer protocols, take a zero-knowledge approach to privacy. When a user sends a shielded transaction, the output is encrypted to the recipient and a zero-knowledge proof certifies that the transfer is valid without revealing the underlying data. In some designs, viewing access flows through keys tied to a user's account: sharing a viewing key with a third party lets them scan the chain and decrypt the activity that key has visibility over. In Zcash, for instance, a full viewing key derived from the user's spending key lets the holder see all incoming and outgoing notes for that account.

The cryptography is mature and well-understood, and viewing rights sit under the user's direct control—there's no contract-level switch an operator can flip to expose someone's data without consent.

But sharing a viewing key typically hands the recipient visibility into everything that key can see—historical and future, incoming and outgoing. Some protocols offer narrower disclosure primitives, but scoping to specific counterparties or arbitrary conditions usually requires additional machinery, and once a viewing key is shared it can't be revoked. Whoever holds it keeps that visibility forever.

Then there’s the composability constraint. Because ciphertexts are encrypted to specific recipients, computing across multiple users' encrypted state—vital for composable onchain apps and DeFi protocols—requires heavy additional machinery.

In our recent compliance framework, co-authored with Predicate, we placed every major ZK-based privacy system into the "pre-defined" viewing category.

Asset-Level Auditor Keys

Some approaches involve baking in privacy directly at the asset level. Solana's Confidential Transfer extension and Avalanche's eERC are two prominent examples of this design. A designated auditor is attached to each confidential asset; the auditor can decrypt confidential transaction amounts for that asset, and in some cases, an onchain AuditorManager can even rotate who that auditor is.

This is simple and compliance-compatible, and it fits how tokenized assets actually get issued. A stablecoin issuer or an onchain bond issuer can reasonably be expected to retain audit rights over their own asset.

But it's asset-level, not general-purpose. These designs work for "confidential token X." They don't extend cleanly to arbitrary smart contract state. If the application is more complex than a token, auditor keys quickly run out of expressive power.

Programmable View Access

The fourth approach stops treating viewing rights as a baked-in cryptographic object and starts treating them as smart contract state. This grants a greater degree of flexibility.

This is the approach Inco takes. In practice, it means:

• A developer can grant or revoke a specific address's right to view specific encrypted data with one Solidity call.
• Viewing rights can be conditional: an auditor can see balances only after a governance vote passes, a counterparty can see a trade only for the next 30 seconds, a regulator gains access only after a flag is tripped.
• Rights can be delegated, rotated, and revoked without touching the underlying encrypted data.
• Because ciphertexts aren't bound to any single user's viewing key, smart contracts can compute across encrypted state freely.

With this approach, institutions who want to take operations onchain can issue view access to regulators on a limited basis, minimizing privacy leakage while integrating blockchains into their everyday processes. 

Why Programmable View Access Matters

Institutions and Compliance

The importance of programmable viewing access is best demonstrated by exploring specific use cases. 

Take a bank tokenizing a bond in 2026. Over the life of that bond, who might legitimately need to see confidential transaction data?

• The issuer.
• The current holder.
• A transfer agent when the bond changes hands.
• The bank's internal compliance team during routine review.
• An external auditor during annual reporting.
• A regulator responding to a market event that hasn't happened yet.
• A court-appointed party responding to a subpoena that hasn't been issued yet.
• A forensic investigator responding to an incidt that may never occur.

This list cannot be known at issuance. The parties will change, and many of their addresses won't even exist yet. With a commitment-based scheme, all you can do is hand over the account's viewing key after the fact—you can't scope disclosure to specific parties or windows of time, and you can't revoke access once given. For an asset that lives for years and crosses many hands, that doesn't work well.

Traditional finance handles this problem with the simple expedient of keeping data in a database and granting access through ordinary access control—role-based permissions, directory services, delegation, governance workflows. Programmable view access is how onchain systems reach parity with that model, meaning the data can stay encrypted while the access policy lives in code. 

A Practical Solution for Institutional Privacy

Institutions bringing assets onchain need privacy, but they also need this privacy to be compatible with their existing processes. One key aspect of this is making sure private onchain activity is compatible with an institution’s existing policies, conditions, and delegations, which are guaranteed to evolve over time.

Pre-defined viewing keys were a reasonable first answer for a generation of privacy protocols focused on payments. For the next generation—confidential DeFi, tokenized RWAs, institutional settlement, programmable compliance—view access needs to be programmable.

For more information about Inco Lightning and how it enables programmable view access, check out the product page.