Recognising a Returning User Without Making Them Trackable, and the Day It Resets

Two requirements that look opposed

A business needs to recognise a returning customer. Not necessarily to know who they are, but to know this is the same account holder as last time: to enforce a limit, to detect an obvious abuse pattern, to carry a standing over from a previous interaction.

A person needs not to be trackable across every business they deal with. The moment the same identifier appears at a bank, a marketplace and a gaming site, those three can compare notes and assemble a picture none of them was given.

Presented as a tradeoff, one of these loses. They are not actually a tradeoff.

The resolution, which is older than this company

One identifier per relationship.

The user presents a different identifier to every verifier. At any single verifier, it is stable forever, so recognition works exactly as it would with a permanent account identifier. Across verifiers, there is nothing in common, so comparing notes yields nothing.

Recognition is a within-relationship property. Tracking is an across-relationship property. Separating them is the whole idea, and it is a pattern the decentralised-identity community developed years before we existed.

Why ours is derived rather than stored

The identifier for each verifier is computed from the wallet's existing key material, with the verifier's identity mixed in so that each one produces a different result.

That choice has consequences worth stating. There is no list of pseudonyms to store, so there is no list to leak, to back up, or to lose. The identifier regenerates from the wallet whenever it is needed, and it is the same one every time.

And it is never written to the chain. It resolves to nothing on the public ledger, deliberately, because publishing a per-relationship identifier would recreate the exact correlation surface the design exists to remove. A public record of every pseudonym would be worse than having no pseudonyms at all.

What it proves, and the part most pages would leave out

It proves that this is a returning controller of the same key, who also holds a valid credential.

It does not cryptographically prove that they are the same credentialed person. The pseudonym is bound to the wallet's key material rather than to the credential itself, so the link between "same pseudonym" and "same verified individual" rests on the wallet rather than on the mathematics.

For most commercial purposes that distinction does not change a decision. For a high-assurance one it might, and a buyer should know which of the two they are getting.

The stronger construction, binding the pseudonym to the credential, is designed and not built. It is deferred for a reason worth being explicit about: it would mean putting draft cryptography into a production wallet before our own BBS+ implementation has been audited.

The failure mode to design around

Social recovery rotates the wallet's root key, and every derived identifier is severed with it.

If a user loses their device and recovers through their guardians, the wallet works again and the identity is intact, but every pseudonym derives differently afterwards. To every verifier they had a relationship with, that user is now a stranger.

The consequences are concrete. Any standing attached to the pseudonym is gone. Limits reset. A returning-customer path becomes a new-customer path. Whatever reputation had accumulated in that relationship is not transferred, because the thing it was attached to no longer regenerates.

That is a real cost and it is inherent to deriving identifiers from a key you can rotate. We would rather write it here than have a business discover it the first time a customer recovers a wallet.

If you are building on this, treat pseudonym continuity as best-effort and keep anything you cannot afford to lose attached to something else.

What to ask any vendor offering per-relationship identifiers

"Is the pseudonym stored or derived?" Stored means a database of pseudonyms exists somewhere, and you should ask who holds it. Derived means it regenerates, and you should ask what happens when the key changes.

"Is it published anywhere?" If per-relationship identifiers appear on a public ledger, the privacy property has been undone by the transparency of the ledger.

"Is it bound to the key or to the credential?" This is the question above, and the answer determines whether recognition is a claim about a device or about a person.

"What happens on account recovery?" Ask it precisely. In our case, every relationship resets, and a vendor who says nothing happens has either solved something hard or not thought about it.

Where this leaves a decision

If you need to recognise returning users without becoming part of a tracking network, the mechanism exists, it shipped, and it works within a relationship exactly as a stable account identifier would.

If you need recognition that survives a user recovering their wallet, this does not provide it today, the stronger version is designed rather than built, and the reason it is not built is one we would rather explain than skip.