How do our cryptographic invitation tokens work without tracking respondents?

If you want to know more about the technical details of this FAQ item, we have a deeper technical dive you can read This one here is the high-level version, lighter on the technicalese

How do invite tokens work without tracking me?

At Salary Confidential, we use invitation tokens to ensure that only invited participants can enter a survey peer group. We know that "tokens" can sometimes sound like "tracking codes," so we’ve designed our system using cryptography called VOPRF (Verifiable Oblivious Pseudorandom Functions) -- a very catchy name, to be sure. We implement it through a framework called Privacy Pass and it runs on our Cloudflare platform (along with everything else in Salary Confidential). Privacy Pass, and the underlying math we selected for our tokens, is the current state of the art for privacy-preserving credentials.

How it works: a three-party privacy model

To keep your identity safe, we split information across three parties so that no one person has the full picture:

The Requester (e.g., the owner of the survey): They know who they sent the invites to, but they cannot audit the tokens to see who has responded to suss out who is going to be in the final report

If a Requester wanted to check if Anna participated, they would have to take the token they gave her and try to use it themselves. But doing so 'burns' the token instantly. If Anna hadn't used it yet, she now can't, making auditing tokens during a live survey self-defeating. And when the survey is closed, there are no more ways to feed it tokens...

Requesters can only generate tokens for their own surveys, and a token is specific for a given survey: This means Requesters can't mint themselves tokens for other people's surveys; this also means that the only path to evaluating a token is the specific survey peer group for which it was minted.

Salary Confidential (The Platform): We host the "mint" that creates the invitation tokens. However, the minting of tokens is 'blind': we sign your token without ever seeing their final value. And our minting is 'stateless': we don't keep track of how many, or which, or when we make tokens for a given survey.

You can think of the tokens as invitations sealed with wax. All invitations use our base wax formula, which lets us recognize that the seal was made by our mint. But when a requester creates invitations for a specific survey, we mix a small additive into the wax that is unique to that survey.

This means the wax seals for one survey have a slightly different chemical signature than the seals for another. When someone presents a token, we can check both that the wax follows our general formula and that the additive matches the specific survey it was minted for.

