Did you know? A public blockchain can hide your real name while still showing a remarkably detailed history of what an address has done. You may never type a name into the network, yet somebody examining the ledger can still observe amounts, contract interactions, timestamps, token movements and repeated relationships between addresses.
Imagine Alicia, Kai Kai and Tricia join a fictional school science club. Instead of writing their names on a public noticeboard, the club assigns account labels A1, K2 and T3. Every time they exchange imaginary credits, the club records the source, destination and amount. A passer-by does not immediately know which label belongs to which student. But after seeing Alicia announce “A1 is my account” on the club website, the passer-by can connect that identifier with its earlier activity.
That is the difference between pseudonymity and anonymity. A pseudonym replaces a name with another identifier. It does not necessarily hide the person’s activity or prevent that identifier from being linked back to them.
Quick answer: On transparent public networks such as ordinary Ethereum, on-chain transactions and account activity are generally inspectable. Addresses are not automatically linked to legal names in the protocol, but transaction patterns and external information can link addresses to people or institutions. A public ledger is not the same as a private bank statement, and simply choosing a new username does not create comprehensive anonymity.
This guide explains how blockchain technology works when people mistake a string of letters and numbers for a privacy guarantee. It uses everyday examples and a safe paper exercise. No real cryptocurrency, account or identity information is needed. Begin with What Is Blockchain? for the broad foundation; here we stay with one reader question: who can see a public blockchain transaction, and what can they really learn?
Choose Your Reading Route
- The one-minute picture: public record, private name
- Pseudonymity is not a magic invisibility cloak
- What an ordinary Ethereum explorer can reveal
- Why repeated use of an address can reveal relationships
- A public wallet address is not a login password
- A different address does not guarantee complete privacy
- Transparency is useful, even when privacy needs protection
- Frequently asked questions
- Sources and further learning
The one-minute picture: public record, private name
Consider a public school noticeboard showing that A1 transferred ten classroom credits to K2. The note contains no student’s legal name. Someone can truthfully say, “The board does not identify Alicia.” But everyone can still see that A1 paid K2 and can compare this event with other notes.
A blockchain explorer performs a similar reading job, although the real cryptography, consensus and transaction records are considerably more sophisticated than paper notices. It can present accepted blocks, addresses, transfers and contract activity without requiring every visitor to identify themselves.
This transparency is useful. Independent observers can verify that published records match the network’s accepted history, subject to the network’s rules and the verifier’s method. A system need not depend entirely on one institution’s private spreadsheet to check important state changes.
The price of transparency is that public information can be analysed. A wallet address that appears in several transactions becomes a repeated identifier. An external detail such as an official donation page, social profile or business invoice can connect that identifier with a known person or organisation.
The fundamental distinction is not that blockchains reveal everybody’s real identity. They generally do not. It is that hiding the name field does not hide all the transactions.
Ethereum’s Privacy overview describes how transparent activity, pseudonymous addresses and network metadata can combine into privacy risks. Its documentation is especially useful because it does not confuse transparent verification with universal user anonymity.
Pseudonymity is not a magic invisibility cloak
A pseudonym is an alternative identifier. Authors use pen names, online communities use handles and blockchain applications use addresses. A pseudonym can help separate some activity from a legal identity, but it is not inherently secret or untraceable.
Suppose the school club publishes a weekly list of transfers made by account A1. A reader learns that A1 repeatedly pays the equipment department and receives rewards from a particular project. Even if the reader does not know Alicia’s name, the public activity already reveals a pattern.
Now the club posts a photograph captioned “Alicia’s account A1 received this month’s science award.” The missing link becomes public. Earlier records connected to A1 can now be interpreted as Alicia’s activity to the extent she actually controlled that account during those times.
That final qualification matters. An address can represent a shared account, a smart contract or a custodial operator rather than one unique human. Analysts can make wrong identity claims when they treat a public identifier as a permanent personal ID.
A careful conclusion distinguishes what the ledger shows, what a separate source asserts and what the available evidence reasonably supports about control or identity. Correlation is not always proof of ownership.
For that second issue, read Why a Blockchain Address Is Not a Verified Identity. Addresses and real people must not be silently equated.
What an ordinary Ethereum explorer can reveal
An Ethereum explorer can let a reader examine an address’s native-asset transactions, token transfers, contract interactions and other public on-chain activity that its services support. The exact displays depend on the explorer, network, contract and indexer.
In a simple example, a public transaction may reveal its sender, destination, transferred value, associated block and processing outcome. Smart-contract calls can expose encoded function data or emitted logs. A friendly interface can decode technical fields into labels that are easier to read.
Not every displayed item is a separately signed transaction. An explorer may derive token-transfer lists from contract events or show execution traces under labels such as “internal transactions.” Those categories need to be interpreted according to the network and service.
A viewer might also find amounts denominated in the native asset or third-party estimates in a national currency. The latter often depend on market data that was not itself written into the transaction. A public balance does not therefore prove a precise cash value or real-world ownership.
The relevant point is that ordinary users usually need not know the address owner’s name to read the public chain. They can query the identifier and receive a record of visible activity.
This is why the privacy question is not solved merely by asking whether you entered an email address into a wallet app. The network’s public data are available independently of the app’s login process.
Why repeated use of an address can reveal relationships
Alicia uses account A1 for the science-club store, a public prize, her exhibition ticket and a class fundraiser. Each activity creates another visible connection in the fictional ledger.
Someone who sees A1 named in the club’s prize announcement could follow transactions involving that identifier and notice the associated organisations. Some observations may have a straightforward explanation. Others may be ambiguous or unrelated. The important fact is that repeated public identifiers permit linkage attempts.
For example, a public donation address published by a charity provides a starting point for observing incoming transactions. That can help supporters assess public flows, but it may also expose donors or connected accounts when additional identifying information is available.
The existence of such linkages does not grant a stranger legitimate access to private bank accounts, passwords or off-chain records. Nor does a transaction automatically reveal the owner’s precise physical location. Analysts can sometimes infer patterns, but each claimed inference needs evidence and appropriate uncertainty.
For organisations, the question is whether all relevant activity should appear under one public operational identity. Governance transparency can be beneficial; publishing personal student transactions can be inappropriate. A sound design separates public accountability from unnecessary exposure.
The most useful reader habit is to ask which public identifiers are reused, what outside records connect them to identities and what sensitive conclusions an observer could attempt to draw from those connections.
A public wallet address is not a login password
It is generally possible to inspect a public address without possessing its private key or a recovery phrase. The address identifies the account within the relevant network rules; the signing authority determines who can authorise applicable actions.
That separation enables public auditing. Tricia could monitor a club treasury address and review accepted transfers without receiving power to spend its credits. Observing an account does not make her its owner.
It also means publishing a public address need not be equivalent to disclosing a private key. Yet a public address can be privacy-sensitive because it may connect transaction histories, contacts or institutional associations. A value can be safe to publish in a cryptographic sense while still requiring care in a personal-data context.
This distinction is particularly important for parents and students. A support worker might legitimately request a non-secret transaction hash when investigating a network record, but should not ask a family to post recovery words or wallet passwords. A separate privacy judgment is still needed before sharing public addresses together with full names and other identifying details.
Read Why a Wallet Password Is Not a Recovery Phrase for the difference between credentials, public identities and signing authority.
Good blockchain literacy is not an instruction to hide everything. It is the ability to describe what each disclosure reveals, who can read it and which information must remain secret.
A different address does not guarantee complete privacy
A user may have several addresses for different activities. That can reduce some direct links under a particular design, but it is not enough to guarantee anonymity or protect every interaction.
Public transaction patterns, shared services, repeated counterparties, funding relationships and off-chain information can sometimes connect accounts. Such analysis can also produce false positives. A person should not treat a suspected linkage as conclusive proof of identity without independent support.
An ordinary classroom example makes the issue visible. Suppose A1 and A2 have different labels but are both funded by an account officially identified with one student. An observer might suspect a relationship. That suspicion is not the same as proving that every activity under both labels belongs to the same person.
Some systems use specialised privacy-preserving cryptography that changes what observers can learn about transactions or account relations. Those mechanisms have their own assumptions, limitations and operational requirements. Simply creating another conventional transparent address is not the same technical protection.
For students, the important distinction is between using multiple pseudonyms and providing a formal privacy property such as hiding selected transaction details or proving membership without revealing which member acted.
Ethereum’s Zero-Knowledge Proofs overview explains how proving a statement need not disclose all of the information behind it. That is a different security promise from a bare address-format convention.
Transparency is useful, even when privacy needs protection
Public ledgers are not inherently flawed because they expose defined records. Transparency can be valuable for checking a public treasury, tracing specified asset movements, verifying contract state and allowing participants to audit a shared history under agreed rules.
Suppose the school science club publishes its total grant spending through an on-chain treasury. Students can observe transfers to authorised project accounts without relying exclusively on the treasurer’s monthly summary. That can support accountability.
But the club may also support students facing private financial or family circumstances. Making individual recipients, assistance amounts and personal identities easily linkable could harm those students. A useful transparency requirement therefore needs a careful design for what is made public.
A system could publish aggregated accountability information while keeping sensitive applicant records appropriately protected. The mechanism might involve controlled databases, selectively disclosed credentials or privacy-enhancing proofs under an accountable governance model.
The architecture should begin with the purpose: What must the public verify? What must participants keep confidential? Who may disclose information with consent or lawful authority? How should errors and disputes be handled?
The best choice might be a public chain, a permissioned system or an ordinary database with suitable audit processes. A fashionable technology label should not replace the underlying privacy and accountability analysis.
Network and website metadata create another privacy layer
The public ledger is only one source of information. A user’s browser or wallet can also contact an RPC service, block explorer, app website or other provider to obtain account balances and transaction data. Those services may receive operational metadata such as network addresses, request times and queried account identifiers.
A privacy-conscious design has to consider what an intermediary learns when someone reads the chain as well as when they write a transaction to it. A user can avoid posting a legal name on-chain yet still disclose sensitive patterns to an app or data provider.
The Ethereum privacy roadmap explicitly distinguishes private reads, private writes and the way users connect to the network. The 2026 Ethereum Privacy Roadmap discusses research aimed at reducing metadata exposure and making privacy more structural.
These goals are not all automatically active features of every wallet or provider. Standards and proposals should be distinguished from deployed functionality and a particular product’s guarantees.
The school analogy extends naturally: even if students use account labels on the noticeboard, the receptionist might keep a separate log showing who came in to check which records. That access log is another information source, not part of the public notice itself.
A good privacy assessment therefore follows the whole data journey: account, wallet, app, RPC provider, blockchain record, explorer and any analytics services. Ignoring intermediaries can create an incomplete picture of what users reveal.
What a zero-knowledge proof can help with
A zero-knowledge proof can, under a specified proof system and assumptions, let a verifier check a defined statement without learning all of the underlying information. This is useful where a service needs to know a particular fact rather than every personal detail behind it.
Imagine a school club needs to verify that a participant is a registered member without posting each member’s name and detailed activity to a public leaderboard. A suitably designed proof system might support a narrow membership claim while concealing which member supplied it, subject to the implementation’s privacy conditions.
That does not mean every system using the letters ZK is anonymous. A proof can be mathematically sound while the surrounding application exposes an identifier, address, timing pattern or other data that links the user to an activity.
The source of the fact also matters. Proving membership against a false or compromised membership register does not make the register truthful. Cryptography establishes the relationship between the proof, statement and inputs under its rules, not the honesty of every issuer.
The Ethereum Foundation’s May 2026 guide to privacy apps with zero-knowledge proofs describes the distinction between the privacy property of a proof and the additional design needed for a functioning private application.
For students, the essential lesson is to name the exact claim: “I can prove I qualify without revealing which person I am among eligible members” is meaningful. “ZK makes blockchain completely invisible” is not a well-defined guarantee.
Why privacy claims require precise wording
The words anonymous, private, pseudonymous, encrypted and confidential refer to different properties. A public transaction may be pseudonymous because it uses an address rather than a legal name. It may still reveal the full on-chain value and counterparties.
Encrypted data can conceal its readable contents under security assumptions, but metadata about when it was published or which accounts interacted with it may remain visible. A proof might hide specified witness information while leaving some public inputs disclosed.
A permissioned blockchain may restrict which parties participate or see certain data. That is an access-governance model, not necessarily an assurance that all participants learn nothing about each other. A private website can also collect information from users even when the underlying chain is public.
A claim of “fully anonymous payments” therefore needs a clear threat model. Who is the observer? What transactions or identities are concealed? What can the wallet provider, relayer, validator, recipient and application operator see? Which assumptions must hold?
The same questions matter for education credentials, donations and medical data. A system can protect some information while exposing other details required for verification.
A trustworthy project explains the actual privacy property and its limitations instead of using a single badge that implies everybody, including the service operator, knows nothing.
Why personal documents generally do not belong in public transaction data
A public-chain transaction may remain accessible to many participants for a long period. Publishing a student’s name, home address, health information, exam result or identity-document image directly into such records can create serious privacy and retention difficulties.
Even when data are hashed, privacy cannot be assumed automatically. If an input is predictable, such as one answer from a small set, an observer may be able to test candidate inputs against a publicly known hash. The resulting risk depends on the scheme, context and outside information.
A school that needs verifiable certificates could keep sensitive originals in an access-controlled system while using carefully designed signatures, issuer registries or integrity commitments. Whether a blockchain is necessary at all should be evaluated according to the problem.
The right question is not “How much can we put on-chain?” It is “What minimum information must a verifier learn, and which information should remain under authorised control?” Data minimisation can be as important as cryptographic correctness.
These choices also depend on applicable privacy law, institutional policy, consent and retention requirements. A permanent ledger should not be used as a way to avoid correcting an erroneous personal record.
For deeper study, see Blockchain Data Protection: Trace Every Copy Before Promising Deletion and Verifying an Education Credential.
What a block explorer cannot prove about a person
An explorer can show protocol records from a particular network. It does not independently establish who is legally responsible for every address, whether two addresses share a human controller or why a person performed a transaction.
Suppose account A1 receives regular payments from a public charity address. The records may support a statement about on-chain transfers. They do not alone establish that Alicia was the beneficiary, that all payments were charitable gifts or that every payment had a particular personal meaning.
An observer may form plausible hypotheses using repeated timing, values and associated activity. Those hypotheses should not be presented as verified personal facts without appropriate independent evidence. A shared treasury or exchange address can make naive analysis particularly misleading.
This caution matters for fairness. Public transparency should not become an excuse to publish unjustified accusations about private individuals. Technical data are evidence of network actions; human motivation and identity require their own verification.
It also matters for readers evaluating alarming social-media threads. A colourful graph connecting addresses may be generated from real transactions while the displayed names, clusters or allegations remain interpretative.
Ask which nodes in the graph are directly identified, which links are inferred and where uncertainty is recorded. That habit helps people use public information responsibly rather than treating every algorithmic association as truth.
A fictional exercise: link the three club accounts
Write three imaginary account labels on paper: A1, K2 and T3. Draw a public ledger containing five transactions. A1 sends K2 ten credits, K2 sends T3 four, A1 donates to the club treasury, T3 pays for equipment and K2 sends A1 two credits.
The class can already describe a graph of transfers without knowing who controls the labels. Now show a public announcement identifying A1 as Alicia’s official student-project address. Ask which earlier transactions may be associated with that disclosed account.
Then reveal that K2 is a shared account used by two authorised club officers. Students should recognise why it would be wrong to assume every K2 action belongs personally to Kai Kai. The label is an account identifier, not a perfect map of humans.
Next ask how the interpretation would change if a wallet app recorded a visitor’s IP address while the visitor looked up A1. That information is not in the classroom ledger, but it can be relevant to the overall privacy model.
Finally, let the students rewrite an overstated conclusion. Replace “The ledger reveals exactly who everyone is” with “The public graph shows account relationships, and some outside evidence can connect identifiers to people under specified conditions.”
The whole exercise uses paper labels, fictitious events and no real identity details. It teaches transparent data reading while protecting students from unnecessary public disclosure.
A seven-question privacy check for ordinary readers
What network is involved? Public, permissioned and privacy-oriented systems can expose different information. Do not assume one network’s properties apply to every chain.
What is publicly recorded? Identify addresses, amounts, timestamps, contract data, logs and other accessible fields relevant to the proposed action.
Which identifiers are reused? Repeated addresses and public names may make activity easier to link. Think about what outside records connect them.
Who else receives data? Wallet providers, websites, RPC services, exchanges and custodians may possess metadata beyond the on-chain records.
What exactly is being kept private? Legal identity, transaction amount, recipient, file contents and query history require different protections.
What is the privacy mechanism? A pseudonym, encrypted file, zero-knowledge proof or restricted-access network offers different properties and assumptions.
What claims remain unverified? A public transaction graph may not establish who controls a shared account or why a payment occurred. Keep inference separate from observation.
For family and school use, add one operational rule: do not publish children’s account identifiers alongside sensitive personal information merely to demonstrate a technology project. Privacy should be designed, not treated as an afterthought.
Frequently asked questions
Are blockchain transactions anonymous?
On many transparent public blockchains, transactions are pseudonymous rather than fully anonymous. Addresses are visible without an automatic legal-name field, but activity patterns and outside information can link them to people or organisations.
Can anyone see my Ethereum transactions?
Ordinary on-chain Ethereum transactions and relevant public contract data are broadly inspectable, subject to the network and available data services. You normally do not need to be the account owner to read public records.
Does an address reveal my real name?
Not inherently. But public profiles, exchange or service information and other external data can connect an address with an identity, sometimes with uncertainty or mistakes.
Is a new address the same as anonymity?
No. Separate identifiers do not guarantee that transaction patterns, funding relationships or service metadata cannot link the activities.
Can a block explorer identify every person behind an address?
No. A public address can represent one person, several signers, a smart contract, a service or a pooled custodian. Human attribution requires appropriate evidence.
Why is transparency useful?
It can let independent participants verify specified records and state without depending solely on one private database. Privacy controls are still needed for sensitive personal information.
Are privacy and decentralisation the same thing?
No. A network can distribute validation widely while publishing transaction details. Privacy concerns which information observers can learn; decentralisation concerns authority and operation.
Does encryption hide the transaction’s metadata?
Not automatically. Encryption may protect selected contents while leaving addresses, timestamps or surrounding public data visible depending on the design.
Can zero-knowledge proofs improve privacy?
They can prove specified statements without disclosing all underlying inputs under defined assumptions. The surrounding app and networking layers still need careful design to avoid exposing linked identifiers or other metadata.
Should a school publish student records on-chain?
Public disclosure of student personal information can create significant privacy risks. Use data minimisation, suitable access controls and an appropriate verification design rather than assuming immutability is always desirable.
Is a pseudonymous donation completely private?
Not necessarily. Transfers to public addresses may be observable and outside information can connect an address to a donor. The privacy result depends on the full system.
What should I remember?
A public blockchain may not name its users, but it can still preserve a visible history of their accounts. Pseudonymity is not a guarantee of anonymity.
Sources and further learning
Ethereum Privacy explains transparent ledgers, pseudonymous addresses and metadata risks. The Ethereum Privacy Roadmap discusses ongoing research into private reads and writes; roadmap proposals should not be mistaken for universal protections already available in every wallet. Ethereum’s Zero-Knowledge Proofs introduction explains what proof systems can selectively establish, and Privacy Apps on Ethereum provides a 2026 tutorial discussing anonymous membership and the wider application requirements.
Within eduKateSG, read Why a Blockchain Address Is Not a Verified Identity, Where Blockchain Files Are Actually Stored, Cryptographic Guarantees and Threat Models and Blockchain Data Protection for the distinctions between identification, storage, cryptographic guarantees and retention.
The useful habit is to ask what is visible, which identities can be linked to it, and which protections actually exist. A public network’s accountability benefits and a person’s legitimate privacy needs can both matter—and neither should be hidden behind an oversimplified claim.