Skip to Content
ConceptsHow Solidus Works

How Solidus Works

Solidus is a decentralized identity protocol. It replaces centralized identity providers with a system where users own their identity data, verify once, and present cryptographic proofs to any service that needs them.

The Problem with Centralized Identity

Today’s identity infrastructure has three fundamental issues.

Single points of failure. When you use Auth0, Okta, or Firebase Auth, your users’ identities live on someone else’s servers. If that provider goes down, gets breached, or changes their pricing, you lose access to your users’ identity data. In 2023, Okta’s breach exposed customer data across thousands of companies — because everyone depended on the same central system.

Redundant verification. Every service that needs to know you are who you say you are runs its own KYC process. You upload your passport to your bank, then again to your crypto exchange, then again to your insurance provider. Each copy of your documents is another attack surface. Each verification costs money and takes time.

Users do not own their data. Your identity information — name, date of birth, address, verification status — is stored and controlled by the services you sign up for. You cannot move it. You cannot revoke access. You have no visibility into who has what.

The Solidus Approach

Solidus inverts this model. Instead of services storing your identity data, you store it yourself and present cryptographic proofs on demand.

The flow works like this:

1. User completes KYC verification once 2. Issuer signs a Verifiable Credential (cryptographic proof) 3. Credential hash is anchored on the Solidus blockchain 4. User stores the credential in their DID wallet 5. When a service needs proof, user presents a zero-knowledge proof 6. Service verifies the proof against the blockchain — no issuer contact needed

The personal data never touches the blockchain. Only cryptographic hashes and proofs are stored on-chain. The actual credential — containing your name, date of birth, or whatever was verified — stays on your device.

Key Primitives

Solidus is built on four cryptographic primitives that work together.

Decentralized Identifiers (DIDs)

A DID is a globally unique identifier that you own and control. Unlike an email address (controlled by Google or Microsoft) or a social security number (controlled by a government), a DID is controlled by whoever holds the private key.

Solidus DIDs follow the W3C DID standard and look like this:

did:solidus:testnet:7Hk3mRtQZvNxP2bK9wYfJ4eD6cA5sLgR

Each DID is backed by an Ed25519 key pair. The address is derived from the public key using BLAKE3 hashing, ensuring it is deterministic and collision-resistant. The DID Document — which lists the public keys and verification methods — is stored on-chain and can be resolved by anyone.

For a deep dive, see Decentralized Identifiers.

Verifiable Credentials (VCs)

A Verifiable Credential is a cryptographic proof that something is true about you. It is the digital equivalent of a passport stamp, a diploma, or an age verification — except it is machine-verifiable and tamper-proof.

A credential has three parties:

  • Issuer — the entity that verified the claim and signed the credential (e.g., Solidus Verify after completing KYC)
  • Holder — the person the credential is about (you)
  • Verifier — the service that checks the credential (e.g., a DeFi protocol that needs KYC proof)

The issuer signs the credential with their private key and anchors a hash on the Solidus blockchain. The holder stores the signed credential. When a verifier needs proof, the holder presents the credential and the verifier checks the signature, the on-chain anchor, the expiration date, and the revocation status — all without contacting the issuer.

For a deep dive, see Verifiable Credentials.

BBS+ Signatures and Selective Disclosure

Standard digital signatures are all-or-nothing: you either show the entire signed document or nothing. BBS+ signatures solve this by enabling selective disclosure.

With BBS+ signatures, a credential holder can reveal only specific claims from a credential while proving the entire credential is valid and unmodified. For example:

  • A credential says: name = “Alice”, dob = “1990-01-15”, country = “DE”, kyc_level = 3
  • A verifier needs proof of KYC level 3 and EU residency
  • The holder reveals only country and kyc_level, keeping name and dob private
  • The verifier can cryptographically confirm these revealed claims are part of a valid, signed credential

This is not redaction — it is a zero-knowledge proof that the hidden fields exist and were signed by the issuer, without revealing their values.

HotStuff BFT Consensus

The Solidus blockchain uses HotStuff BFT (Byzantine Fault Tolerant) consensus to achieve fast finality with a small validator set.

Key properties:

  • ~2.5 second blocks — fast enough for real-time credential verification
  • 3-chain finality — a block is final after 3 subsequent blocks are produced (about 7.5 seconds)
  • Byzantine fault tolerance — the network continues operating correctly even if up to 1/3 of validators are malicious
  • Leader rotation — validators take turns proposing blocks, preventing any single validator from controlling block production

The consensus mechanism is designed for identity workloads: high throughput of small transactions (DID operations, credential anchors) with deterministic finality. This is not a general-purpose smart contract chain — it is purpose-built for identity.

For architecture details, see Architecture.

How Verification Works End-to-End

Here is a concrete example of the full verification flow.

Step 1: User signs up on Solidus Verify. The user creates a DID (an Ed25519 key pair is generated, the public key is registered on-chain). They complete KYC by uploading identity documents and performing a liveness check.

Step 2: Solidus Verify issues a credential. After the documents are verified (OCR, face matching, database checks), Solidus Verify signs a KycLevel1Credential with its issuer DID. The credential hash is anchored on-chain via a CredentialIssue transaction.

Step 3: User stores the credential. The signed credential is stored in the user’s DID wallet (the Identity app at identity.solidus.network). The personal data in the credential never leaves the user’s control.

Step 4: A third-party app needs KYC proof. A DeFi protocol integrates with Solidus and requires KYC Level 1 for its users. It sends an authentication challenge requesting a KycLevel1Credential.

Step 5: User presents proof. The user’s wallet creates a Verifiable Presentation — a signed package containing the credential (or a selective disclosure proof of it) and a response to the challenge. This proves the user controls the DID and holds the credential.

Step 6: Third-party verifies. The protocol checks:

  • Is the presentation signature valid? (Ed25519 verification)
  • Does the credential’s on-chain anchor exist? (RPC query to Solidus)
  • Has the credential been revoked? (revocation registry check)
  • Is the credential expired? (date comparison)
  • Was the credential issued by a trusted issuer? (issuer DID check)

All of this happens in milliseconds, with no API call to Solidus Verify. The verification is entirely trustless.

What Makes This Different

Compared to centralized identity providers:

Centralized (Auth0, Okta)Solidus
Data locationProvider’s serversUser’s device
VerificationPer-service, redundantOnce, reusable everywhere
PrivacyProvider sees all auth eventsZero-knowledge proofs
AvailabilityProvider downtime = your downtimeDecentralized, no single point of failure
PortabilityVendor lock-inOpen standard (W3C DID/VC)
CostPer-auth pricingOne-time verification cost

Compared to other decentralized identity projects:

Generic DID networksSolidus
VerificationSeparate, off-chainIntegrated (Solidus Verify)
Selective disclosureOften missingBBS+ signatures built in
FinalityVaries (minutes to hours)~7.5 seconds (3-chain)
PurposeGeneral-purposeIdentity-optimized chain

Next Steps

  • Getting Started — build something with the SDK in 5 minutes
  • DIDs — DID document structure, key derivation, resolution
  • Credentials — credential types, issuance, selective disclosure
  • Architecture — consensus, state model, transaction types
Last updated on