No title

15 Jul 2025

15 Jul 2025 by Luke Puplett - Founder

Let's get straight to it: your blockchain wallet address is visible to everyone, everywhere, all the time. That's how blockchains work—every transaction, every token, every NFT, every DeFi move you make is tied to that address, and it's all out in the open for anyone to see.

Blockchains rely on pseudonymity for privacy. As long as nobody knows who owns a given wallet address, you're just a string of numbers and letters in a sea of other strings. But the moment someone links your wallet address to your real identity—your name, your email, your phone number, whatever—you're doxed.

What's doxing? It's when your private info gets exposed and tied to your public activity. In blockchain land, that means your entire financial history is suddenly mapped to you, personally. Every transaction you've ever made, every project you've supported, every token you've held, every NFT you've bought or sold, every smart contract you've interacted with—it's all there, and it's all you.

Think about what that reveals: your income, your spending habits, your investment strategy, your interests, your social and professional circles, maybe even your political leanings or charitable giving. It's a full financial dossier, and it's permanent.

So here's the real danger: if an app ever has both your wallet address and your personal details, you need to tread very carefully. That app is now the single point of failure for your privacy. If they get hacked, leak data, or just screw up, your pseudonymity is gone and your entire blockchain life is exposed. That's why any app in this position must have the absolute highest standards in security—because the stakes are that high.

Are You Linking Wallets to Real Identities—And Do You Know the Risks?

Many dApps and Web3 applications with traditional backends store your wallet address directly in their database and use it for both authentication and blockchain interactions. While some applications are thin browser apps with no backend storage, those that do store addresses often take this lazy approach, which creates problems.

When databases get compromised (and they do), your wallet address gets exposed. Suddenly, someone can link your real identity to your entire blockchain transaction history. That's not just a privacy violation—it's a complete breakdown of what makes blockchain valuable in the first place.

But here's the really annoying part: for simple authentication, you don't need to surrender your wallet address permanently. You just need to prove you control it. Yet many applications that do store addresses keep this sensitive information indefinitely, creating unnecessary risk.

The regulatory side is equally frustrating. Privacy regulations require applications to collect only necessary data and give users rights to know what's collected and request deletion. These rights become a nightmare to fulfill when wallet addresses are stored without clear purpose.

And let's talk about user trust. When users realize that many dApps they touch are storing their wallet address in plaintext—like a username instead of a password—they get hesitant. This creates a barrier to adoption that the entire industry has to deal with.

The industry standard of treating wallet addresses like usernames ignores their unique characteristics: they're permanent, globally visible, and can reveal complete financial histories when linked to real identities.

How Regulation Can Make Things Worse

Now, let's talk about the elephant in the room: regulation. You'd think that privacy-minded rules would help, but in the blockchain world, it's often the opposite. Regulators force companies to collect personal details—KYC (Know Your Customer) is the classic example. Suddenly, you're not just holding a wallet address; you're holding a real name, a passport scan, maybe even a selfie. And you're linking all of that to a blockchain address that's visible to the world. If your database ever leaks, you haven't just lost a password—you've handed over someone's entire financial history, mapped to their real identity. That's a privacy disaster waiting to happen.

Here's something we do differently at Zipwire: we let users delete their original personal details, but the cryptographic proofs (attestations) remain. That means users can prove they're eligible for something—like being over 18, or having passed a check—without us needing to keep their sensitive documents in plaintext. Users get the benefit of blockchain-based verification, but they're not stuck with their personal data sitting in our database, waiting to be compromised. That's how we think privacy should work in Web3.

The Solution: Stop Being Lazy

At Zipwire, we've implemented a dual-security approach that recognizes different use cases need different privacy protections:

Authentication: Hash-Based Verification

For login and authentication, we treat wallet addresses like passwords—never storing the actual address. We use cryptographic hashing to convert wallet addresses into secure, unreadable hashes before storage. The original address never gets written to disk, so even if our database gets compromised, your wallet address stays protected.

Our verification system confirms wallet ownership without storing the actual address. When you sign a message with your wallet, we verify the signature against the stored hash, proving ownership without storing any identifiable information. This gives you privacy protection with minimal data retention.

This approach lets us verify wallet ownership without storing any identifiable information, protecting users even if our database gets compromised.

Blockchain Interactions: Encrypted Storage

