Can you target people by their wallet, and should you?
You can see more than you should want to. A wallet address exposes a complete, permanent, public financial history: every purchase, every holding, every counterparty, timestamped. That is why wallet targeting is pitched as the category's advantage. It is also why the moment you connect an address to an email in your own systems, you are processing detailed personal financial data, under obligations most marketing teams have never applied to it.
What can you actually see from a wallet address?
The entire transaction history of that address, in full, forever, without asking anyone. Balances, every token and collectible held, every contract interacted with, exact timing, and the addresses on the other side of each transaction. On a public chain this is not a data feed you subscribe to, it is the default state of the record.
What you do not see is a name. Addresses are pseudonymous, which people hear as anonymous and it is not the same thing at all. Identity leaks through the edges: a naming service handle, an address posted in a public profile, a deposit into an exchange that performed identity checks, or simply the person telling you when they claim something from your site.
The practical significance is that the pseudonym is durable and the linkage is one-way. Once an address is associated with a person, every past and future transaction of that address is associated with them too, retrospectively, and nothing can undo it.
Is a wallet address personal data?
Treat it as personal data whenever it can be linked to an identifiable individual, whether by you or by anyone else with reasonable means. Under UK and EU data protection law, pseudonymised data remains personal data, and the test is identifiability rather than actual identification. A wallet address sitting in your CRM next to an email is unambiguously personal data, and it drags a financial history along with it.
This has consequences teams rarely plan for. You need a lawful basis for processing it, your privacy notice has to describe it, the individual has rights of access and objection over it, and if you are profiling on the basis of holdings you are profiling on financial behaviour. Most privacy notices in this sector do not mention wallet addresses anywhere.
There is also a security dimension. A list mapping wallet addresses to email addresses is an unusually attractive target, because it converts pseudonymous wealth into a list of named people with known balances. Breaches of that pairing have led directly to targeted phishing and physical threats, so it should be held to a higher standard than an ordinary marketing list.
How do deletion rights work against an immutable ledger?
By keeping personal data off the chain entirely. You cannot delete an on-chain record, so the workable architecture is to store nothing about a person on-chain, hold the link between address and identity in a system you control, and honour an erasure request by deleting the link. The address remains public, but the association that made it personal data is gone.
This makes one design decision non-negotiable: never write identifying information into token metadata or contract calls. Names, emails, order numbers, membership tiers tied to a person. Anything written there is permanent, world-readable, and cannot be corrected or removed, which conflicts directly with both erasure and rectification rights.
Minimisation follows the same logic. Collect the address if you need it to deliver the asset, and resist the temptation to enrich it with everything the chain will tell you. Enrichment is trivially easy here, which is precisely why it needs a deliberate limit rather than a default.
| What you hold | What it reveals | Personal data? | Sensible use |
|---|---|---|---|
| An address with no linkage | Full transaction history, no identity | Often, if linkage is reasonably possible | Aggregate analysis only |
| Address paired with an email | A named person's financial history | Yes, unambiguously | Delivering what they asked for, with a lawful basis |
| Address plus a public social handle | Identity plus holdings, publicly linked | Yes, and it was already public | Support and verification, not enrichment |
| Third-party wallet labels | Someone else's inference about the holder | Yes, and possibly inaccurate | Treat with caution, inferences carry rights too |
| Scraped holder lists | Addresses of another project's community | Yes, with no basis to process them | Do not |
| Token-gated login | Proof of holding, nothing more if designed well | Minimal, and that is the point | Access control without collecting a profile |
What is actually useful, and what should you refuse to do?
Useful: segmenting on behaviour you caused. Holders who redeemed against holders who did not, first-time holders against repeat, people who bought directly against people who acquired on a secondary market. All of this comes from your own distribution, relates to your own relationship, and supports messages the recipient will recognise as relevant.
Refuse: buying or scraping holder lists from other projects and marketing at them. There is no lawful basis, the addresses did not consent to anything, and the tactic is indistinguishable to the recipient from the phishing they receive daily. The same applies to sending unsolicited tokens to addresses as an advertising method, which additionally trains people to interact with unknown contracts, the exact behaviour that gets wallets drained.
Between the two sits enrichment: knowing what else a holder owns because the chain will tell you. It is legal to look at public data and it is rarely wise to act on it visibly. A message that reveals you have been reading someone's financial history is unsettling in a way an ordinary retargeted ad is not, and this audience is more sensitive to it than most.
What test can you run this afternoon?
Take one address from your own holder list, open a block explorer, and spend fifteen minutes. Write down what you have learned: total holdings, what else they collect, roughly how much they have spent, who they transact with, whether they appear to have sold at a loss. Then ask whether you would be comfortable with that document sitting in your CRM, and whether your privacy notice tells them it might be.
Second test: search your privacy notice for the word wallet. If it does not appear, you are processing a category of personal data you have not disclosed, which is a straightforward gap to close and an awkward one to explain later.
Third: ask your engineers what is written on-chain when a customer claims. If any part of the answer identifies a person, fix it before launch, because after launch it cannot be fixed at all.
Common questions
- Is a crypto wallet address personal data under GDPR?
- Treat it as personal data whenever it can be linked to an identifiable individual by you or by anyone else using reasonable means. Pseudonymised data remains personal data under UK and EU law, and the test is identifiability rather than actual identification. An address stored alongside an email is unambiguously personal data, and it carries a complete public financial history with it.
- How do you handle a deletion request for blockchain data?
- By keeping the personal data off-chain in the first place. On-chain records cannot be deleted, so the workable design stores nothing identifying on the chain, holds the link between address and identity in a system you control, and satisfies an erasure request by deleting that link. The address stays public, but the association that made it personal data is removed.
- Can you market to wallet addresses you did not collect?
- There is no lawful basis for it and the recipient cannot distinguish it from phishing. Scraping or buying another project's holder list gives you addresses whose owners have no relationship with you and have consented to nothing. Sending unsolicited tokens as advertising is worse, because it trains people to interact with unknown contracts, which is the behaviour that leads to drained wallets.
- What can you legitimately see from someone's wallet?
- Everything that address has ever done: balances, all tokens and collectibles held, every contract interaction, exact timestamps and every counterparty. What is not visible is a name, though identity commonly leaks through naming services, public profiles or exchange deposits. Once an address is associated with a person, the association applies retrospectively to their entire transaction history.
- What should never be written on-chain in a marketing programme?
- Anything identifying a person: names, email addresses, order references, or membership details tied to an individual. On-chain data is permanent, world-readable and cannot be corrected or removed, which conflicts directly with rectification and erasure rights. Ask engineers exactly what a claim transaction writes before launch, because after launch the record cannot be changed.
