How Companies Keep Transaction Data Private on Shared Blockchains

Companies can protect transaction data on shared blockchain infrastructure by combining restricted network access, encrypted transactions, zero-knowledge proofs, and controlled audit access. Avalanche L1s and Encrypted ERC show how these protections can work together, although each addresses different privacy risks.

Public blockchains allow participants to verify transactions against a common ledger. For financial institutions, however, that transparency can expose commercially sensitive information, including payment amounts, account balances and trading activity.

A bank processing institutional payments, for example, may need several counterparties to verify settlement without giving every participant access to its customers’ financial information.

This creates a distinction between two forms of blockchain privacy: controlling who can access a network and controlling what information remains visible to those who can access it.

Avalanche addresses the first requirement through configurable Layer 1 (L1) networks. Its Encrypted ERC (eERC) token technology addresses the second by concealing balances and transfer amounts while supporting authorized audits.

Neither approach guarantees complete anonymity or regulatory compliance. Their effectiveness depends on implementation, network governance and the information institutions need to protect.

What Technologies Protect Transaction Data on Shared Infrastructure?

Companies generally use several privacy-enhancing technologies rather than relying on a single security mechanism.

These technologies protect information at different stages, including storage, processing, transmission and transaction verification.

Technology	Primary purpose	Typical application
Encryption at rest and in transit	Protect stored or transmitted information	Banking databases and cloud infrastructure
Confidential computing	Protect data during processing	Sensitive workloads on shared computing infrastructure
Zero-knowledge proofs (ZKPs)	Verify claims without disclosing the underlying information	Transaction verification and identity checks
Homomorphic encryption	Perform supported calculations on encrypted information	Confidential financial computation
Multi-party computation (MPC)	Allow organizations to compute results without sharing private inputs	Collaborative analytics and distributed key management
Permissioned blockchain networks	Restrict participation and ledger access	Institutional transaction networks
Confidential token systems	Conceal balances and transaction amounts	Private token transfers and settlement

The U.S. National Institute of Standards and Technology (NIST) identifies zero-knowledge proofs, homomorphic encryption and secure multi-party computation among the main approaches to privacy-enhancing cryptography.

These methods are complementary. A company may use encryption to secure its database, confidential computing to process sensitive information and blockchain-level privacy controls when sharing transaction records across organizations.

Why Is Transaction Privacy Difficult on Public Blockchains?

Public blockchains are designed to make transaction records independently verifiable.

On transparent networks, observers can typically inspect wallet addresses, transaction amounts and the movement of assets through blockchain explorers.

That visibility is useful for accountability and verification. It can also create problems for institutions that process confidential transactions.

For example, publishing the amounts of supplier payments or treasury transfers could expose business relationships and commercially sensitive financial activity.

Moving these records into a conventional private database may limit exposure, but it also changes how participating organizations share and verify information.

Some institutions want a common transaction record that multiple approved parties can validate without relying entirely on one organization’s database.

The technical challenge is therefore to maintain shared verification while limiting unnecessary disclosure.

What Is the Difference Between Network Privacy and Transaction Privacy?

Network privacy and transaction privacy address different sources of information exposure.

Network privacy controls who can access the ledger

A permissioned blockchain can restrict which organizations operate nodes, validate transactions and obtain copies of transaction records.

This prevents unauthorized outsiders from accessing ledger information through the network’s normal synchronization mechanisms.

However, participants admitted to the network may still be able to inspect transaction data.

A private network does not automatically mean every payment amount or account balance is encrypted.

Transaction privacy controls what participants can see

Confidential transaction technology protects selected information within transactions.

Depending on the implementation, participants may be able to verify that a transfer is valid without seeing its amount.

This matters when several approved institutions share a blockchain but should not have unrestricted access to one another’s financial information.

For stronger confidentiality, an institution may need both restricted network access and transaction-level encryption.

How Do Avalanche L1s Restrict Access to Transaction Data?

An Avalanche L1 is a customizable blockchain built using Avalanche infrastructure.

Organizations can configure aspects of network participation, validation and execution to meet specific operational requirements.

One relevant feature is the validator-only network configuration.

According to Avalanche’s technical documentation, enabling the validatorOnly setting prevents a configured node from distributing the chain’s contents to unauthorized non-validator peers through ordinary peer-to-peer messaging.

Approved non-validator nodes can also be admitted through the allowedNodes configuration.

Importantly, Avalanche specifies that this setting must be applied consistently by validators to establish a fully restricted network through this mechanism.

The configuration limits distribution of ledger data through the blockchain’s normal network layer. It does not independently prevent an authorized validator from disclosing records or operating a publicly accessible interface.

Permissioned transaction controls

Avalanche also supports controls that determine which blockchain addresses can perform certain activities.

