A wallet connection should prove ownership, not expose an identity

I use tokenized memberships and digital licenses, but I’m increasingly uncomfortable with the default proof of ownership: connect a wallet and hand a website a public address. On a public chain, that address can make transactions, contract interactions, balances, counterparties, and unrelated holdings discoverable through explorers, RPC providers, or indexers. It’s pseudonymous, but it is still a reusable financial profile—not just a yes/no membership proof.

Should wallets and dapps make selective-disclosure credentials or zero-knowledge ownership proofs the normal path? “Prove you hold this license” seems more appropriate than “here is everything associated with this address.” The trade-off is real: private proofs can complicate support, fraud prevention, recovery, and auditing, while address-based access is simple to build and explain. Would you accept extra setup for private proof of ownership, or do you prefer transparent wallet connections?

The address is a poor abstraction for identity, but it is an excellent lookup key. That convenience is exactly why developers reach for it. A private proof system needs to specify what happens when the user changes devices, loses keys, or has to prove the same entitlement to support without exposing the whole wallet.

I’d make selective disclosure the default, with an explicit escape hatch for operators who genuinely need more context. “Zero knowledge” is not magic, either: public inputs, RPC logs, analytics, and key handling can still leak useful metadata. The threat model has to include the surrounding infrastructure.

The product problem is onboarding. A wallet connection is one familiar action; a credential flow can become several unfamiliar actions before the user sees the content they wanted. I support private proofs, but the UX has to hide the cryptography rather than turn every membership check into a protocol tutorial.

I’d separate two questions: what the verifier needs to establish, and what the wallet happens to reveal. Ownership of a particular license does not logically require a transaction history. That seems like a strong default principle, even if implementation and evidence standards are still unsettled.

From the implementation side, an address check is cheap because the ecosystem already has connection and signature flows. A proof service means more moving parts, more failure modes, and another recovery story. That is not an argument against it, but someone has to own those failures at 2 a.m.

There’s also a social expectation problem. Many users click “connect” as if it means “let me in,” not “make my financial graph inspectable.” Consent screens should say what the site can learn, in plain language, before the connection becomes the norm.

I’m not convinced privacy should always win. Some communities may deliberately want visible provenance or an auditable membership history. The important distinction is informed choice: don’t call a transparent wallet connection the only neutral or frictionless option and bury the privacy-preserving route.

Recovery is the part that worries me. If the proof is detached from an address, support needs a reliable way to determine whether the claimant is entitled to restore access without collecting more personal data. That process can become an unofficial identity system unless it is designed very carefully.

“Connect wallet” is a remarkably successful button for something that can reveal a lot. We accepted the abstraction because it was convenient, then treated convenience as consent. A smaller claim should require a smaller disclosure. This feels like basic data minimization, not blockchain ideology.

I’d use the private proof for routine access and reserve transparent connections for advanced users who knowingly want them. Developers can start with the simpler path, but the default should not permanently encode every visitor’s address as their account identifier.