Business wallets

Every integrated open-source business wallet gets an identical playground page: a hosted, Verana-verified demo service you can exercise end to end.

A business wallet is the organization-side wallet: it hosts an organization's services - support agents, credential issuers, login portals - and gives each of them a verifiable identity. Integrating Verana means the hosted service becomes a Verifiable Service: it presents the required credentials, so anyone can verify what it is and who operates it before connecting.

Become a Verifiable Service

The hosted service is identified by a resolvable DID. Its DID Document presents the required credentials as Linked Verifiable Presentations: ECS-Service (what the service is) and ECS-Organization (who operates it), issued under ecosystem governance.

Be trust-resolvable

Anyone - a personal wallet, another service - resolves the DID against the public registry and sees the Proof-of-Trust before connecting. TRUSTED is earned from the credential chain, never just claimed.

Issue and verify under accreditation

With ISSUER or VERIFIER accreditations in an ecosystem, the hosted service offers credentials and requests presentations - and every peer's wallet checks those accreditations before accepting or sharing.

Three integration tracks: native (your stack speaks Verifiable Trust directly), sidecar (run vs-agent alongside your stack - it handles DIDs, DIDComm, Linked VPs and registry operations), or bridge (keep your OpenID4VC stack, add trust resolution). Each integrated wallet below runs a live, Verana-verified demo service.

Verana's business wallet

VS Agent

reference implementationApache-2.0self-hosted

VS Agent is the reference business wallet of the Verana ecosystem: an open-source container that packs the complete stack of a Verifiable Service, as defined by the Verifiable Trust specification. It gives a hosted service a resolvable DID, manages its credentials and Linked Verifiable Presentations, resolves trust before every exchange, and runs the registry operations for you. It is the runtime behind every demo service in this playground, and the sidecar that powers most of the other integrations below.

Holder, issuer and verifier

One runtime plays all three roles under ecosystem accreditation: it holds its own credentials, issues to peers and verifies presentations, with revocation support on every rail.

Dual transport

DIDComm (Issue Credential v2, Present Proof v2, vt-flow) and OpenID4VCI / OpenID4VP with SD-JWT VC, DCQL and Presentation Exchange, plus Token Status List revocation.

The right format for each credential

Public credentials as JSON-LD Linked VPs with on-chain digest anchoring; AnonCreds where presentations must stay unlinkable; SD-JWT VC for OpenID4VC interop. Each class keeps its matching revocation semantics.

Ecosystem-driven lifecycle

The vt-flow protocol turns on-chain ecosystem actions into wallet actions: onboarding triggers issuance, and a revoked participant means the credential is revoked, pushed to the holder and cleaned up automatically - no polling.

Trust resolution built in

Every DIDComm connection and every OpenID4VP presentation is checked against the Verana registry before it is accepted: Proof-of-Trust on both transports, fail closed.

Any service shape

Chat services on Hologram, MCP servers, A2A agents and plain HTTP APIs, all declared under one DID. Plugin architecture, Docker self-hosting, REST admin API and NestJS / JS clients.

See it in action in the Vesta use case Get it on GitHub Read the spec

Wallets that can provide Verifiable Services

These open-source business wallets support Verifiable Trust: they manage a resolvable DID and can present the required credentials as Linked Verifiable Presentations in their DID Documents, so the services they host resolve as Verifiable Services. They do not support the automated vt-flow lifecycle: credentials and Linked VPs are obtained and added manually. Each integrated wallet has its own playground page and hosted demo service.