Avoid signups from used addresses

Because the user’s transaction history across dapps shouldn’t be public

Data on the blockchain may persist forever, and it will be trivial to tie user-operated addresses to user identities. Make it hard for the user to accidentally compromise his privacy.

Early in your dapp’s onboarding process, check whether the public address that the user is signing up with has been used before.

If signing up is free for the user

If your signup uses an off-chain signature validation or you’re going to cover the costs of storing the user’s data on the blockchain, you should ask her to switch to a new address to perform the signup.

Signing up for CryptoKitties is free and done off-chain. They ask the user’s web3 provider to sign a message to prove it has the private key to his publicly-exposed Ethereum address.

In this case, CryptoKitties should check if the address 0xfdff… has been used for other individual transactions. If so, it should require the user to sign up using a different one, giving examples of the data correlations that would be exposed.

If the user needs to cover signup costs

When the user needs an address with funds to store some signup data on the blockchain, your safest bet is to ask her to switch to a new address, have her fund it through an exchange, and finally come back to your dapp to complete the signup. Yes, this introduces a lot of friction, but is a necessity in dapps that store personal information.

Signing up for Bloom requires the user to complete a blockchain transaction from his web3 provider. Sensitive data is stored in this step, so you should ask for a fresh address funded by a source that can’t be easily tied to the user.

Issue specific warnings

It’s easy to issue a general warning about addresses and transaction histories being public.

But even with these cautions, the user will rarely stop to think about where he’s used his account before. A good way to get his attention is by exposing what is publicly known about the address he’s using.