20 MIN26 JAN 2026

The Anatomy of Exposure: How Blockchain Transactions Leak Information at Every Layer

A full-stack look at where blockchain privacy breaks down

D

Dr. Corey Petty

Tech

privacy

Blockchain

Share

Public blockchains leak sensitive metadata at nearly every stage of a transaction: from messaging and wallets to RPCs, mempools, and block builders. This article shows why blockchain privacy is a full-stack problem, and why cryptography alone can’t protect users in an increasingly centralised surveillance ecosystem.

A special thanks to those who provided valuable feedback to this article: Ksr, Maya Krumova, Hudson Jameson, Franck Royer, Carl Bennetts, and Václav Pavlín.

Privacy is a key topic of debate in the world of blockchain, but most discussions focus on cryptographic techniques and protocol design, often centring on powerful yet narrowly scoped tools such as zero-knowledge proofs and transaction mixers.

However, the goal of preserving privacy when interacting with blockchain protocols goes far beyond cryptography and meets with broader concerns over user traceability, infrastructure centralisation, and user security practices.

Any system that purports to preserve user privacy is only as strong as its weakest link. There is currently no blockchain protocol designed to foil issues like simple IP correlation, Remote Procedure Call (RPC) provider logging, or compromised frontends.

Maintaining privacy when transacting on a public blockchain is therefore a comprehensive problem that requires a multifaceted approach, not the silver bullet of a single cryptographic mechanism.

The failure to preserve privacy on blockchain networks is generally the result of one of two issues: either the user has not taken adequate steps to preserve their privacy, or the infrastructure they are using is leaky.

Examples of ways users commonly compromise their own privacy when transacting on a blockchain include:

The issues listed above can be mitigated if one takes the appropriate steps to improve one's privacy and reduce one's own risk of accidentally leaking information.

Infrastructure issues, on the other hand, relate directly to the blockchain protocol and network, and often leak information or compromise privacy in ways a user cannot control. For example:

Some of the above can be mitigated by adopting alternative tools, but many privacy concerns around blockchain transactions stem from the protocol's public nature.

To illustrate the scope of the privacy concerns inherent in transacting on a blockchain, we examine the anatomy of a transaction on the Ethereum blockchain and explore what information might be exposed at each stage of its lifecycle. It is important to note here that many of the listed exposures extend to most other blockchain networks. Ethereum is simply used as a general example, not a specific case.

Stage 1: Coordinating transaction details

The first vector for leaking private information occurs before a transaction is even constructed, during coordination with a payee or platform. 

If you are transacting through a service, app, or user through a centralised platform, you may be required to expose personal information for KYC or advertising purposes, and your data may be collected and logged.

Even if you are coordinating with a single recipient through direct messaging, the application you use to communicate may expose information tying your identity to your transaction.

Exposure through communication channels

Below are some examples of how metadata and other information can be exposed through centralised communication channels:

While some of the exposure vectors above can be mitigated by the user (e.g., using Secret Chats on Telegram for end-to-end encryption or connecting to a secure VPN/Tor), a more secure way to digitally coordinate a transaction would be through privacy-preserving peer-to-peer messaging with end-to-end encryption.

This is the idea behind the messaging component of the Logos technology stack: to offer a scalable, reliable, and privacy-preserving p2p communications protocol that is resistant to censorship and monitoring.

The browser as a hostile environment

Browser-based wallet extensions and custodial online platforms operate in an environment that was never designed to protect high-value cryptographic secrets. They share execution space with arbitrary websites, third-party scripts, trackers, and ads. 

Updates are pushed automatically through extension stores, and users have little visibility into what code is running at any given moment.

In 2025, personal wallet hacks totalled approximately $713 million, with browser extensions consistently identified as a leading attack vector. Research found 186 malicious crypto-themed extensions among 3,599 analysed, meaning around one in twenty carried hostile code. 

Multiple cryptocurrency platforms have also suffered Domain Name System (DNS) hijacking attacks, where attackers modify DNS records to redirect users to pixel-perfect clones of legitimate sites.

