Solidus Privacy and Security

Privacy guarantees, security architecture, vulnerability disclosure policy, compliance roadmap, and data processing agreements.

Privacy Model

Solidus is designed with privacy as a structural property, not a feature that can be toggled off. The following guarantees hold by design:

Core Privacy Guarantees

1. No biometric data stored. Biometric data (face scan, document images, liveness video) is processed by the Solidus verification engine during KYC and immediately discarded after the credential is issued. The engine retains only a cryptographic proof token confirming that verification occurred. Raw biometrics never touch the Solidus blockchain.

2. Selective disclosure. Users present exactly the claims a service requests — nothing more. A service asking “is this user over 18?” receives a yes/no answer, not a birthdate, not a name, not any other claim. Zero-knowledge proofs enable this without any trusted intermediary.

3. Unlinkability across services. Each presentation to a different service uses a fresh ephemeral key. Without the user’s explicit consent, it is cryptographically impossible for two services to determine that they interacted with the same user.

4. No central data store. Identity data lives in the user’s wallet (device-local) or in their Solid pod (user-chosen, user-controlled). Solidus does not maintain a central database of user identities, credentials, or verification histories.

5. Credential minimality. The protocol enforces that issued credentials contain only the claims required for the specific verification type. A KYC Level 1 credential contains no liveness data. A liveness credential contains no document data. Credentials cannot be over-scoped at issuance.

6. User-controlled revocation. A user can revoke any credential they hold at any time. Revocation takes effect immediately on-chain. The user does not need to ask the issuer’s permission.

What the Protocol Knows

The on-chain state contains:

A blockchain observer can see that did:solidus:1:8Qx9... issued a credential of type KYCLevel2Credential to did:solidus:1:Pm3r.... They cannot see the underlying name, document number, address, or any other personal data.

Threat Model

Security Architecture

Cryptographic Foundation

Post-quantum readiness: The current cryptographic suite is not post-quantum secure. NIST PQC standardization (ML-KEM, ML-DSA) is being tracked. A post-quantum migration path will be proposed as a Core SIP before 2028. The migration requires a hard fork, not a standard upgrade.

Network Security

Validator identity binding: Every validator must have a verified human identity (KYC Level 2). This prevents sybil attacks through economic stake alone. An attacker acquiring 51% of staked SLDS would also need 51% of verified human identities — a significantly harder attack.

BFT safety: The consensus protocol is Byzantine Fault Tolerant up to f < n/3 malicious validators (33% fault tolerance). A subset of malicious validators cannot finalize invalid blocks, only halt the network. Halting without finalizing invalid state preserves correctness.

Eclipse attack resistance: Peers are selected from diverse IP ranges and autonomous systems. No more than 20% of a node’s peer connections can come from a single /24 subnet. This makes eclipse attacks (surrounding a node with malicious peers) significantly harder.

Stake-weighted message validation: All P2P messages are signed. Messages from validators are weighted by their reputation score — a node with a fresh registration and minimum stake receives lower initial trust than a long-running node with high reputation.

Smart Contract Security

The Solidus L1 ships no general-purpose contract VM today — state transitions are native, typed Rust handlers (transfer, DID, credential, staking) over a Sparse Merkle Tree, so there is no untrusted bytecode in the consensus path. General-purpose programmability arrives on the roadmap as an EVM subnet (REVM) that shares the L1 validator set. The security practices below apply to that roadmap contract surface:

Formal verification (planned for v1.1): Core credential issuance and revocation contracts will undergo formal verification using the K Framework before mainnet launch.

Audit requirement: All smart contract deployments must pass a security audit from at least one of the following firms before mainnet deployment: Trail of Bits, NCC Group, Sigma Prime, ChainSecurity, or a firm of equivalent reputation.

Upgrade restriction: Smart contracts are non-upgradeable by default. Upgrades require a Core SIP plus a separate multisig approval from the Security Council. The 90-day activation grace period applies to contract upgrades.

Reentrancy protection: All state-mutating contract functions follow the check-effects-interactions pattern. External calls are made only after all state changes are committed.

Key Management

Validator keys: Hardware security module (HSM) storage is strongly recommended for Subnet and Core validators. The node supports PKCS#11 integration with supported HSMs (YubiHSM 2, AWS CloudHSM, Google Cloud HSM).

User keys: User private keys are never transmitted to any server. They are generated and stored on-device (in the Solidus wallet or browser extension). The biometric prompt is a local device unlock, not a server authentication.

Recovery: Users can recover their DID through:

1. Seed phrase (BIP-39, 24 words) — primary recovery method
2. Social recovery (trusted contacts who hold Shamir shares)
3. Hardware backup (export encrypted key to hardware wallet)

No custodial key option: Solidus does not offer custodial key storage. Users who lose their seed phrase and all recovery options lose access to their DID permanently. This is a deliberate design choice — true self-sovereignty requires the user to bear custody responsibility.

