A network for verified age, not verified identity

Proof,
in confidence.

Sigilo is a privacy-preserving age verification network. We let users prove they're old enough to use a site without revealing their identity, date of birth, or document — to the site, to us, or to anyone else.

Request access → Read the threat model
sigilo noun /siˈxilo/ Spanish, Portuguese — secrecy; the practice of keeping a matter unspoken or unrevealed; the discretion of one entrusted with another's confidence. From Latin sigillum, "a small seal."
Built on open standards
W3C Verifiable Credentials · OpenID4VP · ISO/IEC 18013-5 · eIDAS 2.0
§ 01

The current way is backwards.

Existing vendors collect government IDs and biometrics, then return a yes-or-no answer. The honeypot is enormous. The privacy harm is structural. We built the inverse.

Existing IDV vendors

User uploads ID. Vendor keeps it.

  • Vendor accumulates millions of government IDs
  • Each ID is linked to which adult, gambling, or dating site requested it
  • Biometric retention spans one to three years
  • Subpoena, breach, and policy-shift risk all live in one place
  • 40–70% user abandonment at the ID upload step
Sigilo network

User proves a predicate. Nobody collects anything.

  • The website receives one boolean: over_18: true
  • The issuer signs once at onboarding, never sees the site
  • Two presentations of the same credential are cryptographically unlinkable
  • Sigilo is not in the verification path — we hold nothing to leak
  • One tap. 3-second median verification time
§ 02

How it works.

A three-party protocol. Each party sees only their slice. No party — including Sigilo — can reconstruct the whole.

i.

Onboard once, with an issuer you already trust.

The user verifies their age once, with a bank, mobile carrier, government wallet, or accredited identity provider. The issuer signs a verifiable credential bound to the user's device.

Issuers · tier 1
Government mDLs (ISO 18013-5), EUDI Wallet, passport NFC reads

Issuers · tier 2
Regulated banks, MNOs, accredited IDV providers
ii.

The credential lives in a wallet on the user's device.

Bound to the device's secure enclave. Never exported. The user can hold one credential and use it across every site in the network — no re-verification, no re-upload of ID.

Storage
Apple Secure Enclave, Android StrongBox

Wallets
Sigilo app · Apple Wallet · Google Wallet · EUDI Wallet
iii.

When a website asks, the wallet proves the predicate.

A zero-knowledge proof asserts dateOfBirth ≤ today − 18y. The website verifies the proof. It learns nothing else — not the date of birth, not the issuer, not a user identifier, not anything correlatable across visits.

Proof scheme
BBS+ over W3C VC with selective disclosure

Unlinkability
Fresh randomised presentation each time
0
Identity records held
Sigilo is not in the verification path. We have nothing to leak, nothing to hand over.
3s
Median verification
Onboarding: two minutes, once. Every subsequent check across the network: one tap.
15+
Jurisdictions in scope
UK Online Safety Act, EU DSA, Texas HB 1181, Louisiana Act 440, and growing.
∞
Cross-site presentations
Cryptographically unlinkable. Two visits to two sites cannot be correlated by anyone.
§ 03

Verifiable from day one.

Trust is not a marketing word. Our relying-party SDK is open source. Every release is built and signed by GitHub Actions, recorded in a public transparency log, and verified by npm before it reaches your installer. Anyone can audit what we ship against the source we published.

↗
Source
github.com/sigilo‑id/verify
Public · Apache 2.0

Full SDK source, threat model, security policy, CI workflows. Static analysis runs on every commit. Issues and security disclosures handled in the open.

View repository →
 ↗
Package
@sigilo/verify
v0.0.2 · Provenance verified

One install command. Zero runtime dependencies. TypeScript-first, ESM-only. The green checkmark on npm links the published artifact to the exact commit that produced it.

View on npm →
 ↗
Build
Signed by GitHub Actions
SLSA v1 · Sigstore inclusion proof

Every release is built by a workflow whose identity is signed by Sigstore at publish time. Inspect the workflow run, the commit it built, and the attestation it produced — all timestamped to a public transparency log.

View workflow run →
§
Verify it yourself. Run npm install @sigilo/verify then npm audit signatures. npm will fetch the signed attestation, verify it against the Sigstore root of trust, and confirm the package came from this exact commit in this exact workflow run. No tokens. No trust required.
§ 04

One line of code. Production grade.

Built for developers. Audited for regulators. Drops into your existing checkout, signup, or gating flow.

SDKs for every surface.

Web, iOS, Android, React Native, Unity, and a server-side proof verifier. OpenID4VP-conformant — your existing wallet plumbing works out of the box.

The relying-party SDK is open source. The cryptography is open source. The threat model is published. The audit reports are public.

View the docs→ 
// drop-in widget — one line on the page
import { Sigilo } from '@sigilo/verify';

const sigilo = new Sigilo({
  publishableKey: 'pk_live_4kZ...',
  predicate: 'over_18',
  assurance: 'high',
});

const { verified, proofId } = await sigilo.verify();

if (verified) {
  // proceed — you received a boolean,
  // no PII, no biometrics, no ID image
}
§ 05

The hard questions, answered.

If you're a head of trust, a regulator, or a cryptographer, these are the questions you should ask. They are the ones we ask ourselves.

What does the relying party actually see?
A signed cryptographic proof of the requested predicate, a proof identifier for audit, and the assurance tier. No user identifier. No issuer identifier. No date of birth, document number, name, or biometric. The same user verifying twice in succession produces two presentations that cannot be linked.
Could a state-level actor compel you to identify a user?
We architecturally cannot. Sigilo is not in the proof verification path — verification happens between the wallet and the relying party using public network keys. We do not see verifications, do not log presentations, and do not hold a database that could be queried. Issuers individually cannot link a presented proof to a user without breaking the underlying cryptographic assumptions. A multi-issuer federation prevents single-issuer compulsion.
What about a determined minor using a parent's device?
No age verification system is truly foolproof against this. We are honest about it. Sigilo defends with hardware-bound keys requiring on-device biometric unlock at presentation, passive liveness checks for higher-risk relying parties, behavioural device-binding signals processed locally, and periodic re-anchoring against the original issuer. This raises the bar substantially above current solutions while remaining compatible with regulatory "highly effective" thresholds.
Why should a regulator accept this?
Because data minimisation is the law in every jurisdiction that has written one. The UK Online Safety Act, EU eIDAS 2.0, and California's CCPA all require that the data collected for a purpose be limited to what is necessary. Sigilo collects nothing at the relying party — by design, not by promise. We are pursuing recognition by Ofcom and conformance under eIDAS 2.0 implementing acts.

Compliance shouldn't
cost your users their privacy.

Talk to us about your verification volume, your regulator, and your timeline.

partners@sigilo.id → Developer docs