Solidus Ecosystem

Overview

The Solidus ecosystem comprises surfaces at different maturity stages: 9 are fully live (Verify, Identity, Auth, Pod, Explorer, RPC, Docs, a secondary devnet, and the marketing site), 3 are live in self-labelled beta (Wallet, Agents, Relay), 1 is live in early/dev status (Node), and several more named below have not been built yet (no DNS resolution). “Surface,” “product,” and “business” are different units — this page counts web/API surfaces, not businesses or standalone products. Each surface is an independent codebase with its own development lifecycle, but all share the Solidus Protocol as their foundation layer.

Service Map

app.solidus.network (a native mobile/desktop app) and social.solidus.network (federated communications, previously described on this page) are not part of the canonical surface inventory — their hostnames don’t resolve and they aren’t on the roadmap’s own radar.

Service Dependencies

Services must be built in dependency order. A service cannot launch until its dependencies are operational.

Protocol (foundation)
├── Verify (first product, needs protocol for DID/VC)
├── Identity (needs protocol for DID management)
│   ├── Wallet (needs identity for user context)
│   ├── App (needs identity + wallet)
│   └── Pod (needs identity for access control)
├── Node (needs protocol for consensus participation)
│   └── Explorer (needs node for chain data)
├── Dev Portal (needs protocol SDK to document)
├── Relay (needs protocol for transaction handling)
├── Gov (needs protocol for on-chain voting)
├── Bridge (needs protocol + external chain connectors)
├── Pay (needs wallet + identity)
├── Data (needs identity + pod for consent management)
└── Social (needs identity + pod for message storage)

Marketing (independent — can launch anytime)

Build Order

Status note: The phases below describe the originally planned sequencing, not current state. Several items shipped ahead of this narrative or landed with different scope (e.g. Wallet, Agents, and Relay are live in beta, not “Planned”). See the Service Map above for authoritative per-surface status.

Phase 1: Foundation (Months 1-6)

Protocol and Verify developed in parallel with Marketing site.

• Protocol provides the DID/VC infrastructure
• Verify is the first revenue-generating product
• Marketing site explains the vision and collects interest

Phase 2: Core Platform (Months 7-12)

Identity, Node, and Dev Portal launch.

• Identity gives users a dashboard to manage their DID and credentials
• Node software allows community participation
• Dev Portal enables third-party integration

Phase 3: Expansion (Year 2)

Wallet, Explorer, App, Pod, Relay, Gov launch.

• Wallet and App provide consumer-facing products
• Explorer and Gov provide transparency and community governance
• Pod and Relay provide infrastructure services

Phase 4: Full Ecosystem (Year 3+)

Pay, Bridge, Data, Social launch.

• These services require a mature user base and protocol stability
• Each opens new revenue streams and use cases

Pod API

Solidus pods are built on Tim Berners-Lee’s Solid Protocol — the open standard for user-controlled personal data stores. pod.solidus.network runs Community Solid Server  (v7.x) — a real, Solid-spec-compatible LDP server (not fully spec-conformant), not a custom multipart/JWT API. Each user gets their own pod at pod.solidus.network/<slug>/ (path-based multi-tenancy, not a subdomain per user), provisioned via CSS’s account API and owned by a WebID minted by auth.solidus.network (Solid-OIDC, DPoP-bound tokens).

Live today, using the standard LDP verbs CSS provides out of the box:

GET    /<slug>/                    # List a container
POST   /<slug>/                    # Create a resource in a container
PUT    /<slug>/<resource>          # Create or replace a resource
DELETE /<slug>/<resource>          # Delete a resource

Access control is enforced via WAC (Web Access Control) .acl resources, same as any Community Solid Server pod. The deployment uses CSS’s file-based storage backend — there is no SPARQL query endpoint configured, and no custom resource schema on top of stock CSS.

Developer SDK

DID Challenge-Response (@solidus-network/auth)

import { createChallenge, verifyPresentation } from '@solidus-network/auth'
 
// Issue a challenge for a DID to answer
const challenge = createChallenge('did:solidus:testnet:user123')
 
// ...the holder signs challenge.nonce and returns a VerifiablePresentation...
 
const result = await verifyPresentation(challenge, presentation, resolvePublicKey)
console.log(result.valid)

See the @solidus-network/auth reference for the full signature.

CLI (@solidus-network/cli)

npx @solidus-network/cli did resolve <did>
npx @solidus-network/cli did create --public-key <hex>
npx @solidus-network/cli credential verify <vcId>
npx @solidus-network/cli init          # wire Solidus into a Next.js app
npx @solidus-network/cli mcp install   # add @solidus-network/mcp to .mcp.json

There are no solidus contract * commands — Solidus has no smart-contract VM today (see Architecture). See the full CLI reference.

SDK Packages

See the SDK Overview for the full list of published @solidus-network/* packages, with npm badges that track the current version — do not hardcode a version or package count here, both change independently of this page. @solidus-network/jwt is referenced in older planning material but was never published; do not install it.

Third-Party Integration Points

Identity Providers (Inbound)

• Google — OAuth sign-in is live on Verify and Identity today.
• Microsoft, Apple, government digital ID systems, university credential systems, and professional certification bodies are not integrated — there is no code path for any of them today.

Blockchain Networks (Outbound)

There is no smart-contract VM and no live bridge to another chain today (see Architecture). An EVM-compatible subnet has early, unwired scaffolding in the protocol repo (solidus-evm), but it is not built into the running node binary or exposed over RPC. Bitcoin, Avalanche, Cosmos, and Polkadot bridges do not exist in the codebase in any form.

Enterprise Connectors

• OAuth 2.0 / OpenID Connect — live; auth.solidus.network is an OIDC bridge (discovery document at /.well-known/openid-configuration).
• Active Directory/LDAP, SAML 2.0, and WebAuthn/FIDO2 are not implemented.

Pod Storage Structure

Each pod is provisioned at pod.solidus.network/<slug>/ by Community Solid Server’s own account API — the resource layout inside is whatever CSS creates by default for a new pod, not a Solidus-specific schema. Solidus has not defined or built a custom resource layout (a wallet/identity/social directory structure was previously drafted on this page but was never implemented anywhere in the codebase — removed rather than presented as a roadmap item it isn’t).