Each seal still has its own tiny natural variations in the wax (the cryptography itself introduces this variance, we don't control it), so every token remains unique even within the same survey. When the seal is melted during redemption, it will also produce a unique chemical signature.

You (The Respondent): You hold the only key that can "unblind" the token. When you submit information to a survey, you present this token to prove you were invited. The token is specific to a given survey peer group, so you can only participate with your token to that survey, and, once the token is used to submit one data set, it will no longer work

One token, one participation

The primary goal of our tokens is to protect the integrity of the peer group relative to who the requester intends to invite: even if a survey link is shared publicly, only the specific group selected by the requester can participate, since you need a one-time use token to submit a response

When you submit a response, we check two things:

1. Is it valid? Does it mathematically match the keys for this specific survey?

2. Is it 'spent'? To do this, we burn your token and look at the mathematical output of the burn. We check a ledger to see if we have already recorded that this same hash was seen by us. If we have a record of such a burnt hash, the token was used and we don't allow a new submission based on this token coming back. If we've never seen this particular mathematical burnt signature, we store it in our ledger (so the underlying token won't be re-usable after this) and we allow the respondent to deposit their data submission to the survey.

Why storing a hash of burnt token is safer than recording tokens presented for submission

What we store as a way to guarantee a token is used only once, is a mathematical hash -- a 'digital smudge' -- of your burnt token. This smudge is enough for us to recognize it if the same token shows up again (because it will have the same smudge), but it’s impossible to turn that smudge back into the original token: this is a key rule of all one-way cryptographic functions that allow a system to confirm that something is valid without ever being able to reconstruct the original value it came from. This means that if a requester asked Salary Confidential "I once issued token 123, can you tell me whether it was redeemed?" we actually would never be able to respond, and not just it would break our privacy model. Crucially, we just cannot respond technically to such a request: Our ledger of burnt tokens has no record of "token 123" which is how the Requester knows its tokens. We're storing something totally different.

If you need an analogy, you can think of invitations sealed with wax. The real unique signature is in the wax seal itself — and we can’t see it directly. When someone comes in and presents a token, we can check that the wax formula cryptographically matches the kind of seals we produce in our mint, and that the additive in the wax matches the survey for which it’s presented.

We then briefly melt the wax seal and keep only a tiny smear of the melted wax. The heat changes it permanently, but that melted wax still has its own unique signature. We keep a sample of that residue for later comparison when other seals are presented.

At no point can we say "we recognize the invitation." We never recognize the seal itself — only that it follows the formula of seals we make, and that its unique melted-wax signature hasn’t been seen before. And we couldn't recognize the seal anyway: we made them in the dark, didn’t keep track of them, and never saw them leave our mint.

So while a requester may know which sealed invitation (token) they handed to someone, Salary Confidential only ever sees two things: whether the wax formula is valid for our mint and the survey context, and whether we’ve already seen the melted-wax signature from that seal before. If we have, it means someone has already used that token to submit a response, so we will not accept it again. Meanwhile, the requester never sees the melted wax — we perform the melt, and they never see the residue.

So then, if the token is valid and hasn't been used, we accept your response and give you your respondent Results Key to view results later. If the hash is already in our ledger, we reject the submission -- it means this token was used. This ensures "one token, one response" without ever knowing who that person is.

What about 'Fingerprinting'?

'Fingerprinting' is a technique where websites collect small details — like your IP address, browser type, or time of day — to build a more detailed picture of who their users are.

We do NOT fingerprint token redemptions. When a token is burnt in our ledger, we don’t record your IP address, browser information, or timestamp. We simply see that a valid token is being presented to be allowed to submit a response, and that we don’t already have a matching burn hash in our ledger (which would indicate this token has been used for redemption before) We learn nothing about who walked in the door with this token - we don't look at the user at all - we're only interested in evaluating the token, and whether we have an existing burnt hash with the same signature. That's it

We do fingerprint the responses themselves. To prevent fraud, we store an IP address and timestamp alongside the response data itself. This is a technically separate part of the process, and this information lives in a completely different part of the system.

If an analogy helps:

You can think of the token redemption and data submission as taking place in entirely separate rooms of our factory.

In order to be admitted into Room 2 where data submission takes place, we verify in Room 1 that you have a valid, unused token.

In Room 1, you stay in the dark as a person and push through the sealed invitation to someone who never sees you and whose job it is to evaluate whether this is one of our wax seals, whether it's valid for this survey and if so, will melt a small portion of the wax where we take that unique transformed sample and compare it against all the samples we already have so we know whether it's the first time we're seeing this specific seal or not.

If we don't have a record of this seal being used before, we keep our small melted wax sample (so no one can use the same enveloppe to get in) and allow you to proceed into Room 2. But the people of Room 1 never saw you come in and they don't see you head into Room 2 either. All of this happens with no notion of the time of day, and the melted wax sample is tossed randomly in a pile of other used samples for all future comparisons.

In Room 2, you are now seen and you submit your survey response. We store some technical information about that submission to protect the platform - your IP and the time at which you are sharing this data submission. No one in this room knows anything about the token you presented to get in Room 1 - that's not their job, 100 percent of the people who are allowed in Room 2 have been verified elsewhere to be allowed to get there, so they don't need to rehash that (ha! get it?)

Because those two rooms never use any of the same information, there is no mathematical bridge that allows us to connect a person’s identity to their specific salary data. If someone from Room 2 said "I just got a submission record from someone with this IP, can you tell me what is the melted wax hash of the seal they used", all that Room 1 would be able to say is "The only thing we've ever known about anything is the melted wax samples we extract from seals. We never see the users when they hand over their tokens for analysis, or their IP; and we don't keep track of time in this room. Our pile of melted wax samples is from all times, mixed randomly, I have no way of telling you anything more"

Unused tokens can't be audited once the survey closes

Finally, once a survey peer group is closed, all outstanding tokens become mathematically useless. They can’t be audited because the only consuming device that would speak on validity and use was the survey submission process and it's gone; unused tokens can’t be used for other surveys (they won't be valid). In other words, once a survey closes, all its unused tokens effectively vanish.