Learn
Privacy
What identifier hashing actually protects, what it does not, and which guarantees are properties rather than promises.
This page states the limits plainly. A protocol that hides its weakest point discovers it during an incident, in public, with a counterparty reading over its shoulder.
The three things kept apart
Most privacy failures in payment systems come from collapsing two of these into one.
| Layer | Question | Failure if merged |
|---|---|---|
| Authentication | Is this session the subject it claims to be? | A signed-in user is treated as a verified phone number |
| Identifiers | Does the subject demonstrably control this identifier? | An unverified number is indexed and someone else becomes reachable at it |
| Consent | Did the subject agree to this disclosure, to this counterparty? | Verified means findable, and nobody ever opted in |
PATH keeps them as three separate records, and a disclosure requires all three.
What a directory lookup returns
A lookup answers a routing question and gets a routing answer.
| Returned | Never returned |
|---|---|
| Which member holds the key | The account holder's name |
| That member's endpoint | Their institution's customer record |
| What the destination accepts | Their KYC tier or documents |
| Applicable limits | Their balance or history |
| A signature and a commitment | Any other identifier of theirs |
The line is not a matter of taste. Returning a profile to whoever holds a hash turns a routing lookup into a disclosure, and the hash was supposed to be the thing that made lookups safe.
Identifier hashing: what it does
Identifiers are normalised, then hashed with a network-held secret (a pepper) using Argon2id. The directory stores hashes; it never stores the identifier.
What that protects: the database at rest. A stolen dump is not a phone book. Reversing it requires the pepper, which is not in the dump.
What it does not protect: identifiers from the operator that computes the hash. The pepper is server-side, so a member sends the identifier in the clear and the operator sees it in order to hash it. There is no way around that in this configuration, and describing it as "zero knowledge" would be false.
Until oblivious hashing ships, the honest statement is: the hash protects the database, not the network's members from the network. No page on this site will say otherwise.
Why the pepper is not distributed
The obvious fix — give members the pepper so they can hash locally and send only the digest — is refused, permanently.
Phone numbers are a small, dense, fully enumerable space. With the pepper, anyone can compute the hash of every possible number offline and rebuild the entire directory in reverse. A secret shared with fifty members is not a secret; it needs to leak once, anywhere, and the exposure is retroactive and undetectable — no API call, so no budget, no log, no trace.
Argon2id instead of a bare hash raises the cost of that scenario from seconds to an afternoon of rented compute. That is a speed bump, not a defence, and it is worth doing only because it costs milliseconds per lookup and cannot be changed later without re-registering everyone.
The construction that does fix it
Oblivious hashing. Without the mathematics:
- 01BlindThe member blinds the identifierA random value of its own.
- 02SendIt sends the blinded valueTo the network.
- 03PepperThe network applies its pepperIt cannot see the identifier.
- 04UnblindThe member removes the blindingAnd holds the final hash.
The network sees nothing; the member never learns the pepper. Both problems close together. It is a known construction, deployed elsewhere — it is how a browser checks whether your password appears in a breach without sending your password — and it costs one round trip and a few milliseconds.
It is on the roadmap with an explicit trigger: before a second member joins a network. While one member holds everything, the network only sees its own customers and the exposure is theoretical. The second member makes it real, and that member will be the one to ask.
What a person can do
Choose a level per identifier. private keeps an identifier out of the directory entirely,
reachable only through an existing relationship. network is the default for an individual.
public is opt-in and, realistically, for merchants.
Withdraw completely. Withdrawal applies at the subject level and removes every identifier at once. Someone who opts out expects to disappear everywhere; a per-entry toggle that leaves them findable by email after they removed their phone number is a promise half kept, which is worse than none.
Rotate an address. Opaque addresses can be rotated without changing the underlying identity. The old one is revoked rather than deleted, so a payer holding a saved destination is told it moved rather than that it never existed.
What operators must do
Never persist the clear identifier. It is used to compute the hash and gone in the same request: not in a table, not in application logs, not in the search log.
Look up at the moment of intent. Sending an entire address book on install exposes every contact a user has, most of whom will never be paid. Looking a number up when someone actually wants to pay it reduces what the network sees by orders of magnitude, and costs nothing but a change of timing. This is the single highest-impact privacy measure in the protocol and it contains no cryptography.
Log searches, and keep the log short. With a declared retention, published rather than buried in a contract.
The load-bearing assumption
In the central configuration, the network could correlate. It holds the index, so it knows who each hash belongs to, and it sees each search. Crossing the two reconstructs a payment graph without ever seeing a payment: volumes between members, corridors, cycles.
The counterweights — short retention, a rulebook prohibition on commercial use, independent audit — are commitments, not properties. With a design where the network could not know, the question would not arise. Here it can, and undertakes not to.
That difference matters on exactly one day: when a competing institution decides whether to trust the operator. It makes the neutrality of whoever runs the network a load-bearing assumption of the model, and it is why the separation between the entity that writes the rules and the entity that operates the system is worth taking seriously long before anyone asks about it.
Next: Trust and signatures — why nearly everything is signed.