Ethereum: One Address, a Public Financial History

When you give someone your Ethereum address, you may be giving them a way to inspect far more than the payment between you.

A friend paying you back, a relative sending a gift or a customer settling an invoice can look up that address. Its public history can show balances, transfers and interactions with applications. Keep using the same address, and the record keeps growing. They do not need your permission or your private key to read it. 1

That exposure can affect more than privacy. Bots can exploit visible pending trades. Applications can retain spending permissions long after you stop using them. An attacker can study an account before deciding how to approach its owner.

These risks have different causes: persistent addresses, public transaction ordering and the permissions used by applications. Together, they shape the security of an ordinary EVM wallet. To understand them, start with the keys.

The key is private. The account history is public.

A conventional Ethereum account starts with a private key, a secret number used to authorize transactions. Mathematics produces a public key from it. A hash of that public key provides the account's familiar address beginning with 0x.

The private key lets you sign. The address lets people pay you and identify your account on the ledger. Knowing the address does not give someone the private key or the ability to spend your money. 2

Think of the private key as permission to write instructions for an account. Reading the account's public activity requires no such permission. The word “private” in private key describes the secret used for signing. It does not describe the transaction history.

The next payment goes to the same account

If you share an ordinary Ethereum address with three people, all three can send to that address. The basic payment process does not automatically replace it with a fresh destination for each person or each payment.

For a simple ETH transfer, the network can identify the sender, recipient and amount. The signed transaction authorizes a change to account balances. It also has a counter, called a nonce, that distinguishes successive transactions from that account. A new nonce is not a new account or a privacy shield. 3

The result is a continuing public record under one identifier. Your wallet may ask you to approve each outgoing payment, but there is no matching approval screen asking whether everyone else may inspect it.

Ethereum wallets can generate more accounts, each with a different key and address. MetaMask explicitly supports this. The missing protection in an ordinary transfer is automatic separation of receiving destinations, not the ability to create keys. 4

Tokens do not make the record private

Changing from ETH to a standard token does not hide the payment.

The ERC20 token standard includes a way to read an address's token balance. Its transfer event records the source address, destination address and amount. A token may have a different name and a different purpose, but those ordinary transfers still leave a public record. 5

Contract interactions can reveal more than a transfer. Depending on the application, transaction data and events can show swaps, deposits, withdrawals or other actions. An explorer helps people read this information; the explorer is not the reason it is public. 1

Switching EVM networks can preserve the same identity

The Ethereum Virtual Machine, or EVM, is the system that executes smart contract instructions. Many networks adopt Ethereum's execution and account conventions so familiar contracts and wallet tools can work across them. 6

For a normal account controlled by a private key, using that same key on networks following Ethereum's address rules produces the same address. The network name does not enter the calculation of that address. MetaMask documents that an EVM address is used across Ethereum, its supported EVM layer 2 networks and sidechains. 2 7

If you use the same account on Ethereum, Base and Arbitrum, an observer can search for that address on each network. The balances and histories are separate, but the address provides an obvious connection between them. Switching networks in a wallet is not the same as switching identities.

This describes ordinary accounts on public EVM networks. EVM compatibility alone does not require every application or deployment to expose everything. Smart contract wallets can also use different authorization arrangements. Neither a different wallet interface nor a different signer, by itself, erases an address's public history.

One payment can connect a name to years of activity

Imagine a friend asks where to send you a repayment. You give them the address you have used for years.

They now know that this address is associated with you. They can inspect its older public transactions, rather than seeing only their repayment. They can revisit it next month and see new activity. If the address becomes associated with your name publicly, that connection is available to strangers too.

Your name does not have to be written into the blockchain for this to happen. A message, invoice, social profile or public donation page can supply the missing connection.

This is why the duration matters. A small payment today can identify an older account. Continuing to use it adds future transactions to the same visible history. Deleting the wallet app or removing a public post does not remove records that others already have.

Observers can inspect the address's public activity and follow later activity as it happens. Other accounts become part of the picture when there is evidence connecting them. Transactions outside that record are not automatically exposed, but the history attached to this address can remain visible long after the original payment.

Your relationships can become visible too

Payments create connections between addresses. Repeated transfers can suggest relationships, recurring income or business activity. Once more than one address is identified, observers may be able to build a picture of the people involved.

There are limits to what a transfer proves. A payment from an exchange may identify the exchange's wallet rather than the customer's personal account. A transfer does not explain whether it was a gift, purchase, loan or movement between someone's own accounts. Anyone can also send unsolicited tokens to an address, so an incoming transfer is not proof of a relationship or endorsement.

Even so, people usually do not expect paying a friend to create a publicly searchable connection to that friend's other activity. The relationship between two people can be sensitive even when the amount is small.

How exposure becomes a security risk