Its Transaction AllowList can restrict transaction submission to approved addresses.

Separately, the Contract Deployer AllowList can limit which addresses deploy smart contracts.

These controls may help institutions enforce network participation policies and restrict unauthorized activity.

They should not, however, be confused with encryption. An allowlist determines who can perform an operation; it does not automatically conceal the resulting transaction details from authorized observers.

How Does Encrypted ERC Protect Transaction Amounts and Balances?

Encrypted ERC, or eERC, is a confidential token standard developed by AvaCloud.

It uses zero-knowledge proofs and partially homomorphic encryption to support token transfers while concealing balances and transaction amounts onchain.

According to the Avalanche Encrypted ERC documentation, the technology allows observers to verify transactions without exposing the financial values associated with those transfers.

For example, a conventional public token transfer may reveal that one wallet sent $5 million in tokens to another.

With an eERC implementation, the transfer amount can remain encrypted even though the transaction itself is observable.

The distinction is important: eERC protects transaction values, not complete transaction anonymity.

On a public deployment, sender and receiver addresses, along with transaction timestamps, remain visible. Public addresses do not necessarily identify individuals by name, but they can still reveal transaction relationships.

How the encryption works

The Ava Labs eERC repository describes an architecture that combines zero-knowledge proofs with encryption mechanisms allowing supported balance operations to be performed without exposing the underlying values.

The zero-knowledge component helps verify that transactions satisfy the required rules without publishing confidential amounts.

eERC supports two main operating models.

Standalone mode allows the creation of a confidential token with encrypted balances and transfers.

Converter mode enables an existing ERC-20 token to be deposited into an encrypted representation and subsequently withdrawn.

Conversions between encrypted and conventional tokens require particular attention because activity at the entry and exit points can expose information or support transaction-linkage analysis.

Although designed within the Avalanche ecosystem, eERC is not exclusive to Avalanche L1s. It can also operate on other compatible Ethereum Virtual Machine (EVM) networks that meet its technical requirements.

Can Blockchain Transactions Remain Private and Auditable?

Yes. Confidential transaction systems can be designed to give authorized auditors access to information that remains concealed from ordinary observers.

eERC includes an optional auditor mechanism that supports access to encrypted balances and transaction amounts.

Its architecture also supports changing or revoking auditor permissions, according to Avalanche’s eERC technical materials.

This produces different levels of information access.

Participant	Potential information access
Outside observer	Publicly visible transaction metadata, where the underlying network is public
Ordinary network participant	Information permitted by the network configuration and token privacy controls
Authorized auditor	Protected transaction values covered by the configured audit permissions

For financial institutions, this distinction can be useful.

A company may want to prevent competitors from observing its transactions while preserving a mechanism for internal reviews or regulatory examination.

However, an auditor key does not automatically make a blockchain compliant with financial regulations.

Institutions must separately assess identity verification, anti-money-laundering controls, record retention, reporting requirements and the security of disclosure credentials.

Private Avalanche L1 vs. Encrypted ERC: What Is the Difference?

The two technologies serve different purposes and can be combined in an institutional blockchain architecture.

Privacy requirement	Restricted Avalanche L1	Encrypted ERC
Restrict access to ledger data	Yes, when correctly configured	No
Restrict transaction submission	Yes, with appropriate allowlist controls	Not inherently
Conceal token balances	Not automatically	Yes
Conceal transfer amounts	Not automatically	Yes
Support authorized decryption of encrypted values	Requires an additional mechanism	Yes, with configured auditor access
Operate on a public EVM blockchain	A restricted network is a separate deployment model	Yes, on compatible networks

An institution seeking both forms of protection could deploy confidential tokens on a restricted Avalanche L1.

Such an architecture could limit access to the ledger while also encrypting selected financial values.

That combination is technically possible, but its security and operational effectiveness would still require deployment-specific testing.

Have Financial Institutions Used Avalanche’s Permissioned Infrastructure?

Financial institutions have explored Avalanche-based infrastructure for tokenized assets and other shared financial workflows.

The available examples demonstrate institutional interest in configurable blockchain networks. They should not be interpreted as proof that those institutions deployed eERC or achieved complete transaction confidentiality.

Citi Tested Tokenized Private Funds on Avalanche Spruce

In February 2024, Citigroup announced a completed proof of concept involving Wellington Management and WisdomTree.

The project used Avalanche’s Spruce institutional test network to examine private-fund tokenization.

According to Citi’s official announcement, ABN AMRO simulated the role of an investor in a tokenized private equity fund issued by Wellington Management.

The participants tested processes involving token transfers, encoded fund-distribution rules and collateralized lending scenarios.

Citi said the experiment examined potential operational efficiencies and compliance controls.

