Manav vs W3C Verifiable Credentials

VC is the rails. Manav is the train. The standard makes the protocol possible. The protocol makes the standard usable.

What W3C Verifiable Credentials is

The Verifiable Credentials Data Model is a W3C Recommendation finalized as a W3C Recommendation (with updates) that defines the structure of cryptographically signed claims. A VC has an issuer, a subject, a set of claims, a signature, and a verifiable presentation format. It is the lingua franca of self-sovereign identity. Manav, World ID, eIDAS 2.0 wallets, and most modern SSI vendors all speak it.

Why "rails, not train" is the right metaphor

A standard does not deploy itself. To use VC in production you need: a trustworthy issuer, a wallet, a verifier, a revocation mechanism, a key management strategy, a governance framework for what credentials count, and an integration with the systems that consume them. None of these come with the standard.

That is what Manav is — the train that runs on VC rails. We use the W3C data model where it fits, extend it where it doesn't (delegation chains, trust scores, work-attestation roles), and ship the wallet, verifier, and registry as one coherent product.

What Manav does that VC alone does not

• Delegation tokens. VC describes static credentials. Manav extends this with delegation tokens that carry scope, magnitude caps, and revocation endpoints — the agent-era addition.
• Work attestation roles. VC is silent on whether a credential represents authorship vs supervision vs direction. Manav defines the three roles and their cryptographic distinctions.
• Trust scoring. VC produces unscored claims; Manav aggregates them into a portable Trust Score with selective-disclosure proofs.
• Settlement. VC has no economic primitive. Manav settles via $MANAV and integrates with x402 for agent payments.
• Article 14 audit format. VC supports the cryptographic primitives; Manav structures them into the artifact a regulator will read.

Use VC standards directly when

You are building infrastructure that other people's wallets and verifiers must interoperate with. The standard is what makes them interoperate. SpruceID, Privado, and Polygon ID all do this well; their products are layers above the W3C primitives, similar in spirit to Manav but narrower in scope.

Use Manav when

You need the wallet, the verifier, the registry, the delegation primitive, the trust score, the audit format, and the settlement layer in one stack — and you need them to satisfy Article 14 by today. Building this on top of raw W3C VC is doable but takes 12–18 months. Most teams don't have the time.

The good news

Manav is open about its W3C compatibility. A credential issued via Manav is a valid VC. A VC issued via SpruceID can be presented to Manav-compatible verifiers. The protocols compose. The choice is buy-vs-build, not VC-vs-Manav.

Common objections

Buyers reasonably ask: do we have to choose? No. Most production stacks run both — the incumbent for the layer it owns, the new category for the layer the incumbent does not. The category split is real; the integration is clean; the procurement question is sequencing, not selection.

Frequently asked questions

Why not just use the incumbent for both? Because the incumbent was built for the previous problem. The fact that the workflow looks similar masks an architectural mismatch the incumbent cannot fix without rebuilding. We respect the incumbent; we do not pretend they ship the answer.

Where does the incumbent still win? In its native category. Use the incumbent where it was designed to operate; use the new layer where the new category begins. Most production stacks end up running both, with a clean handoff between them.

How long until we have to choose? You don't, mostly. The clean integration runs both side-by-side. The choice arrives only when a procurement contract forces consolidation, and by then the data on which layer is doing the work is usually clear.

Where to start

To go deeper, read manav vs ssi vendors for the architectural diff and ssi without crypto headache for the broader vendor map. Most procurement teams converge on the same composition — incumbent plus the new layer — once they have walked both.

Where the W3C standard helps Manav

We are not competitive with the W3C Verifiable Credentials standard; we are a profile of it. The standard supplies the data model, the proof formats, the wallet primitives. Manav supplies the delegation semantics, the magnitude caps, the witness binding, the regulator-graded audit log. A Manav-issued credential is a W3C-VC-compliant credential with additional fields the W3C did not specify. The relationship matters because procurement teams ask "is this a standard or a vendor lock-in?" The honest answer is both, in different layers. The credential is a standard; the delegation profile is a vendor specification we are pushing to standardize. We have published the schema. We are participating in the working group. The lesson from past identity waves is that vendor-specific extensions to standards either get absorbed back into the standard or become the proprietary lock-in the procurement team feared. We are working hard to be in the first category.

VC is the rail standard. Manav is the train you can actually ride.