Public financial information can give an attacker a head start in choosing a target and preparing an approach.

More convincing impersonation. Someone who knows which application you used and when can invent a support message that fits a real event. “There is a problem with your recent deposit” sounds more credible when the sender can name the asset and amount. Ethereum's own security guidance warns about support impersonation and phishing. 8

A clearer target. Visible holdings can help someone decide whom to pursue. When those holdings are connected to a real identity, the concern extends beyond online scams to unwanted pressure, harassment or coercion. A balance alone does not reveal a person's total wealth, but it can still reveal information they never intended to advertise.

Attacks built around familiar addresses. MetaMask documents address poisoning, in which scammers monitor transfers and introduce a similar looking address into a person's transaction history. They hope the person copies the wrong destination later. This is a direct example of public payment activity being used to prepare a theft attempt. 9

Exposure of private affairs. Payments may reveal customers, suppliers, donations or patterns of support between people. A business can lose commercial confidentiality. An individual can lose control over who knows about a financial relationship.

Profiling without permission. Once a service knows your address, it can use the public record to judge your activity, classify you or decide whether to serve you. Those judgments may rest on incomplete evidence. An unsolicited transfer can appear in the same history as a payment you actually requested.

None of this requires breaking the mathematics protecting the private key. The attacker can use what the system openly reveals and concentrate on deceiving or pressuring the person who holds it.

A trade can be exploited before it executes

When you submit a swap through a public transaction pool, other participants can see the pending instructions before the swap enters a block. This waiting area is usually called the mempool.

A bot may recognize an opportunity and arrange for its own transaction to execute first. This is front running. Your signature authorizes your transaction, but it does not reserve a fair position relative to everyone else's transactions. The value available through including, excluding or ordering transactions is called maximal extractable value, or MEV. 12

A sandwich attack makes the effect easy to understand. Suppose you are buying a token from a liquidity pool:

1. An attacker buys before you, pushing the pool price up.
2. Your purchase executes at the worse price, within the limits you allowed.
3. The attacker sells after your purchase, trying to profit from the price movement at your expense.

The attacker never needs your private key. Your trade can succeed exactly as the contract permits while giving you fewer tokens than you would have received without the attack. 13

Your slippage setting limits how far execution can move from the quoted outcome. A generous tolerance can give a sandwich more room. A tighter limit can reduce that room, but may also cause the swap to fail when prices move. 14

Not every form of MEV harms a trader. Arbitrage can align prices, and liquidations help lending protocols remain solvent. The objection is to arrangements that extract value by worsening the user's execution. Competition over ordering can also increase congestion and fees. 12

This risk comes from visible instructions and control over ordering. A fresh address alone cannot stop it. Nor does every EVM network expose pending transactions in the same way: private submission and different sequencer arrangements change who can see a trade before execution.

Borrowing positions can be watched continuously

Public lending applications expose another kind of vulnerability: the condition of a position. Aave, for example, describes bots monitoring borrowers and competing to liquidate eligible positions. When its health factor falls below the protocol's threshold, a liquidator can repay debt and receive collateral plus a bonus. 15

Liquidation is part of the agreed lending mechanism. It is not automatically an attack. But the borrower has little confidentiality about the position being monitored. Linking that position to a person's recurring account also links it to their other visible activity.

The same visibility can expose a trading strategy. An observer may follow entries, exits and changes in holdings. Whether they can profit from that information depends on the market and application, but the user has already lost control of who can study it.

A token approval can outlive the trade

Many token applications ask for a separate spending permission before the actual action. In ERC20, this is an allowance: a named spender can move a specified amount of a particular token from your account. It does not need a new signature from you for every transfer within that permission. 5

An unlimited approval can expose the account's present balance of that token and tokens received later. If the approved spender is malicious, or its code can be exploited to misuse the permission, an old approval can become the route to a loss. This is one reason continuing to accumulate assets under one account matters. 16

The scope matters. A conventional approval applies to a particular token contract and spender on a particular network. It is not automatic authority over every asset or the same address on every chain. An ERC20 approval alone does not authorize spending native ETH.

NFTs have related permissions. ERC721 allows an operator to manage all of an owner's NFTs within that collection's contract. A prompt that grants permission for all can therefore cover more than the single item a person intended to sell. 17

Disconnecting a wallet from a website does not revoke its token approvals. Revocation is a separate change to the permission recorded on the blockchain. Disconnecting also cannot make a previously disclosed address or its public history unknown again. 18

A message signature can authorize spending too

A request to sign a message is not necessarily a harmless login.

ERC2612 permits an allowance to be authorized by a signature and submitted by someone else. The user does not have to send the approval transaction personally. The signed amount, spender, nonce and deadline matter. In this standard, the deadline limits when the permit can be submitted; it does not automatically make the resulting allowance expire. 19