Vulnerability Disclosure

Responsible Disclosure Policy

Solidus follows coordinated disclosure. Security researchers who find vulnerabilities should report them privately before any public disclosure. We commit to:

• Acknowledgment: Within 24 hours of report
• Initial assessment: Within 72 hours
• Status update: Every 7 days until resolved
• Resolution: As fast as feasible based on severity
• Disclosure: After the patch is deployed and users have had time to update

Report to: [email protected] PGP key: Available at solidus.network/.well-known/security.txt

Please encrypt all vulnerability reports with our PGP public key. Do not discuss the vulnerability in public channels (Discord, GitHub, Twitter) until the coordinated disclosure window has closed.

Severity Classification

Bug Bounty Program

Solidus operates a continuous bug bounty program. Rewards are paid in SLDS.

In-scope:

• Solidus Protocol smart contracts (on mainnet and testnet)
• Node software (solidus-node)
• Auth SDK (@solidus-network/auth, @solidus-network/auth/server)
• Solidus API (api.solidus.network)
• Verify product (verify.solidus.network)

Out-of-scope:

• Third-party integrations and bridges
• Social engineering attacks against team members
• Denial-of-service attacks against infrastructure (without a novel exploit)
• Issues requiring physical access to user devices

Detailed bug bounty rules: solidus.network/security/bug-bounty

Security Audit History

All security audit reports are published in full at solidus.network/security/audits after the remediation period. Solidus does not withhold audit findings.

Compliance Roadmap

Compliance is achieved region-by-region. This is the planned sequence:

Phase 1 (Months 1-6): Legal Foundation

• Establish legal entity in a crypto-friendly jurisdiction (considering Switzerland, Singapore, UAE)
• Engage data protection counsel for GDPR pre-assessment
• Draft privacy policy, terms of service, and data processing agreements
• Conduct Data Protection Impact Assessment (DPIA) for biometric KYC flows
• Obtain legal opinion on token classification in target launch jurisdictions

Phase 2 (Months 7-12): Product Compliance

• GDPR compliance for EU users:
  • Data minimization by design (verified — biometrics not stored)
  • Right to erasure (DID deactivation severs personal data connection; on-chain records are pseudonymous)
  • Legitimate interest or consent legal basis for processing
  • Data processing records for all verification events
• CCPA compliance for California users:
  • Privacy notice at collection
  • Right to know, delete, and opt-out of sale (no sale occurs)
  • Biometric data under CCPA treated as sensitive personal information
• BIPA pre-assessment (Illinois Biometric Information Privacy Act)
  • Written consent before biometric data collection
  • Destruction schedule for biometric data (must specify in writing)
  • No profit from biometric data

Phase 3 (Year 2): Certification Targets

• SOC 2 Type II audit (security, availability, confidentiality)
  • Required for enterprise contracts > $50K/year
  • Expected timeline: 12-month observation period + 3-month audit
• ISO 27001 certification
  • Information security management system
  • Required for government and financial institution contracts
• eIDAS 2.0 compliance (EU)
  • Relevant for “Login with Solidus” to be accepted as an EU digital identity
  • Requires conformity assessment by a notified body

Phase 4 (Year 3+): Advanced Certifications

• FedRAMP (if pursuing US government contracts)
• PCI DSS (if payment processing revenue > $5M)
• HIPAA (if healthcare credential use cases are pursued)
• DORA compliance (EU Digital Operational Resilience Act) for financial services

Data Processing Agreements (DPAs)

DPAs are available for enterprise customers who require them for GDPR or other data protection law compliance.

Standard DPA Terms

Data controller / processor relationship: In most deployments, your application is the data controller and Solidus is the data processor. Solidus processes identity data only to the extent necessary to fulfill the verification service.

Data categories processed:

Subprocessors: Solidus processes government IDs and biometrics natively via its own verification engine. No third-party KYC providers are used. A current list of infrastructure subprocessors (hosting, email, monitoring) is maintained at solidus.network/legal/subprocessors. Enterprise customers are notified 30 days before any subprocessor change.

International transfers: Data processed for EU users is stored and processed within the EU (EU geographic subnet) unless the user explicitly selects a non-EU subnet. Standard Contractual Clauses (SCCs) cover any necessary transfers outside the EU.

Enterprise DPA Request: Send to [email protected] with:

• Company name, jurisdiction, and DPA contact
• Expected monthly verification volume
• Specific data categories and use cases

Standard DPA turnaround: 5 business days for new customers. Custom DPA negotiations available for Enterprise tier customers.

Security Contacts

Data Protection Officer (DPO): Required under GDPR for organizations processing special category data (biometrics). Appointed before EU launch.

PGP Fingerprint: Published at solidus.network/.well-known/security.txt (updated each time the security team key rotates)