Read v0.51 ↗
Foundation document · v0.51 · registered 12 May 2026

Verification is the default.
Identification is optional.

An open European protocol that lets anyone verify a call, message, or email comes from a registered source — without revealing who is behind it.

Read the foundation document → Open questions ⌗ 24
Verified credential · kpn.nl
§1 · the problem

Trust in everyday communication is failing — calmly and at scale.

€1.8B
European losses to voice-channel fraud in 2024.
↳ Europol IOCTA 2024¹
3.4×
AI-generated impersonation calls increased year-over-year.
↳ ENISA Threat Landscape 2025¹
71%
of Europeans answer fewer calls because of caller-uncertainty.
↳ BEREC consumer survey, Q3 2025¹
§2 · the principle
Pseudonymity by default.
Identification by choice.

Every registered source can be verified. None are forced to reveal who they are. The asymmetry is the protocol.

§3 · how it works

Five layers, governed by a foundation.

TARIDE protocol architecture
L1
Registration
Operators register against an eIDAS-aligned chain of trust. No personal data is required at this layer.
live · v0.51
L2
Verification
Resolvers verify a sender's registration in sub-500ms without revealing identity to the verifier.
in spec
L3
Reputation
Pseudonymous reputation accrues to registered credentials — never to natural persons.
open question
L4
Consent
Recipients control the disclosure ladder. Identification is granted, not extracted.
in spec
L5
Resolver
Lightweight client library for telecoms, MUAs, and messaging providers to integrate.
draft
§4 · why a foundation

Infrastructure, not a product.

TARIDE is governed as a multi-stakeholder foundation rather than incorporated as a commercial entity. Trust infrastructure cannot be subject to acquisition, equity dilution, or unilateral pivot.

The foundation board is composed of telecom representatives, security researchers, privacy advocates, and a European public-interest seat. No commercial entity holds a majority. The protocol is released under CC BY 4.0; the reference implementation under Apache 2.0.

Precedents we acknowledge — and do not imitate — include Mozilla, Signal Foundation, Let's Encrypt, and Ecosia.

§5 · where we stand

Pre-specification, post-vision.

Phase Deliverable Detail Status
Q2·26Foundation registeredDutch stichting; statutes filed with Kamer van Koophandel; board seated.✓ done
Q2·26Foundation document v0.51Vision, principles, governance. Open for critical feedback through Q3.✓ done
Q3·26Technical spec v0.6Resolver protocol, credential format, attestation chain.in progress
Q4·26Reference resolverApache 2.0 implementation, Go + Rust bindings, eIDAS test harness.next
Q1·27First operator pilotOne Dutch telecom, one Dutch ISP, one European messaging provider.later
Q2·27v1.0 spec freezeAfter two pilots, the spec freezes for two years before any breaking change.later
§6 · what we ask

Differentiated by audience. One short brief each.

Telecom operators
Read the integration sketch. Tell us where it breaks.
Pilot opportunity for two operators in 2027. Pre-spec feedback shapes the resolver surface.
Telecom brief · 8 pages →
Security researchers
Attack the threat model. We have it written down.
v0.51 §4 details the threat model and the open questions we expect adversarial review on.
Security brief · 12 pages →
Privacy & DID/SSI community
Tell us where pseudonymity is leaky.
We want this critiqued by people who have lived through W3C-DID and ID Wallet rollouts.
Privacy brief · 6 pages →
EU policy stakeholders
Comment on eIDAS 2.0 / EBSI alignment.
We need this calibrated against the implementing regulations as they actually land.
Policy brief · 4 pages →
App developers
Look at the resolver API. Squint at it.
Pre-spec API sketch — your integration shape determines whether the protocol is real.
Developer brief · 10 pages →
Journalists & informed public
Read the 2-page summary.
Plain-language; quotable principles; numbers cited. Nothing speculative.
Summary · 2 pages →