Solidus Ecosystem

Overview

The Solidus ecosystem comprises 19 product surfaces (9 live on testnet) that collectively provide decentralized identity, authentication, wallet, agent, and communication infrastructure. Each surface is an independent product with its own development lifecycle, but all share the Solidus Protocol as their foundation layer.

Service Map

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

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

Federated Communications

The Social service integrates two major federated protocols:

ActivityPub (Mastodon)

A modified Mastodon instance at social.solidus.network with:

• WebID authentication replacing standard OAuth
• Pod storage backend (user toots stored in their pod, not centralized)
• Cross-protocol following
• Lightning Network tips for content monetization

Matrix (Element)

A Synapse/Dendrite homeserver at matrix.solidus.network with:

• WebID SSO
• Pod-based end-to-end encryption key storage
• Decentralized room state across participant pods
• Crypto payment channels for premium features

Unified Communications Hub

A single inbox aggregating messages across protocols:

comm.solidus.network
├── ActivityPub timeline
├── Matrix messages
├── Solidus pod notifications
└── Nostr events (optional)

Cross-Protocol Identity

Users maintain a single Solidus WebID that maps to all protocol identities:

• ActivityPub: @[email protected]
• Matrix: @username:matrix.solidus.network
• Solid: WebID URI
• Nostr: derived public key

API Specifications

REST Endpoints

Identity Management

POST   /api/v1/identity/create
GET    /api/v1/identity/{webId}
PUT    /api/v1/identity/{webId}
DELETE /api/v1/identity/{webId}
POST   /api/v1/identity/authenticate
POST   /api/v1/identity/verify
GET    /api/v1/identity/credentials

Wallet Operations

POST   /api/v1/wallet/create
GET    /api/v1/wallet/{walletId}/balance
POST   /api/v1/wallet/{walletId}/transaction
GET    /api/v1/wallet/{walletId}/transactions
POST   /api/v1/wallet/{walletId}/sign

Verification Services

POST   /api/v1/verify/email
POST   /api/v1/verify/phone
POST   /api/v1/verify/crypto-address
GET    /api/v1/verify/status/{verificationId}
POST   /api/v1/verify/confirm

Auth Bridge (OIDC-compatible)

POST   /auth/verify          # Verify VP, return JWT
GET    /vc/{vc_hash}         # Fetch VC metadata
POST   /tx/send              # Send transaction to mempool

WebSocket Events

Applications can subscribe to real-time events:

• wallet.update — balance changes
• verification.complete — verification finished
• identity.change — DID document updated
• credential.issued — new credential received
• credential.revoked — credential revoked

Pod API (Roadmap — Solid-spec LDP compatibility planned)

Solidus pods are built on Tim Berners-Lee’s Solid Protocol — the open standard for user-controlled personal data stores. Today the Solidus pod (pod.solidus.network) exposes a per-user multipart upload + JWT auth model; the full Solid-spec Linked Data Platform (LDP) and SPARQL support shown below is on the roadmap, not yet shipped.

GET    /pods/{username}/                    # List container       (roadmap)
POST   /pods/{username}/                    # Create resource      (roadmap)
PUT    /pods/{username}/{resource}          # Update resource      (roadmap)
DELETE /pods/{username}/{resource}          # Delete resource      (roadmap)
POST   /pods/{username}/sparql              # SPARQL query         (roadmap)

Developer SDK

Browser SDK

import { solidusAuth } from "@solidus-network/auth";
 
const session = await solidusAuth.login({
  requiredClaims: ["email_verified", "human", "age_over_18"]
});
 
console.log(session.user.did);
console.log(session.token);

Backend SDK

import { verify } from "@solidus-network/jwt";
 
app.get("/profile", async (req, res) => {
  const token = req.headers.authorization.split(" ")[1];
  const session = verify(token);
  if (!session.valid) return res.status(401).send("Unauthorized");
  res.json({ did: session.sub, claims: session.claims });
});

CLI Tools

solidus contract new       # Scaffold new smart contract
solidus contract build     # Compile to WASM
solidus contract deploy    # Deploy to network
solidus contract call      # Call contract method
solidus node start         # Start light node
solidus did create         # Create new DID
solidus vc issue           # Issue credential

SDK Packages (Planned)

Third-Party Integration Points

Identity Providers (Inbound)

Solidus can consume credentials from:

• Google, Microsoft, Apple (OAuth bridge)
• Government digital ID systems
• University credential systems
• Professional certification bodies

Blockchain Networks (Outbound)

Solidus bridges to:

• Bitcoin (Lightning Network, Taproot anchoring)
• Ethereum (EVM compatibility, ENS integration)
• Avalanche (subnet-to-subnet)
• Cosmos (IBC protocol)
• Polkadot (XCM)

Enterprise Connectors

• Active Directory / LDAP
• SAML 2.0
• OAuth 2.0 / OpenID Connect
• WebAuthn / FIDO2

Pod Storage Structure (Roadmap)

Solidus pods follow Tim Berners-Lee’s Solid Protocol model. When the Solid-spec LDP layer ships, each user’s Solidus pod will follow the standard Solid RDF resource layout. The deployed pod today (pod.solidus.network) uses a flat-file multipart upload model; the Turtle (.ttl) layout below is the roadmap target for full Solid-spec compatibility.

/{username}.solidus.network/
├── profile.ttl                 # WebID with payment info
├── wallet/
│   ├── keys.ttl                # Encrypted private keys
│   ├── addresses.ttl           # Public addresses
│   ├── transactions/           # Transaction history by period
│   └── preferences.ttl         # Payment preferences
├── identity/
│   ├── credentials/            # Verifiable credentials
│   ├── presentations/          # Presentation templates
│   └── biometric-proof.enc     # Encrypted liveness proof token (not raw biometrics — biometric data stays with the issuing oracle; only the proof token is stored in the pod)
├── social/
│   ├── activitypub/
│   │   ├── inbox/
│   │   ├── outbox/
│   │   └── followers/
│   ├── matrix/
│   │   ├── rooms/
│   │   └── keys/
│   └── unified/
│       ├── timeline/
│       └── notifications/
└── contacts/
    └── trusted-addresses.ttl   # Guardian/recovery contacts