DNS attacks are particularly devastating because users navigate to the correct URL, and their browser shows the expected domain. There is no visual indication of compromise.

When using a browser to manage their wallet and transactions on the blockchain, users have no practical way to verify that the JavaScript executing in their browser matches what developers intended to deploy. 

Content-addressable systems like IPFS could provide verification, but adoption remains minimal.

When coordinating a transaction, the quality of a user’s privacy is in their hands. Even if a perfectly private protocol for transaction coordination existed, failure by the user to take adequate precautions may still result in their information being leaked.

Stage 2: Constructing a transaction

Once the transaction details are coordinated, the transaction itself must be constructed, typically within wallet software developed by third parties.

Reliance on RPC providers

When constructing a transaction, wallet software must source various information from the blockchain via an Ethereum node. Instead of requiring a user to run a client themselves, wallets like MetaMask make several RPC calls to centralised services such as Infura, which return the information requested.

Most popular wallets used to construct Ethereum transactions today rely on centralised RPC providers by default. This makes it straightforward to construct transactions, but it also means your personal information is sent to and collected by the companies that provide this service.

Infura explicitly collects IP addresses and Ethereum wallet addresses when users send transactions, and retains the data for at least seven days. The analytics dashboard of Alchemy, another RPC provider, maps user IP addresses geographically. This means centralised RPC providers have sufficient information to:

ENS lookups and wallet fingerprints

Privacy vulnerabilities associated with centralised RPC providers are not limited to the standard suite of RPC calls required to construct a transaction. If a user enters the Ethereum Name Service (ENS) domain name of the recipient (e.g. alice.eth) before sending funds, this also reveals the intended recipient to the RPC provider.

Beyond centralised RPC calls, using specific wallets to construct transactions can also reveal information that, when combined with other data, may compromise a transaction's privacy. Wallets have their own gas estimates, nonce gaps, and ways of deriving addresses that can inform an observer which wallet was used to construct a specific transaction.

Potential vectors for information leakage in transaction construction can be avoided if a user runs their own node and constructs their own transaction manually, without using an RPC endpoint.

This requires significant expertise; however, for many users, a more realistic approach may be to use a secure VPN or the Tor network in combination with a tool such as the Nimbus Verified Proxy, a lightweight client that can act as a middleman between users and endpoints like Infura, verifying the data provided by the endpoint and preserving user privacy.

While this does not address the possibility of extrapolating information from how a transaction is constructed, it removes several centralisation-related risks associated with RPC endpoint providers.

Stage 3: Signing a transaction

Signing a transaction on Ethereum is a secure cryptographic process. The Elliptic Curve Digital Signature Algorithm (ECDSA) used by Ethereum ensures that private keys remain isolated and secure.

However, a transaction is generally signed using wallet software or a hardware wallet, which can introduce risks of private or identifying information being leaked.

Hardware wallets

From a security perspective, hardware wallets with their secure physical chips are generally deemed more resistant to attacks and less likely to expose information than software wallets, which can be vulnerable to compromised browser or mobile environments.

Managing your keys and signing transactions from a software wallet or within a mobile environment can potentially expose them to malicious software running on your device or scripts running within your browser.

A hardware wallet’s secure element performs cryptographic operations in an isolated environment, protecting its keys from being compromised by these methods.

However, even the cryptographic operations performed by older versions of these secure elements may be vulnerable to voltage-glitching attacks if an attacker has physical access to the hardware wallet in question.

Onchain wallets

When it comes to onchain wallets, the public nature of the Ethereum blockchain means that multi-signature (multisig) wallets created through tools such as Safe reveal all signer addresses publicly. 

Additionally, offchain signature collection through the Safe Transaction Service can also expose all pending transactions, the order in which they were signed, and approval patterns to the provider running the service.

Multi-Party Computation (MPC) wallets aim to offer better privacy for onchain wallets by making signatures appear identical to single-key transactions, but the coordinator service maintains a view of all transaction requests and which keyholders participated in signing.

Stage 4: Submitting a transaction

Submitting a transaction to the blockchain’s mempool presents the most risk for information being leaked. This is the moment where a user who submits a transaction exposes their IP address to the network, tying it to their Ethereum wallet address.

