"Anonymous or fully disclosed?" is the wrong question

Most conversations about privacy on the internet collapse into exactly that question, anonymous or fully disclosed: either the user is anonymous, with no trace and no accountability, or they hand over everything, name, date of birth, a passport scan, stored on someone else's server forever.

Leadership teams building anything that needs to know something true about a user, whether they're an adult, whether they're a real human, whether they're who they claim, pick one of those two knobs, because those are the only two most people have seen in production. Neither actually holds up. But that's not the failure we want to start with.

Anonymity doesn't work either

On July 14, 2026, security researcher Paul Moore published another proof of concept bypassing the EU's age-verification app, version 2026.07-1, using nothing more exotic than a Chrome extension. His conclusion, after three months of genuine security hardening still failed to close the gap:

Anonymous age verification doesn't work.

This isn't a story about sloppy engineering. It's a story about an architecture that can't be patched into working. When a verification system is anonymous, nothing binds the "verified: true" signal to the actual event of a real check happening, no identity, no persistent thread, no accountable party. The signal is just a bit on a wire, and if nothing ties that bit to a specific, attributable ceremony, forging it is always possible, no matter how much you harden the check around it. You can raise the cost of the bypass. You cannot make it architecturally impossible, because anonymity is precisely the absence of the thing that would make it impossible: a way to hold the signal accountable to a person.

Full disclosure fails the mirror-image way: it hands over too much, creating a standing liability, in exchange for the accountability anonymity can't provide. Both ends of the binary are failing at the same job from opposite directions.

Pseudonymity

Between "no persistent identity" and "full identity, always" sits a third option that gets far less airtime, the option nobody names: pseudonymity, a persistent, consistent identifier that lets a system recognise "this is the same verified party as before," without ever revealing who that party is.

This isn't a compromise between the two extremes, it's a different property. Anonymity and full disclosure both answer "how much does the system know about you." Pseudonymity answers a different question: can the system prove something about you is real and attributable, without learning who you are to do it. Once that's a separate axis, "anonymous or disclosed" stops being the only choice.

What pseudonymity buys that anonymity structurally cannot:

• A verification result can be bound to a specific event. Tied to a persistent, cryptographically verifiable identifier, a forged "verified: true" has no legitimate ceremony to point back to. No browser extension trick manufactures a real, attributable proof out of nothing.

• Bad actors can be held accountable without exposing everyone else. A platform can recognize a returning bad actor and rate-limit or revoke them without ever knowing their name.

• Disclosure becomes a deliberate, auditable event, not a default state. When identity genuinely needs to surface, that disclosure can be a specific, logged, consent-aware act, rather than baked into the system from day one because full disclosure was the only way anyone knew to get accountability.

Our design decision to avoid anonymity

This is the actual design decision behind Leagle.id, made deliberately, not by default.

Every holder gets one verified passport, a real biometric and document check, done once. A platform then requests only whichever proof it actually needs:

• A bot-check or login request discloses only a persistent, pseudonymous Holder ID: enough to recognise "the same verified human as last time," never enough to learn who that human is.

• An age-check request discloses a boolean claim, "older than eighteen," never the underlying date of birth. This is the exact category of check Paul Moore's POC targeted, and it's structurally different from an anonymous check: the claim is bound to a persistent, passkey-verified credential, not a client-side signal an extension can intercept and replay.

• The KYC/money-handling level itself only discloses age, residency, and Holder ID, never identity. A platform obtains a holder's actual identity only by issuing an Identity Disclosure Request, a signed certificate stating the reason, and only once something warrants it: fraud, a dispute, a regulatory or legal request. Not as a routine part of onboarding. We relay that request, and the reason, to the holder at the same moment we release the data to the platform, a deliberate, logged act visible to the person it's about, not a silent default. A platform never ends up holding the identity of a customer who gave it no reason to.

Every level reuses the same passport. A platform doesn't integrate three vendors for three guarantees; it requests whichever proof it needs against one accountable identity, and nothing more.

The real choice

The EU age-verification bypass isn't an indictment of age verification. It's an indictment of building any verification on anonymity, then expecting hardening to eventually close a gap the architecture itself keeps open. The fix was never "harder to bypass." It's a different foundation: an identifier persistent enough to be held accountable, and private enough that being held accountable never means being exposed.

That's pseudonymity. Not a midpoint between anonymous and fully-disclosed, but a different question entirely, and once leadership teams see it as an option rather than a compromise, "we have to choose" stops being true.