How Solidus works, layer by layer
Five subsystems — DID method, credential format, validator consensus, on-chain registry, and the fee mechanism. Every section links to the paper that proves it.
did:solidus — identifier resolution.
Every Solidus identifier is a DID — a Decentralized Identifier per the W3C DID Core 1.0 standard. The Solidus-specific method is `did:solidus:<network>:<id>`, where `<network>` is `mainnet` or `testnet` and `<id>` is the base58-encoded hash of the controller's public key.
DID documents — the JSON structure that resolves from a DID — live on-chain in the registry contract. Resolution is a single read against any validator node, no central directory required. Key rotation, controller change, and service-endpoint updates are signed transactions; each one increments the DID document version.
We chose to put DID documents on-chain (not off-chain like did:web) because the protocol's trust anchor is the validator set — keeping resolution within that set means verifier and issuer share the same source of truth without needing to ping a third-party service.
W3C Verifiable Credentials, BBS+ proofs.
Solidus credentials follow the W3C Verifiable Credentials Data Model 2.0. Every credential is a JSON document with a context, a type, an issuer DID, a subject DID, the attested attributes, and a cryptographic proof.
The proof scheme is BBS+ — a pairing-based signature that supports selective disclosure. A holder presenting a credential can choose which attributes to reveal and which to keep hidden, with a constant-size proof regardless of credential size. Verifiers learn only what the holder chooses to share.
Revocation is registry-anchored. Each credential carries a revocation index; the on-chain registry tracks revoked indices. Verifiers query the registry as part of the verification flow — no need to contact the issuer to check status.
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://solidus.network/vc/v1"
],
"type": ["VerifiableCredential", "KYCCredential"],
"issuer": "did:solidus:mainnet:0x7a3f...",
"credentialSubject": {
"id": "did:solidus:mainnet:0xb4e2...",
"kycLevel": 2,
"ageVerified": true
},
"proof": { "type": "BbsBlsSignature2020" ... }
}HotStuff-derived BFT consensus.
Solidus runs a HotStuff-derived Byzantine Fault Tolerant consensus among the validator set. Leader rotation happens every view (epoch); voting proceeds in three phases — prepare, precommit, commit — with a 2f+1 quorum required at each phase, where f is the maximum tolerated Byzantine faults (up to one-third of validators).
Finality is fast: 1.4 seconds at the median, deterministic (no probabilistic confirmation depth). Liveness holds under partial synchrony; safety holds under full asynchrony. Both are properties of HotStuff that we preserve in the Solidus adaptation.
Slashing penalizes provable misbehavior — double-vote, double-propose, and equivocation. The slashed stake routes to the on-chain treasury (per the fee mechanism in §6). Validators who go offline lose rewards but aren't slashed; only safety-violating behavior triggers stake destruction.
The registry contract.
The registry contract is the on-chain canonical state. It stores DID-document hashes (keyed by DID), issuer public keys, revocation entries, and the active validator set. Total state is bounded by the number of unique DIDs registered — currently under 100MB for an order-of-magnitude estimate.
Credential bodies are NOT on-chain. The BBS+ proof, the issuer's signature, the attested attributes — all that lives off-chain in the holder's wallet. The chain only stores the minimum required to anchor trust: the issuer's authority to sign, the revocation status, the validator set's current composition.
Gas cost per operation is intentionally low: DID registration ~$0.0003, credential anchor ~$0.0001, revocation entry ~$0.0001. This is the cost the issuer pays; verifiers pay a separate per-verification fee covered in §6.
Validator fees + treasury + burn.
Each credential verification costs $0.05 in protocol fees, paid by the verifier (the party requesting verification, typically a service operator). Of the $0.05: 70% routes to validators (proportional to stake-weighted vote contribution), 20% to the on-chain treasury (governance-controlled), 10% is burned.
The 10% burn is the deflationary lever. Once daily verification volume exceeds the issuance rate, the protocol becomes net-deflationary — see /tokenomics for the 11-year model. Verification demand pays for both validator security and supply contraction.
Fee adjustment is dynamic but bounded. The protocol can adjust the per-verification fee within ±20% of the base $0.05 in response to demand spikes; larger changes require governance vote. This keeps the user experience predictable while letting the network respond to load.
Compliant by design.
The protocol is built on open standards from W3C, IETF, OpenID, and NIST — and aligned with EU and ISO regulatory frames. Nothing proprietary; everything inspectable.
Verifiable Credentials — the canonical credential format.
Decentralized Identifiers — the canonical identifier syntax.
Selective Disclosure JWT — alternative credential serialization for legacy interop.
OpenID for Verifiable Credentials — issuance + presentation protocols.
Identity assurance level mapping. We support IAL2 and IAL3.
European Digital Identity Wallet compatibility from day one.
Data minimization via BBS+ selective disclosure. Right to erasure via key deletion.
Information security management. SOC 2 Type II in progress (2026).