RPC provider logging

This marks another point in the lifecycle of an Ethereum transaction where the widespread reliance on centralised RPC endpoints creates privacy risks for everyday users.

Infura’s privacy policy explicitly states that it collects IP addresses and Ethereum wallet addresses when a user sends a transaction. This linkage of IP addresses to wallet addresses represents a single data point that can be used to link a user’s crypto wallet to their physical location.

The scope of this problem is made more severe thanks to the concentration of the RPC provider market, with most transactions submitted to the network via services such as Infura, Alchemy, QuickNode, Chainstack, and Ankr.

Each of these providers maintains logs of the transactions submitted through them to the Ethereum network, which could include geographic location data, query patterns, and more.

To avoid exposing this link between IP and wallet addresses, those submitting a transaction through an RPC provider can use a VPN or other method to obscure their real IP address, although this also places trust in a centralised VPN provider.

Timing correlation attacks

Even if their traffic is encrypted, a user who submits a transaction from their actual IP address can still fall victim to timing-correlation attacks. 

This type of attack sees passive adversaries at network border routers correlating TCP packet timestamps with blockchain transaction confirmation times. 

This allows IP addresses to be linked to blockchain wallet addresses using only the metadata of encrypted web traffic.

ISP traffic monitoring

Running your own client instead of relying on an RPC provider can remove the risk of RPC provider logging, but it does not remove the potential for information to be exposed to other centralised services that can easily monitor online traffic, such as Internet Service Providers (ISPs).

According to research by DARPA, 60% of global Bitcoin traffic crosses just three Internet ISPs, presenting a massive opportunity for surveillance of transaction behaviour.

When a user connects to an RPC provider without shielding their IP address, ISPs can observe when they connect to RPC endpoints, correlate traffic volume with transaction sizes, and monitor connection timing to determine the timestamps of trading sessions.

Running your own client and connecting to a VPN or Tor can help to mitigate the risks of information being exposed through these avenues as you submit transactions to the public mempool.

Stage 5: Propagating a transaction

Once a transaction is submitted by a node, it is propagated to the public mempool through the peer-to-peer network.

This leakage happens whether this occurs from an RPC provider’s node or a node the user is running themselves. 

Gossip protocol vulnerabilities

Ethereum’s execution layer propagates transactions over DevP2P using TCP, broadcasting NewPooledTransactionHashes messages between peers. Bitcoin uses a diffusion-based approach with randomised delays. 

Despite these differences, both systems are vulnerable to so-called “first-spy” attacks.

In a first-spy attack, a well-connected observer watches which peers relay a transaction first. With enough vantage points, the observer can infer the transaction’s point of origin with surprisingly high accuracy.

This type of attack is not theoretical. Research has shown that Bitcoin users could be deanonymised for around €1,500 by deploying a set of highly connected nodes and monitoring transaction relay patterns. 

More recently, Princeton’s PERIMETER attack demonstrated that an autonomous system-level adversary could deanonymise over 35% of Bitcoin clients purely through passive BGP observation. 

No new peer connections were required to facilitate this attack, making the cost of this relatively low compared with the deployment of densely connected border nodes.

Industrial-scale mempool observation

Mempool archives are a valuable trove of data for companies that have the capacity to extrapolate patterns and infer information from these vast stores of information.

Firms such as Blocknative maintain vast archives of this information. Blocknative alone stores more than 15TB of data covering over five billion transactions, with dozens of metadata fields per transaction, including regional timestamps. 

This data underpins real-time mempool streaming services used by MEV searchers.

From analysing pending transactions based on patterns in this archival data, searchers can infer information such as:

MEV searchers run specialised infrastructure and custom clients with low-latency connections to block builders, creating a close-to-real-time view of the transaction processing pipeline.

The information they extract from unconfirmed transactions is then used to inform their own trades and transactions before the information becomes more widely propagated on the network.

MEV searchers are motivated to extract value from transaction data, but the data they are incentivised to collect or purchase can also be used to analyse all address activity and extrapolate identifying information, leading to a potential privacy risk.