The distinction is that this was a proof of concept using simulated workflows, not a production settlement network or a documented eERC deployment.

Related coverage: Citi Bank Tests Private Equity Tokenization on Avalanche — The Crypto Times.

FIS and Intain Developed a Tokenized Loan Marketplace

Financial technology provider FIS and structured-finance platform Intain launched the Digital Liquidity Gateway initiative in November 2025.

The Avalanche-based marketplace is designed to help community and regional banks buy, sell and securitize loan portfolios through shared digital infrastructure.

The platform integrates with FIS banking systems and uses Intain’s technology to support loan records, verification and related financial workflows.

Intain’s website describes the partnership as connecting its marketplace to infrastructure serving more than 2,000 community and regional banking institutions.

That figure represents the partnership’s institutional reach; it does not establish that every institution has actively transacted on the blockchain marketplace.

The project illustrates how distributed ledger technology can be incorporated into loan-financing workflows, although public information does not establish that its participants use eERC confidential tokens.

Related coverage: Avalanche Powers FIS and Intain Blockchain Gateway — The Crypto Times.

Are There Alternatives to Avalanche for Private Transactions?

Avalanche is one approach to controlling transaction visibility. It is not the only blockchain architecture that supports institutional privacy requirements.

For example, Hyperledger Fabric supports private data collections, which allow designated organizations to store confidential information while other participants retain cryptographic hashes on the shared ledger.

Its official documentation describes how private data can remain available only to authorized organizations.

Other approaches rely on cryptographic computation rather than restricted blockchain membership.

In September 2026, COTI announced the deployment of its Privacy-on-Demand and Privacy Portal tools on Avalanche, offering a separate approach to confidential computation. These tools are distinct from eERC.

The appropriate architecture depends on whether a business needs restricted access, encrypted balances, confidential computation, interoperability with existing systems or a combination of these capabilities.

What Are the Limitations of Confidential Blockchain Transactions?

Blockchain privacy involves trade-offs between confidentiality, cost, governance and transparency.

1. Restricted networks still depend on authorized operators

A validator-only network can prevent ordinary outsiders from accessing blockchain data, but authorized validators may retain access to transaction records.

The institution must therefore establish appropriate governance, security and operational controls around those participants.

2. Encrypted amounts do not eliminate metadata exposure

Even when transaction values are hidden, visible addresses, timestamps and transaction patterns can reveal information.

Organizations should also evaluate what becomes observable when assets move into or out of confidential systems.

3. Cryptographic privacy increases processing requirements

Confidential transactions generally require additional computation.

Avalanche’s eERC integration documentation estimates roughly 947,000 gas for a confidential transfer, or approximately 15 times the cost of a standard ERC-20 transfer.

This is a documented implementation estimate, not a universal cost for every network or future version.

The practical impact depends on network fees, transaction volumes, proof-generation requirements and system architecture.

4. Permissioned networks introduce governance trade-offs

Restricting validation can provide institutions with greater operational control.

It also concentrates participation among approved operators rather than allowing open validation by anyone who satisfies a permissionless network’s requirements.

Businesses must evaluate how this affects trust, resilience and accountability.

5. Privacy systems require independent security assessment

Encryption and audit-access mechanisms create additional responsibilities involving key management, smart-contract security and access permissions.

For sensitive financial applications, an organization should review relevant security audits, test the deployed implementation and establish procedures for lost, compromised or revoked credentials.

How Should Companies Choose a Transaction-Privacy Solution?

The starting point is not the blockchain brand or token standard. It is the information that must remain confidential.

Organizations should establish whether they need to protect transaction amounts, customer identities, account balances, commercial relationships or the entire ledger.

They should then determine which parties need to validate transactions, which need access to the underlying data and which must retain audit permissions.

A restricted blockchain may be suitable when the participants are known institutions operating within a defined governance arrangement.

Confidential tokens may be useful when participants need to verify asset transfers without seeing every financial value.

Other businesses may be better served by conventional encrypted databases, confidential computing or private data-sharing arrangements.

Any decision should also account for operating costs, interoperability, regulatory requirements and the security of the underlying implementation.

The Bottom Line

Protecting transaction data on shared infrastructure requires separating network access from the visibility of financial information.

Avalanche L1s provide configurable controls over network participation and access to ledger data, while eERC supports encrypted token balances and transaction amounts with optional audit functionality.

Combining these technologies could help institutions operate shared financial infrastructure without exposing every transaction value to all participants.

However, neither restricted network access nor cryptographic encryption should be treated as a complete privacy or compliance solution.

The appropriate approach depends on the institution’s confidentiality requirements, governance model, regulatory obligations and ability to operate the technology securely.

Frequently Asked Questions