Security.
Threat model, key management, audit roadmap — written honestly, including what we have not done yet.
Threat model.
What's in scope, what's out, and where trust boundaries sit.
In scope
- Credential-issuance integrity (BBS+ signing)
- did:solidus resolution + document integrity
- ERC-8004 anchor correctness (Identity + Validation Registry)
- Public verification API abuse / rate-limiting
- Operator-token handling
Out of scope
- Operator's own key custody (we never hold it)
- The ERC-8004 standard itself (open EIP, not ours)
- Ethereum's base-layer (L1) security
- Third-party agent-framework runtimes (AgentKit / Crossmint / Olas)
- verify.solidus.network KYC internals (separate product, separate trust boundary)
Solidus Agents sits at a specific point in the trust chain: the operator proves who they are once, at verify.solidus.network; Solidus signs and anchors the resulting agent credential; the relying party verifies it independently against the public registries. Each boundary is deliberately narrow — Solidus never holds operator keys, and a relying party never needs a Solidus account to check a credential.
Key management.
Who holds what, and what a compromise of each one actually exposes.
Operator keys
The operator's did:solidus signing key stays with the operator. Solidus Agents never holds or escrows it — a compromise of Solidus does not expose operator keys.
Issuer key
The BBS+ issuer key signs every credential we issue. Today: environment-isolated, access-controlled. Planned: HSM-backed signing.
Anchor wallet
A dedicated wallet submits Identity and Validation Registry anchors on Ethereum. Funds are scoped and spend is monitored; anchor costs are ETH gas, billed at cost.
Data minimization by design.
A security property, not a marketing feature — the agent proves only what a relying party needs.
Every credential Solidus issues is signed with BBS+, a signature scheme built for selective disclosure. An agent can prove a specific claim — operator KYC verified, running on a regulated network, a capability still active — without revealing the credential's full payload to the relying party asking. The unrequested claims never leave the agent's side.
That is the property a wallet address or an on-chain credential cannot offer: a wallet address discloses everything or nothing, and an on-chain claim is public by construction. BBS+ makes partial, provable disclosure possible — which is what a data-minimization requirement in a regulated integration actually asks for.
See it end to endIssued to the agent
Disclosed to a relying party
Audit roadmap.
We do not have audit reports yet. This is the plan — nothing below is marked complete.
External smart-contract + protocol audit
Pending seed funding.
Engagement to be scheduled with a reputable firm once seed funding closes. No firm is named until an engagement is signed.
Bug bounty program
Not yet live.
A coordinated-disclosure bounty is in planning. No reward tiers are published until it launches.
Continuous internal review
Internal code review and dependency monitoring on the issuance and anchoring paths.
Report a vulnerability.
Found a security issue in the SDK, verification API, issuer, or anchoring path? Tell us. Good-faith research is welcome — no legal action for responsible disclosure. We aim to acknowledge within 24 hours.
PGP key available on request.