Architecture

Documentation Index

Fetch the complete documentation index at: https://docs.soverage.com/llms.txt

Use this file to discover all available pages before exploring further.

Soverage Gateway is built on open standards and a privacy-first design. This page provides a high-level overview of the technical architecture.

​

Overview

​

Components

​

User device (privacy boundary)

DID keys, credentials, and attestation data are stored locally on the user’s device. The wallet is used for signing operations only. No funds are transferred. Personal data never leaves the device.

​

Gateway (stateless)

The Soverage Gateway handles document verification and credential management (issuance, presentation). It is the coordination layer between the user and the DLT. The gateway is stateless with respect to personal data: document images are analyzed in memory and immediately discarded. No PII is retained after verification completes.

​

DLT layer (public, immutable)

Soverage is multi-chain by design. The DLT layer stores only cryptographic artifacts, never personal data:

• DID documents: public keys and service endpoints, resolvable by anyone
• Attestation commitments: SHA-256 hashes that prove verification happened without revealing what was verified
• Personhood Tokens: non-transferable tokens representing verified personhood

The architecture abstracts these services so that the same identity primitives (DIDs, VCs, Personhood Tokens) work across different networks. Currently live on Hedera, with support for additional chains planned.

​

Third-party verification

Verifiers can check credentials without contacting Soverage. They resolve the user’s DID directly on-chain, verify the VC signature, or check token ownership, all independently and trustlessly.

​

Verification pipeline

The verification pipeline combines multiple independent signals to build a user’s identity profile. Document analysis is one component. Additional attestations (email, phone, device, social account) provide independent verification signals. Each step produces a cryptographic commitment, not stored data. For details on what the pipeline outputs and how to verify it, see How It Works. For more on the privacy guarantees, see Privacy & Security.

​

Standards

​

Current network

Currently running on Hedera Testnet, using the Hedera Consensus Service for DIDs and attestations, and the Hedera Token Service for Personhood Tokens. Additional networks are planned.