The mediator that routes your DIDComm messages.
Chain-anchored, credential-gated, hosted. Your agents exchange encrypted messages without being online together — and you can prove where every route was resolved.
Testnet · pre-launch — the console preview renders the real operator surface on sample data.
Request mediation. Forward. Pick up when you're back.
The standards-track DIDComm mediation stack, run as a service — the three protocols named, nothing proprietary.
Agent requests mediation
CoordinateMediation 2.0 — mediate-request in, mediate-grant out; the relay becomes the agent’s routing endpoint and manages its keylist.
mediate-request → mediate-grantSender forwards an encrypted envelope
Routing — the relay unwraps only the outer forward envelope and holds the JWE it cannot read for the recipient.
forward { JWE ciphertext }Offline recipient picks it up
Pickup Protocol 3.0 — delivery-request when the agent reconnects, or live-delivery over a persistent connection.
delivery-request → messages-receivedFull sequence, message by message, on How the mediator works →
What a hosted mediator gives you that a library can't.
Chain-anchored routing
Routing keys and the mediator’s own endpoint resolve on-chain from did:solidus documents, block-cited — tamper-evident, phishing-resistant mediator discovery no off-chain registry offers.
Credential-gated delivery
Require a verified credential to accept mediation or delivery — checked against the Solidus verify stack, with BBS+ selective disclosure supported. No OSS mediator has a credential layer beneath it.
Hosted & unified
A managed multi-tenant plane with a real operator console — one stack with verify, identity, wallet, and agents. Point a mediator URL, not a Kubernetes chart.
Works with the agents you already run.
Keep your Credo, Veramo, or ACA-Py agent — point its mediator URL at the relay. Adapters are planned and ship with launch; the raw DIDComm v2 endpoint is the floor.
1// @solidus/credo-relay-adapter — planned, ships with launch2const agent = new Agent({3 modules: {4 mediationRecipient: new MediationRecipientModule({5 mediatorInvitationUrl: 'https://relay.solidus.network/invite',6 }),7 },8})
The rest of the field is a library. This is a product.
The open-source mediator field is real and good — we compose with it. What none of it ships is a hosted multi-tenant relay with an operator console.
| OSS mediators | Solidus Relay | |
|---|---|---|
| Deployment | Self-host — deploy, patch, scale, monitor | Hosted, multi-tenant |
| Operator console | None — logs and CLI | Queues, keylists, policies, delivery metrics |
| Routing resolution | Off-chain registry or static config | On-chain did:solidus, block-cited |
| Credential-gated delivery | Not available | Native, checked against verify |
| Getting started | Infrastructure project | $0, point a mediator URL |
Compose-with, not versus: Credo-TS, Veramo, and ACA-Py are integration targets, not competitors — their agents mediate through the relay with one line of config. XMTP and Matrix run different protocols (MLS / Matrix federation) and stay out of scope.
$0 for the first 1,000 messages a day.
No enterprise sales call. Planned launch pricing, public from day one — relay is on testnet, pre-launch.
Straight answers.
What is a DIDComm mediator?
DIDComm agents — wallets, issuers, verifiers — are rarely online at the same time. A mediator becomes an agent’s routing endpoint, holds its encrypted messages while it is offline, and delivers them when it reconnects (CoordinateMediation 2.0 + Pickup Protocol 3.0).
Can you read my messages?
No. The relay routes JWE-encrypted envelopes addressed DID-to-DID; it unwraps only the outer forward envelope. There is no plaintext access and no message-body column anywhere in the console — by construction, not policy.
What is chain-anchored routing?
An agent’s routing keys and the mediator’s service endpoint resolve on-chain from its did:solidus document, cited to a block — instead of an off-chain registry the operator controls. Discovery becomes independently verifiable and tamper-evident.
What is a credential-gate?
A policy that requires the recipient (or sender) to hold a verified Solidus credential — KYC, membership — before the relay accepts mediation or delivers a message. Checked against verify.solidus.network, with BBS+ selective disclosure supported.
Do I have to use did:solidus?
No — any DIDComm v2 agent can mediate through the relay. Chain-anchored resolution is what did:solidus adds; other DID methods resolve through their own drivers.
Which agent frameworks work?
Anything that speaks DIDComm v2 mediation. Credo-TS, Veramo, and ACA-Py adapters are planned and ship with launch; the raw DIDComm v2 endpoint works for any conformant agent.
Can I self-host?
Yes — the mediator protocols are open standards, and self-hosting an OSS mediator is a fine choice if you want to run the infrastructure. The relay is for teams that want a mediator URL, an operator console, and the chain-anchored + credential-gated layer without the ops.
How is this different from XMTP or Matrix?
Different protocol layer — XMTP is built on IETF MLS and Matrix on its own federation protocol. The relay is DIDComm v2 transport: compose-with, not compete.