Private mempool services can help to reduce this exposure, but they do not remove it, mainly changing who you trust.

Examples of these services include:

All of these services protect users from public mempool monitoring, but they concentrate visibility in the hands of a small number of operators.

Mitigating network-layer privacy vulnerabilities

There is currently no simple protocol for propagating transactions in a way guaranteed to prevent targeted surveillance, although solutions such as Dandelion++ do provide formal anonymity guarantees that can protect against mass surveillance.

However, Dandelion++ is not implemented in either Bitcoin Core or Ethereum, meaning both protocols currently remain vulnerable to first-spy attacks and other deanonymisation techniques that target transaction propagation.

Tor can hide a user’s IP address, but Bitcoin-specific attacks against Tor users have been demonstrated, and Tor usage itself is often detectable. I2P offers stronger resistance in some cases, but suffers from a smaller anonymity set and limited ecosystem support.

Future Logos Press Engine technical articles will examine how next-generation network privacy layers, such as Logos’s Blend network and mixnet, address these fundamental limitations.

Stage 6: Including a transaction in a block

Once a transaction has been propagated through the network, it must be included in a block that will then be proposed to be added to the blockchain.

The construction of blocks today is a heavily centralised process, and as with the other instances of centralisation we have explored so far, this represents a concentrated potential for the surveillance of transactions and exposure of information to a few select parties.

The block builder duopoly

Following the implementation of Ethereum’s post-merge Proposer-Builder Separation (PBS) architecture, the centralisation of block builders has become a significant issue for those concerned with the decentralisation of the network.

The numbers are stark. According to data from Rated.network, Titan Builder is responsible for building more than 50% of blocks on Ethereum. BuilderNet follows with a market share that fluctuates between 27% and 35%. 

That means the top two block builders on Ethereum have essentially formed a duopoly responsible for building up to 85% of blocks on the network at any given time.

Block builders have access to the full content of transactions, are able to exploit MEV opportunities, and can easily monitor the transaction patterns of specific wallet addresses.

Large-scale MEV through centralised information

The few builders who dominate the block building process monetise their privileged view of transactions on Ethereum. Since 2020, more than $7.2 billion in MEV has been extracted. 

Individual sandwich attacks, where MEV searchers sandwich a target transaction between two of their own in the transaction order, have generated hundreds of thousands of dollars for builders, while validators receive comparatively modest rewards.

In a recent 30-day period alone, over 72,000 sandwich attacks targeted more than 28,000 victims.

Private order flows

The dominance of the few block builders that control production on Ethereum is further exacerbated by the growing prevalence of private order flows.

This refers to a process where nodes send transactions directly to block builders instead of propagating them through the network, allowing them to be included ahead of transactions targeted for MEV attacks.

Around 54% of block value now comes from private transactions, and while these account for only about 12% of transaction volume, they generate over half of all block rewards.

The effectiveness of these MEV mechanisms makes it lucrative and desirable to hoard and inspect transaction data, monitoring for patterns and surveilling user activity on the network to capitalise on their transactions.

This is bad news for a user transacting on Ethereum who wishes to remain as private as possible, as the industrial-scale collection and scraping of transaction-related data is currently incentivised.

Block builder centralisation and private order flows also undercut the principles of decentralisation on Ethereum by encouraging users to send transactions directly to specific block builders without sharing them with the rest of the network beforehand.

Stage 7: Post-inclusion surveillance

Once a transaction is included in a block, it becomes available to a mature surveillance industry that extracts and monetises onchain data at scale.

Block explorers and IP correlation

Even simple actions can leak information. When a user looks up their own address or a transaction hash on a block explorer – for example, to confirm if a transaction has been processed – they create a link between their IP and that address or transaction.

As early as 2018, Ethereum developer Peter Szilagyi documented that Etherscan’s analytics integrations shared user IP addresses with major third-party platforms like Facebook and others whenever an address was viewed.

Chain analytics at a global scale

When a transaction is committed to the network, it is made immutably public and constantly remains a potential target for the many chain analytics firms that specialise in extrapolating information from historical transaction data:

