Verifiable trust between organisations — without central authority

Stargate is rolling out across Swiss healthcare through 2026, making institutional trust programmable, auditable, and free from single points of failure.

Discuss Stargate for your organisation — no commitment

Organisations depend on third parties to verify who they are communicating with — creating single points of failure in every trust chain. Stargate enables direct, bilateral verification between organisations, removing this dependency. Swiss healthcare chose Stargate to replace 25 years of legacy infrastructure — implementation is underway, already processing over 800,000 verified interactions monthly.

Read the HIN use case →

850+

gateways across Swiss healthcare

Seven capabilities. One platform.

Stargate provides a complete platform for organisations to establish, manage, and verify trust relationships — without depending on any central authority. Here are the seven capabilities that make this possible.

Trust between organizations at institutional scale requires authentic, sovereign data exchange. Stargate is being deployed as that layer in Swiss healthcare. Local systems integrate easily using standard protocols like OAuth.

FINMA reports a 30% increase in cyber attacks targeting Swiss financial institutions — FINMA

ENISA reports 4,875 significant cyber incidents across Europe, with phishing responsible for over 60% of initial attack vectors — ENISA

Organisation identity management

Each organisation controls its own cryptographic identity via DKMS (Decentralized Key Management System), built on KERI (Key Event Receipt Infrastructure). Identity events are tamper-evident and auditable without requiring a central registry or certificate authority. Organisations establish and revoke trust relationships bilaterally — no central coordinator required.

Certificate management and authority

Stargate includes a built-in certificate authority based on DKMS, allowing organisations to integrate internal and external trust relationships without depending on external CA infrastructure. Certificates are issued and managed within the platform, reducing external dependencies and the attack surface of third-party CA chains. Certificate lifecycle management is handled programmatically with full audit trails.

Verifiable credential issuance and verification

Stargate issues and verifies credentials in ACDC (Authentic Chained Data Container) format — a cryptographic chain of proof that links every credential to the identity that issued it. Credentials carry their own verification data, so verifying parties do not need to query a central registry at the time of verification. The chain of custody is maintained and auditable at every step.

Policy engine

Access control policies are defined with OPA (Open Policy Agent), making them programmable, version-controlled, and auditable. Policies can be updated without redeploying infrastructure, and every policy decision is logged. This supports granular, resource-level consent rather than coarse OAuth scopes.

Sovereign data exchange

SVDX (Sovereign Data Exchange) provides multi-path programmable routing for data between organisations. Routing decisions are policy-driven and auditable — data flows are governed, not assumed. Organisations retain sovereignty over which data leaves their environment and under what conditions.

Secure transport layer

All communication between nodes is encrypted with WireGuard — an open source, auditable transport protocol with a small code surface and strong security properties. Point-to-point connections are established between organisational nodes without routing through a central relay. WireGuard operates at the network layer, making the transport layer independent of application-level encryption.

Semantic interoperability

OCA (Overlays Capture Architecture) enables data format transformation at the semantic layer, so organisations with different internal data models can exchange structured information without losing meaning. OCA overlays describe how data should be interpreted, translated, and displayed — enabling interoperability between systems with different schemas without requiring a shared canonical model.

How Stargate works

Stargate architecture diagram showing concentric-ring mail exchange topology with verified sender, SEAL gateway, and recipient verification — Stargate mail exchange — verified communication between organizations

Stargate architecture diagram showing concentric-ring structured data exchange with sovereign routing and policy engine — Stargate structured data exchange — sovereign, policy-driven data routing

Each organization runs its own Stargate node. Trust relationships are established bilaterally between organizations — there is no central authority or coordinator. This is how Stargate scales institutional trust.

EHDS Article 71 (in force 26 March 2025) made consent enforcement a legal right — not just an organisational best practice. Every secondary use of identifiable health data must be deniable by the subject, and that denial must propagate across every downstream party. No centralized consent registry can satisfy Article 71(8), which explicitly forbids storing additional identification data solely for opt-out purposes.