For blockchain operations like attestations, we actually need users' wallet addresses. Our solution gives users user-controlled encrypted storage with geographic choice, letting them pick where their data gets stored based on their privacy preferences and regulatory requirements. Users control their data sovereignty while getting the blockchain functionality they need.

We implement split encryption keys managed by the application runtime, so even if someone gets access to our storage systems, they can't decrypt your wallet addresses without the application's encryption keys. The keys get split into multiple pieces and managed separately from the encrypted data, creating multiple layers of protection.

Storage isolation prevents direct access to plaintext addresses, even by our own engineers or during a security breach. The encrypted data gets stored separately from the encryption keys, and the application runtime manages decryption only when needed for blockchain operations. This ensures compliance with data protection regulations while maintaining blockchain functionality.

How We Actually Built This

Our dual-model approach requires careful architectural decisions that balance privacy protection with blockchain functionality. The authentication flow starts when users sign a message with their wallet, proving ownership and control of the private key. Our application hashes users' wallet addresses using strong cryptographic methods before storing only the hash in our database. For future logins, we verify wallet ownership by checking the signature against the stored hash, never needing to see the actual address.

The blockchain flow works differently, requiring the actual wallet address for operations like attestations. When users consent to address storage for blockchain operations, we encrypt the address using split keys and store the encrypted data where they choose. The application runtime manages decryption only when needed for blockchain operations, ensuring the plaintext address never gets stored or accessed outside the runtime environment.

Why This Matters

Regulatory Compliance

This approach addresses regulatory concerns that matter for blockchain applications. Compliance with privacy regulations happens through user-controlled data location, letting users choose where their data gets stored based on their geographic location and privacy preferences. Users control their data sovereignty while helping applications meet regulatory requirements.

We follow minimal data collection principles, only storing what's absolutely necessary for the specific use case. For authentication, we store nothing identifiable. For blockchain operations, we store only the encrypted wallet address and let you delete source data while preserving blockchain functionality through cryptographic proofs.

The right to deletion gets preserved while maintaining blockchain functionality. Users can delete their source data (like passport information) while still being able to claim attestations later, because attestations are based on cryptographic proofs rather than the original documents. This creates a privacy feature that traditional applications can't offer.

Transparent data handling practices are built into our architecture. Users can see exactly what data gets collected, why it's collected, and where it's stored. This transparency builds trust and ensures compliance with privacy regulations that require clear communication about data practices.

User Trust and Adoption

Many users value privacy and want control over their data. Our approach provides transparency about privacy practices, showing users how their data gets protected and giving them control over their information. This transparency helps build trust with users.

We enable selective data sharing, letting users choose what information they share and for what purposes. This control can help build user confidence, especially when dealing with sensitive financial information that can be linked to real identities.

Our system preserves blockchain functionality while providing privacy controls. Users can participate in blockchain operations like attestations while maintaining control over their personal information. This balance can help with user adoption of Web3 applications.

The approach supports regulatory compliance requirements, helping organizations adopt blockchain technology while meeting their legal obligations. This is important as regulations around digital identity and privacy continue to develop.

What Engineers Should Actually Do

Alright, developers—here's what you need to stop doing and start doing instead:

Design Principles

First, stop treating authentication and blockchain operations the same way. They're completely different beasts that need different approaches. For authentication, developers should store a strong hash of the wallet address—not the actual address—to maintain server-side state while proving the user controls it. For blockchain operations, developers might need the actual address, but should encrypt it properly.

Here's a key insight: you can design your app to simply reverify wallet control when needed using Sign-In with Ethereum (SIWE) or similar protocols. When you need the wallet address for a blockchain operation, have the user sign a message proving control, verify the signature matches the address, check that the address hash matches what you already know, use the address for the operation, and then discard it—never storing the plaintext address. This approach gives you the functionality you need without the privacy risks of permanent storage.

Get user consent right. Explain clearly what data the application is collecting and why. Users need to understand the difference between "I'm just proving I own this wallet" and "I'm storing your wallet address for blockchain stuff." This transparency builds trust and keeps developers out of regulatory trouble.

Give users control over where their data gets stored. Different people have different privacy preferences and regulatory requirements. Let them choose the storage location that works for them.

Enable data deletion while keeping blockchain functionality. Users should be able to delete their source data (like passport scans) while still being able to use their blockchain attestations later. The proofs are based on cryptography, not the original documents.

Security Considerations

