Stargate transforms email infrastructure from trust-dependent to trust-verified. Every message exchange between organizations resolves cryptographic identity, establishes policy consent, and creates an auditable trail — without adding workflow overhead or changing how end users work.
Book a 30-minute architecture walkthroughCurrent trust systems force organisations to depend on central authorities for every identity check and every data exchange. Vereign's architecture eliminates these dependencies by enabling each organisation to control its own cryptographic identity and verify others directly. This is how it works in practice, from key management to verified data exchange.
The 7-step sequence below is the path every Stargate-enabled message takes — from the moment your DNS client makes a query to the moment data arrives verified and audited at its destination.
When your application resolves a counterparty's domain (e.g., hospital-b.ch), the Stargate DNS Proxy intercepts the query before it reaches your upstream resolver. This is the entry point — no changes to application code required. The proxy operates transparently at the network layer.
The Identity Agent queries the counterparty's Stargate-published identity record. Two outcomes: the counterparty is Stargate-enabled (proceed with full cryptographic verification) or it is not (fall back to standard delivery, flagging the message as unverified). This is how Stargate achieves backward compatibility — it never blocks messages to non-Stargate counterparts.
If the counterparty is Stargate-enabled, a WireGuard VPN tunnel is established using keys derived from the DKMS identity records of both organizations. These keys are not issued by a central certificate authority — they are derived from each organization's own KERI key event log. The tunnel is bilateral: each party is authenticated to the other independently.
Before any data moves, Stargate's policy engine (Open Policy Agent, OPA) evaluates whether this data exchange is authorized under both parties' policies. For healthcare data, the FHIR Resolver checks resource-level consent: patient consent records, organizational authorizations, and sector-specific regulations (EHDS, Swiss DPA) are evaluated in real time. Data that is not authorized by policy does not move.
Your existing OAuth tokens and X.509 certificates remain valid. Stargate's compatibility bridge translates KERI-anchored credentials to JWT or X.509 format at the receiving end — locally, without contacting any external authority. Your identity infrastructure does not change. Stargate extends it to operate across organizational boundaries.
With policy consent confirmed and the encrypted WireGuard tunnel established, the data exchange proceeds. SEAL (Secure Evidence and Authenticity Layer) wraps every message with a verifiable authenticity layer — the receiving organization can prove who sent the data, when it was sent, and that it has not been modified in transit. This replaces S/MIME's dependency on third-party certificate authorities with bilateral DKMS-derived verification.
Every exchange creates an entry in KERI's Key Event Log (KEL) and Transaction Event Log (TEL). These logs are tamper-evident and independently verifiable by any party — not just by a central log server. For regulated sectors, this means cross-organizational audit trails that are cryptographically sound and available without centralized infrastructure. Your compliance team can verify any exchange independently, at any time.
Stargate's trust stack is designed in layers. Each layer does one thing well and hands off cleanly to the next. Existing infrastructure plugs into the compatibility layer — nothing is ripped out.
Stargate is not a replacement project. It is an extension of the infrastructure you already operate. The table below shows what you keep and what Stargate adds.
443 GDPR data breaches reported daily across Europe, with cumulative fines exceeding EUR 1.2 billion — DLA Piper GDPR Fines and Data Breach Survey
This is the right question. Three well-funded projects failed to deliver decentralised identity at scale:
KERI is structurally different. It has no blockchain dependency. Key events are anchored in append-only logs that each controller maintains independently — no shared ledger, no gas fees, no foundation governance required. The network does not need a central coordinator because trust is established bilaterally between parties, not validated by a shared global state.
The institutional validation: GLEIF — the Global Legal Entity Identifier Foundation — operates the global LEI system for financial institutions in 180 countries. GLEIF chose KERI for the vLEI (verifiable Legal Entity Identifier) system. This is not a proof-of-concept. It is production infrastructure verifying the identity of financial institutions globally. Stargate builds on the same KERI foundation that GLEIF validated at institutional scale.
See how verified trust infrastructure applies to your specific requirements and regulatory environment.
