Spend a minute thinking about the last "verified" badge you trusted. A blue check on a profile. A green padlock. A "✓ verified email" pill in a settings page. Each one is doing the same quiet thing: it's asking you to trust whoever runs the system. The badge doesn't mean a fact was independently established — it means a company decided to display the badge. Pull the company, and the badge means nothing. There is always an owner of the check.

That ownership is the part worth questioning. Not because companies are untrustworthy, but because centralizing the judgment of "is this real?" centralizes a lot of power, a lot of liability, and a single point of failure. The verifier sees everything — your email, your phone number, your documents — and you have to trust both their honesty and their security. When the verifier is gone, captured, or breached, every badge it issued goes with it.

So here's the design question that started this whole thread of work: could a green check have no owner at all? Could independent peers, none of whom is "the authority", collectively verify something about you and issue a credential that says a third party checked this — without any of them learning the thing they checked? It turns out you can. The pieces are not exotic; they're just usually wired up to centralize, and you have to deliberately wire them not to.

flowchart LR
  Y[you] --> P[random panel of peers]
  P --> C[group co-signed credential]
  C --> V[anyone can verify]

What we're actually building

The unit is a small cooperative — call it a verification group — that anyone can stand up. Its members run verification services: one peer can verify email ownership, another phone numbers, others handle social-account control, domain ownership, even age. None of them is in charge. The group is the authority, and the group is just its members, chosen freshly for each request.

When you want to prove "this email is mine" or "I control this domain", you don't ask one trusted server. You ask the group, and the group runs a ceremony:

1. A small panel of verifiers is selected — randomly, per request — from the eligible members.
2. The panel runs the actual check (you prove control of the email/phone/account/domain).
3. The panel members each independently reach a verdict, commit to it secretly, then reveal — so no one can see how others voted before voting.
4. If they agree, they co-sign a credential together. The signature isn't from any single peer; it's a group signature that only forms when enough of them participate.
5. You walk away holding a credential that says "a third party verified this attribute" — and you can show it to anyone, who can check the group's signature mathematically, with no call back to any server.

The green check is real, and nobody owns it. Let's take the load-bearing parts one at a time.

Threshold signatures: a signature with no single signer

The heart of "nobody owns it" is the co-signature. We use a threshold signing scheme (FROST), and the property that matters is this: the group has one public key, but no single member holds the private key for it. The key is split. To produce a valid signature, some threshold of members — say, any 3 of 5 — must each contribute a partial signature, which combine into one ordinary signature under the group's public key.

To a verifier checking the credential later, it looks like a normal signature from one identity: the group. But producing it required a quorum of real, independent participants to agree. No member can forge the group's signature alone. Compromise one peer and you've compromised nothing — you still can't sign. That is what makes the green check owner-less: the authority is mathematically distributed, not just organizationally distributed.

Fellow travelers. We're far from the only people who've reached for "verification without a single authority." BrightID tackles the harder, adjacent problem of proving you're a unique human through a social graph rather than documents — a genuinely different and ambitious cut at the same fear (one entity owning everyone's identity). We took the spirit — distribute the judgment — and chose a narrower, more legible target: verify a specific attribute (this email, this domain) with a co-signed credential, rather than score personhood globally. And KERI showed us how to make key authority self-certifying and witness-backed without a registry to phone home to; our group public key leans on the same instinct — the credential carries its own proof, and verification needs no live lookup. We learned from both; where we diverge is scope, and the reasons are our own constraints (local-first, narrow claims), not their shortcomings.

Sortition: why the panel is chosen, not volunteered

If the same friendly peers always verified each other, the green check would be worthless — a clique rubber-stamping itself. So panels aren't volunteered for; they're drawn by lot. For each request, a deterministic-but-unpredictable draw selects which members verify, seeded so that you can't steer who gets picked and members can't reliably collude in advance because they don't know in advance who they'll be paired with.

This is sortition — the same idea as a randomly empaneled jury — and it's doing exactly the jury's job: making it expensive to fix the outcome. Combined with the secret-commit-then-reveal step (so panelists can't see each other's verdicts before committing), it raises the cost of a corrupt verification well above the value of a single fake badge.

Anti-collusion: making cheating not worth it

A distributed verifier has a distinctive failure mode: members quietly agreeing to vouch falsely. The defenses stack:

• Random panels mean you can't choose your accomplices.
• Blind commit-reveal means you can't coordinate verdicts in the moment.
• Reputation that degrades on bad behavior — repeatedly co-appearing with the same partner, or a pattern of disputed verdicts, costs you standing in the group. Get caught in enough bad calls and you fall below the bar to be drawn for panels at all.
• Disputes can be opened against a verdict, voted on, and resolved, with the cost landing on whoever was dishonest.

None of this makes collusion impossible — nothing does. It makes it expensive, detectable, and self-limiting, which for a badge that nobody owns is the honest goal.

Proving without revealing: the credential says "checked", not "the data"

Here's the part that surprises people. The credential you walk away with does not have to contain your email address, your phone number, or your birthday. It can simply assert the outcome: "a third party verified that this person controls an email at this domain", or "this person is an adult", signed by the group.

Two techniques make this real:

• Zero-knowledge proofs. For email, the strongest path proves ownership mathematically without the verifier ever seeing the address. Your device fetches a real, cryptographically-signed message from your provider and produces a proof that says, in effect, "a message signed by this provider was addressed to me and contained the group's challenge" — and the panel checks the proof, not the message. The plaintext never leaves your device. This rides on a general proof-verification layer in the group: the panel verifies a submitted proof (the heavy proving happens client-side), and because proof-checking is deterministic, every panelist reaches the identical verdict.
• Selective disclosure. A single credential can be issued such that you later reveal only the field you need. Age is the cleanest example: the credential carries a range — "adult" / "minor" — not your date of birth. A feature that needs to gate minors can check the credential without ever learning when you were born.

The thread tying these together is one of our core commitments: be honest about what's verified, and reveal nothing beyond it. A self-declared field and a third-party-verified field must look different to anyone reading them — but "third-party-verified" must not become "third-party-knows-everything-about-you". The green check proves a check happened; it is not a data leak.

How much of this is real, and how much is design

We want to be precise here, because "we designed it" and "it runs" are different claims and conflating them would be exactly the dishonesty this system exists to prevent.

• Built and proven: the owner-less co-signature (real threshold signing, not a placeholder), random panel selection, blind commit-reveal, reputation degradation, and disputes are implemented with a substantial test suite. The verification expansion — many verification types (email, phone, domain, and a range of social-account checks), the zero-knowledge proof layer, and selective-disclosure credentials — reached a completed, celebrated state with its full test suite passing on the main branch in early April 2026.
• Built, with rough edges: the foundational group implementation is in active hardening. As of this writing its end-to-end browser suite was partial — most of the flow green, a handful of multi-peer discovery and provisioning checks still failing and under a fix design. We'd rather tell you "36 of 44 end-to-end checks were green and the rest had a plan" than show you a clean badge over a gap.
• In progress / design: age verification is implemented as a verification type and being wired into the features that need it. The most privacy-preserving email path (a zero-knowledge prover that runs entirely in your browser over a real provider-signed message) is designed and rides the general proof-verification layer that did land; a dedicated in-browser email prover is the part still ahead, not behind.

If you take one thing from this: the green check most of us trust every day is a logo's promise. The one described here is a math promise, produced by a group that, by construction, has no single owner — and it can prove that a third party checked something about you while learning as little as possible about you in the process. That's a harder thing to build. It's also, we think, the only kind of green check worth trusting.

Written by AI agents from real project logs; owned and edited by Mujo.