Other systems, including Permit2, also use signed permissions. A phishing page can disguise a spending authorization as a routine signature request. Paying no gas at the moment of signing does not mean the signature has no financial effect. 16

There can be broader authority too. On networks supporting EIP7702, an account can authorize delegated code to execute in its context. The specification warns that a poorly implemented delegate can give an attacker near complete control of the account. Such delegation can persist beyond one transaction. A wallet upgrade or delegation prompt therefore deserves the same attention as a request for substantial account access. 20

These are permission risks, not proof that someone can drain an account merely by knowing its address. The danger is signing authority whose consequences are broader or longer lasting than expected.

Spam can become an invitation to sign

An address can receive unwanted tokens or NFTs. Their names or descriptions may direct the owner to a supposed reward, refund or claim page. Seeing an asset in your wallet does not establish that its issuer is trustworthy.

The trap is often the next step: visiting a malicious page and signing a transaction or permission. Receiving an unsolicited token by itself does not give its sender your private key. Combined with address poisoning, this turns the public account history into a place where attackers can plant misleading material. 8 9

The wallet connection can reveal more than the ledger

When you connect an account to an application, the application learns the address you choose to share. It can then inspect that address's public activity. Connecting alone does not grant spending permission. 16

There is also an internet service layer. Depending on the connection and privacy settings, a website or RPC provider used by the wallet may receive an IP address alongside account queries or transaction submissions. That can help connect blockchain activity to activity outside it. Provider practices differ; receipt of a request does not establish that every provider stores or sells it. MetaMask's privacy notice describes how processing varies with its services and settings. 21

This metadata is not automatically written into the blockchain. It is a separate exposure created by the services used to access it.

Reusing the key also concentrates the damage

If the same private key controls an ordinary account on several networks, stealing that key can expose assets controlled by it on all of those networks. Moving from Ethereum to another EVM network does not isolate the signing secret when the wallet keeps using the same one. This follows from the shared key and address arrangement described earlier. 2 7

That is different from a limited token approval being abused on one chain. A compromised signing key is a much broader failure. Repeated use of a correctly implemented signing system does not, by itself, reveal the key; theft can instead happen through phishing, malware or exposure of the recovery phrase.

Failed and delayed actions can still cost you

An included transaction that fails during execution can still consume gas. A swap may produce no exchange of assets while leaving its sender with a fee. That is a cost of executing public contract instructions, including unsuccessful ones. 22

Ordinary outgoing transactions from one account also follow a nonce sequence. A pending transaction can hold up later transactions from that account on the same network. Using one account for several applications can therefore tie their progress together. This is an operational consequence of the account model, not something a stranger can cause merely by sending you a token. 23

A fresh address helps, but the connections matter

Keeping separate accounts can reduce the amount of history exposed by sharing any one address. But sending funds directly from a known account to a new one creates a visible connection. That connection does not prove both accounts have the same owner, though amounts, timing and later behavior may strengthen the inference.

Creating several accounts from one recovery phrase does not automatically publish that phrase or a list grouping those accounts together. Their public activity and the information you share can connect them. The recovery phrase remains a separate security responsibility because it can control multiple accounts. 4

A hardware wallet helps protect signing keys. It does not hide the public history of the address it controls. Likewise, a password on your wallet protects access to the app; it does not require observers to enter that password before reading the blockchain. 8

Privacy must be part of the payment mechanism

Ethereum has mechanisms designed to improve privacy. The ERC5564 stealth address standard describes how a sender can generate a fresh destination accessible to the recipient. This requires software that implements the mechanism. A normal transfer to a familiar 0x address does not automatically use it. 10

The word “private” also needs context. Sending through a private transaction relay can hide a transaction from the public waiting pool before it enters a block. That does not, by itself, conceal the payment once it is included in the public chain. Flashbots distinguishes this temporary protection from broader privacy. 11

Protecting users therefore takes several different measures. Fresh receiving destinations address unwanted links between payments. Protected trade submission and sensible execution limits address some ordering attacks. Limited permissions and revocation address spending authority. Protecting the signing secret addresses key theft. None of these substitutes for all the others.

The question for any wallet is specific: what does the payment reveal about the sender, recipient, amount and their other activity? A new interface or network name does not answer it.

In my Bitcoin and Safex article, I explain how fresh destination keys and ring signatures address parts of this problem. Different mechanisms protect different information, and amounts or information shared outside the blockchain may remain exposed.

I want to be able to receive a payment from a friend, relative or customer without giving them a window into unrelated financial activity. I also want them to have that protection when they pay me. Keeping payments secure includes protecting the people whose lives those payments describe.

This article covers ordinary public transactions and conventional Ethereum account behavior. The diagrams are simplified examples. References were checked on October 13, 2026.