Use proper hashing for authentication—and I mean proper. Don't use fast algorithms like MD5 or SHA-1 that are too easy to crack. Use purpose-built password hashing functions designed for this stuff. They're slower by design, making them much harder to brute-force. If the hash gets compromised, the original wallet address should be unrecoverable.

For stored addresses, implement split-key encryption. Divide your encryption keys into multiple pieces and manage them separately. This creates multiple layers of protection and makes it way harder for attackers to reconstruct the full key.

Keep your encryption keys isolated from your stored data. If someone gets access to your storage systems, they shouldn't automatically get access to the keys needed for decryption. This separation is crucial—it's what protects your data even during a storage system compromise.

Audit your privacy implementations regularly. Both automated testing and manual review by security experts. Your privacy controls are only as strong as their implementation, and regular audits help you catch problems before they become disasters.

What Users Should Actually Do

While developers need to build better systems, users also need to protect themselves. Here are some practical steps you can take right now:

Wallet Separation Strategy

Don't use the same wallet for everything. Create separate wallets for different purposes:

• Login Wallet: A dedicated wallet just for signing into dApps and services. Keep minimal funds here—just enough for gas fees if needed.
• Financial Wallet: Your main wallet for significant holdings, DeFi operations, and large transactions. Never use this for random dApp logins.
• Shopping Wallet: A separate wallet for NFT purchases, gaming, and other consumer activities. Fund it only when needed.

This separation means that even if one wallet gets doxed, your financial privacy isn't completely compromised. It's like having different email addresses for different purposes—basic operational security.

Account-Level Separation

Many modern wallets support multiple accounts or addresses within the same wallet. Use this feature to create different personas for different activities. Each account can have its own transaction history, making it harder to link your activities together.

Understanding Mixers

Mixers (also called tumblers) are privacy protocols that break the link between your wallet addresses and your identity by pooling transactions from multiple users. Here's how they work: you send your tokens to a mixer, they get mixed with tokens from other users, and then you receive the same amount back to a different address. The blockchain shows money going into the mixer and money coming out, but there's no clear connection between the input and output addresses.

Services like Tornado Cash on Ethereum or similar protocols on other chains can help protect your privacy for significant transactions. The mixer essentially creates a "break" in your transaction history, making it much harder for someone to trace your financial activity back to your real identity. Just remember that while mixers can help with privacy, they're not perfect—and in some jurisdictions, using them might attract regulatory attention.

Smart Contract Interactions

Be careful about which smart contracts you interact with. Some contracts can reveal more information about you than you realize. Before connecting your wallet to any dApp, ask yourself:

• Do I trust this application with my transaction history?
• Is this interaction worth potentially linking my wallet to my identity?
• Could this contract reveal patterns about my financial behavior?

Regular Privacy Audits

Periodically review your blockchain activity. Look at your transaction history from the perspective of someone trying to learn about you. What patterns emerge? What could someone learn about your income, spending habits, or interests? If the answer concerns you, it might be time to create new wallets or use privacy tools.

The Bottom Line

Wallet addresses are pseudonymous until they're not. The moment someone links your wallet to your real identity, your entire blockchain history becomes public. That's not just a privacy violation—it's a complete breakdown of what makes blockchain valuable.

The common practice among applications that store wallet addresses—treating them like usernames—is lazy and dangerous. It creates single points of failure where a database breach can expose someone's entire financial life. And when regulation forces companies to collect even more personal data, the risks get worse, not better.

But it doesn't have to be this way. We can build systems that protect privacy while enabling blockchain functionality. Engineers can implement proper hashing for authentication and encrypted storage for blockchain operations. Users can practice wallet separation and use privacy tools. And companies can give users control over their data while maintaining the cryptographic proofs that make blockchain useful.

At Zipwire, we've built this approach into our platform. We let users delete their personal details while keeping their blockchain attestations. We use hashing for authentication and encryption for blockchain operations. We give users geographic control over their data storage. And we're committed to sharing what we've learned.

The Web3 ecosystem needs applications that users can trust with their digital identities. That means treating wallet privacy as a fundamental requirement, not an afterthought. The technology exists to do this right. The question is whether we're willing to put in the work.

For developers and organizations interested in implementing these privacy controls, you can learn more about our blockchain attestation implementation, privacy architecture, and security framework through our technical documentation. We're also seeking partnerships with organizations that share our commitment to privacy-first blockchain development.

---

Learn more