Stargate anchors authorization in subject-controlled Key Event Log state. Consent withdrawal is a key rotation the subject performs unilaterally. Downstream parties holding stale authorizations must re-authenticate against the latest KEL state — the withdrawal propagates by failing closed at every downstream verifier, without requiring a central register.

FHIR-over-Stargate is architectural — production deployment depends on hospital onboarding; earliest plausible September 2026.

Read the consent architecture thesis

Deployment models

Cloud

Private Cloud

Deploy Stargate in your own cloud environment with full control over infrastructure and data residency.

On-premises

On-Premises

Run Stargate entirely within your own data centre for maximum control and compliance.

Azure

Azure Virtual Machine

Deploy on Azure VM for organizations already invested in Microsoft infrastructure.

Service

Gateway-as-a-Service

Vereign-operated gateway for organizations that want the capabilities without managing infrastructure.

Dev

Development

Development environment for testing and integration before production deployment.

SEAL — the verifiable communication layer within Stargate

SEAL (Secure Edge Application Layer) handles verifiable messaging within the Stargate infrastructure — every sender verified, every message cryptographically signed and auditable. Stargate is the full trust infrastructure; SEAL is the communication function that runs on top of it. SEAL can also be deployed independently wherever verifiable messaging is needed, without the full Stargate stack.

Explore SEAL — the verifiable communication layer →

See all use cases →

Fully open source, every line auditable

Stargate and SEAL are released under AGPLv3+ — every line of code is publicly auditable. The AGPLv3+ licence ensures modifications must also be shared openly, protecting the commons. Source code is available in the Vereign source repository.

What Stargate eliminates

Bilateral CA negotiations. Manual key exchange. Dependence on certificate chains for inter-organisational trust.

What Stargate is not

Not a VPN
Not a certificate authority
Not an identity provider
Not a blockchain

It is a bilateral trust infrastructure that makes organisations independently verifiable.

Stargate — frequently asked questions

What is Stargate?

Stargate is Vereign's cross-organisational trust fabric. Each organisation runs its own Stargate node; trust relationships between organisations are established bilaterally using Decentralised Key Management (DKMS) and the KERI protocol. There is no central authority or coordinator. Stargate is being rolled out across Swiss healthcare throughout 2026, with 850+ gateways already deployed through Health Info Net (HIN).

Does Stargate use a blockchain?

No. Stargate uses KERI (Key Event Receipt Infrastructure), which is based on hash-linked Key Event Logs (KELs). These are append-only logs — not a blockchain. There is no consensus layer, no token, no distributed ledger. The architectural choice to avoid blockchain is deliberate: regulated infrastructure needs deterministic verification, not probabilistic settlement.

How is Stargate deployed?

Each participating organisation operates its own Stargate node, on-premises or in its own cloud tenancy. No data, keys, or credentials flow through a Vereign-operated central service. Stargate is AGPLv3+, so customers and partners can run it independently; Vereign provides deployment, operations, and 24/7 support under a separate services agreement.

Is Stargate a certificate authority or a replacement for one?

Stargate is not a certificate authority. It eliminates the need for a third-party CA at the cross-organisational trust layer by anchoring identity in each organisation's own KERI key event log. Internal use of X.509 certificates for TLS or device identity remains compatible; Stargate replaces the CA role in institution-to-institution trust.

What is KERI and why does Stargate use it?

KERI (Key Event Receipt Infrastructure) is a cryptographic protocol for self-certifying identifiers. Every organisation's identity is derived from its own key material and evolves through an append-only Key Event Log with pre-rotation of keys — meaning the next key is committed before the current one is used, enabling safe recovery from compromise. Stargate uses KERI because it gives cross-organisational trust without a central authority and makes post-quantum migration a routine key rotation rather than a big-bang re-issuance.

Who operates Stargate in production today?

Health Info Net (HIN) operates the Swiss healthcare deployment on Vereign infrastructure — 850+ gateways, rolling out to hospitals through 2026 and GP offices through 2027. Pilot and production work began in March 2023; SEAL (the messaging layer on Stargate) has been live since 2024.