These firms rely on graph analysis techniques such as common-input ownership, change address detection, and protocol-specific heuristics.

On Ethereum, address reuse patterns alone can cluster a significant share of externally owned accounts into singular identifiable entities.

Cross-chain and behavioural tracking

Using a bridge to move tokens to another blockchain does not provide meaningful obfuscation.

Modern analytics systems treat multiple blockchains as a single graph, tracing assets through bridges, DEXs, and swaps, and specialised tools have demonstrated tracing accuracy above 90% across popular DeFi bridges.

Even without labels, users can be identified through their behaviour as they submit more transactions – i.e., more data points – to the public record. 

Transaction timing suggests geography. Gas price choices form distinctive patterns. Sequences of DeFi interactions create unique fingerprints.

KYC as an anchor to identity

Centralised exchanges anchor this system of global blockchain surveillance. 

Once an address is linked to a verified identity through a centralised exchange, that association propagates through connected wallets.

Regulations such as the FATF Travel Rule, now enforced under EU MiCA, formalise data sharing between compliant service providers, making it easier to tie real-world identities to wallet addresses across blockchains and off-ramps.

Stage 8: The downstream data economy

Information exposed throughout the transaction lifecycle does not vanish, especially not the data valuable to the centralised entities widely relied on at various stages of the process.

Every time potentially private information is leaked, it risks being accumulated, aggregated, and sold.

This can be true for everything from analytics trackers on block explorers or centralised exchanges to the record of transactions on the public blockchain itself, which can be collected by chain analytics firms and used to infer valuable information that is then provided to exchanges, trading firms, insurers, venture capital funds, and tax authorities.

All major infrastructure providers are also subject to legal compulsion, often requiring them to collect and archive data. 

IP logs, transaction histories, and access records can be demanded through court orders or regulatory frameworks such as MiCA and the Travel Rule.

These incentives and requirements create a landscape in which blockchain data is scrutinised by myriad third parties, both malicious and compliant, many of whom aim to tie individual transactions back to deanonymised real identities.

A stack gap in blockchain privacy

Analysing a blockchain transaction’s lifecycle makes it clear that while exceptional advances are being made on application-layer privacy solutions such as zero-knowledge proofs and mixnets, there is a gap in the privacy stack.

Zero-knowledge proofs, for example, hide transaction content from surveillance, but they do not obscure the IP address of the submitter, the time of submission, the RPC endpoint, smart contract metadata, or wallet infrastructure.

A user employing Railgun’s zk-SNARKs for transaction privacy while using Infura as their RPC provider has their IP address linked to their wallet. A mixer user who checks their output address on Etherscan has their IP correlated with their address through Google Analytics. A stealth address recipient who accesses funds via a compromised frontend has their transaction intercepted in its entirety.

The industry has invested heavily in cryptographic privacy at the application layer, while leaving coordination, network, infrastructure, and frontend layers largely exposed.

Below is a brief overview of privacy risks related to blockchain transactions at every layer:

For most adversaries, breaking cryptography is unnecessary when simple observation, subpoenas, or frontend compromise suffice.

When considering potential blockchain privacy exposures beyond application-layer solutions, three central issues jeopardise user privacy the most.

First, IP-to-address correlation. Once established, this link propagates through the entire analytics ecosystem. Second, centralisation. A small number of RPC providers, block builders, analytics firms, and frontend hosts form natural surveillance hubs beneath an ostensibly decentralised protocol layer.

Third, the browser and application security crisis. Users interact with “trustless” systems through centralised, potentially vulnerable web infrastructure and applications. Recent incidents have shown that smart contract security is irrelevant if the interface is compromised.

Application-layer privacy tools address only a fraction of total exposure. Most leakage occurs elsewhere, often in ways users cannot meaningfully control. 

Until privacy is treated as a full-stack problem, blockchain privacy will remain partial, fragile, and easily undermined by the lack of robust privacy-preserving infrastructure for the large-scale digital communication it relies on.

Logos is an open-source movement aiming to revitalise civil society. We need coders, writers, designers, and all forward thinkers to join us. To get involved, head to the Logos Contribute portal and submit a proposal.