ProofPack vs W3C Verifiable Credentials: An Honest Comparison

27 Jun 2026

27 Jun 2026 by Luke Puplett - Founder

The decentralized identity space is crowded with acronyms. W3C VCs, SD-JWT, OID4VC, DIDs, BBS+—it can feel like you need a decoder ring before you can have a conversation. At the same time, ProofPack has taken a different path: a Merkle-based selective disclosure format built around blockchain attestations, portable files, and delegation chains for the agentic economy.

This post maps the two worlds against each other. We'll be specific about where they overlap, where they genuinely differ, and where each approach has the stronger answer. If you're evaluating selective disclosure infrastructure for your product—whether for identity, supply chain, RWAs, or AI agent credentials—this is the comparison we'd want to read ourselves.

First: three things the W3C stack often conflates

Before comparing anything, it's worth separating three concepts that are frequently bundled together in "W3C VC" discussions. They operate at different layers and can be mixed and matched independently.

• W3C VC Data Model — the format. Defines a standard JSON-LD structure with an Issuer, Credential Subject, Claims, and a Proof. Importantly, VC 2.0 is deliberately proof-format agnostic: the proof could be a Data Integrity proof, an SD-JWT, JOSE/COSE, or BBS+. There is no single canonical proof block.

• OID4VC (OpenID for Verifiable Credentials) — the transport layer. Built on OAuth 2.0 and OIDC, it defines two specs: OID4VCI for credential issuance (wallet requests a credential from an issuer) and OID4VP for credential presentation (a relying party requests specific claims from a wallet). OID4VC solves wallet interoperability—it does not define the credential format itself.

• SD-JWT (Selective Disclosure JWT) — a specific proof format. Claims are broken into individual salted hashes embedded inside a JWT; only the salts for disclosed fields are shared with the verifier. This is the most common selective disclosure mechanism in the enterprise VC world today.

Conflating these three is the most common source of confusion in identity discussions. OID4VC doesn't require SD-JWT. SD-JWT doesn't require OID4VC. The VC Data Model supports both. Keeping the layers separate makes the ProofPack comparison much cleaner.

What ProofPack is—and what it isn't

ProofPack is often described as an identity format, but that undersells it. It is a general-purpose selective disclosure and attestation framework. Identity is one application. The documentation is explicit about the broader scope: invoices, insurance quotes, real-world asset tokenization, supply chain provenance, and AI agent delegation are all first-class use cases.

The format has three nested layers:

• Merkle Exchange Document — the innermost layer. The original data (a passport, an invoice, a bank statement) is structured as a flat set of salted leaf hashes rolled up to a single root hash using Merkle combination. Each leaf can be revealed or withheld independently. The spec explicitly calls this a "Merkle-inspired hash set" rather than a traditional Merkle tree—it's optimized for short records where most fields will be revealed, not for large datasets and proof-of-membership.

• Attested Merkle Exchange Document — wraps the Merkle document with blockchain attestation metadata: network, attestation UID, attester and subject addresses, timestamp, and nonce. The attestation links the Merkle root to the chain.

• JWS Envelope — the outermost layer. A standard JSON Web Signature wraps everything, providing cryptographic signatures that can be verified without touching the blockchain. Can be serialized as a compact JWT for use in HTTP headers.

The design separates concerns deliberately: the JWS protects transport integrity, the attestation anchors trust, and the Merkle structure handles selective disclosure. Each layer can be verified independently.

Comparing the approaches

With the layers clear, here is how ProofPack maps against the W3C VC stack across the dimensions that matter most:

Dimension	W3C VC / OID4VC Stack	ProofPack
Primary scope	Identity credentials	General selective disclosure (identity, invoices, supply chain, RWAs, agent delegation)
Trust anchor	Issuer identity (DID or X.509/Web PKI) + signature	On-chain attestation + Merkle root binding
Selective disclosure	SD-JWT (salted per-claim hashes inside a JWT) or BBS+ signatures	Merkle-inspired hash set: salted leaf hashes, same root maintained regardless of which fields are revealed
Transport	OID4VC (OAuth/OIDC native, deep wallet integration)	Transport-agnostic: downloadable file, email attachment, HTTP header (Bearer JWT), API, URL—no wallet infrastructure required
Attestation model	Issuer's DID resolves to a public key; signature chain to trust registry	Attestation service abstraction (EAS on Base is the current implementation; architecture is not inherently EAS-specific)
Delegation / agentic use	Nascent; usually handled via custom VC schemas or capability invocation extensions	Native IsDelegate chain (human → agent → sub-agent), on-chain via EAS refUID; verifiable by wallet lookup without requiring the agent to present a JWS
Blockchain dependency	Optional; many deployments use did:web (no chain required)	Attestation layer requires a supported chain; JWS layer verifiable offline
Enterprise integration	Deep: OAuth/OIDC native, existing wallet ecosystems, enterprise SSO compatible	Requires ProofPack library (npm or NuGet); no wallet software needed to consume a proof
IAL2 identity proofing	Orthogonal—IAL2 is the process assurance level, not the credential format	Orthogonal—Zipwire Attest uses IAL2-equivalent identity proofing before issuing attestations; this is not part of the ProofPack format itself

The deeper architectural difference: what is actually being trusted?

The most significant difference between the two approaches isn't in the feature table—it's in the underlying trust model.

In the W3C VC world, trust flows from the issuer's identity. A verifier resolves the issuer's DID to a public key, checks the signature, and decides whether to trust that issuer (often by looking them up in a trust registry). The credential is as trustworthy as the issuer.

In ProofPack, trust flows from the attestation. The Merkle root is attested on-chain by an attester address. The verifier decides which attester addresses to trust—and if the Merkle root in the proof matches what was attested, the disclosed fields are cryptographically bound to that attestation. The JWS protects the transport, but the attestation is the primary object being trusted.

This is subtle but consequential. In the VC model you're asking "Do I trust this issuer?" In ProofPack you're asking "Do I trust this attester, and does the proof bind to what they attested?" The binding is tighter because the Merkle root links the specific proof document to the specific on-chain event—not just to the issuer's identity in general.

It also means the trust model is open by design. Any KYC provider, bank, or government portal can issue attestations. Verifiers configure which attester addresses they accept. The infrastructure is shared; the trust decisions are local.

Selective disclosure: Merkle hash set vs SD-JWT

Both approaches solve the same problem—letting a holder reveal a subset of their claims without invalidating the proof—but with meaningfully different mechanisms.

SD-JWT breaks claims into individual disclosures at issuance time. Each claim gets a random salt, is hashed, and that hash is embedded in the JWT. To disclose a claim, you share the salt and original value; the verifier recomputes the hash. Claims not disclosed simply aren't presented—their hashes sit in the JWT as commitments.

ProofPack's Merkle hash set works differently. The original document is structured as a flat set of leaves (one per root-level field), each salted and hashed. Those leaf hashes combine—using Merkle combination—to produce a single root hash, which is what gets attested on-chain. To disclose a field, you reveal its data and salt; to hide it, you include only the hash. The root recomputes correctly either way. The same root hash is always attested, regardless of which combination of fields a given presentation chooses to reveal.

The practical implication: with SD-JWT, the issuer's JWT contains all the claim hashes up front. With ProofPack, the attested root is all the chain knows about—the selective presentation is constructed from the leaf hashes alone, post-attestation. A holder can construct multiple different presentations from the same attested root without the issuer being involved again.

Neither approach is strictly superior; they suit different operational models. SD-JWT is deeply integrated with the JOSE ecosystem and straightforward to implement in OAuth flows. ProofPack's Merkle approach integrates naturally with blockchain attestation and produces smaller on-chain footprints (only the root hash is stored).

One trade-off worth acknowledging: because the Merkle root is identical across all presentations derived from the same attestation, it can act as a correlation vector. Two verifiers who collude could link separate presentations from the same user via that shared root hash. SD-JWT avoids this because each presentation can use independently hidden salts with no shared public identifier. ProofPack optimizes for data integrity and verifiable on-chain state rather than strict unlinkability—which is the right trade-off for most B2B and agentic workflows, where the goal is trust, not anonymity. Where absolute unlinkability is required, a fresh attestation with a new root can be issued for each context.

Can you convert a ProofPack into a W3C VC?

Mostly, but not losslessly—and it's worth being precise about what "conversion" means here.

The claim mapping is straightforward. A ProofPack's JSON payload maps naturally to a credentialSubject in a W3C VC. That part is easy.

The selective disclosure mechanism, however, cannot be directly translated. ProofPack and SD-JWT use different commitment schemes. In a fully-revealed ProofPack, the hex-encoded source data and salts are present in the leaves—so the raw material is technically available. But the hash structure is incompatible: ProofPack hashes each leaf as SHA256(concat(data_hex, salt_hex)) and then rolls all leaf hashes up through binary Merkle combination to a single root. SD-JWT hashes claims individually with no cross-claim commitment—there is no Merkle root. The two schemes make fundamentally different mathematical promises about the data. You cannot derive SD-JWT disclosures from ProofPack leaf hashes; you would need to re-salt, re-hash, and restructure from scratch under a different commitment model. You are not converting a proof; you are producing a new one.

The attestation is similarly not portable directly. The EAS attestation UID could become a credentialStatus reference, an evidence entry, or a custom extension in the VC, depending on the VC profile you're targeting. The JWS over the ProofPack payload is not automatically a VC-compliant signature suite—a new VC signature (e.g. JsonWebSignature2020) would need to be applied.

Once formatted as an SD-JWT VC or JSON-LD VC, any OID4VP-compliant wallet could request and present it. So ProofPack's underlying data is compatible with the enterprise VC ecosystem—it just requires re-issuance, not a format converter.

Where the W3C VC stack has the stronger answer

It's worth being direct about where the enterprise VC stack has genuine advantages.

Wallet ecosystem integration. OID4VP is supported by a growing number of digital wallets and identity providers. If your users already have a W3C-compatible wallet, they can present credentials without any new infrastructure. ProofPack currently requires either the ProofPack library on the verifier side or an integration with Zipwire's APIs.

No blockchain required. did:web and similar DID methods let you run a verifiable credential ecosystem entirely without a public chain. For regulated industries or jurisdictions where public blockchain usage is complicated, this matters.

Standardization and interoperability. The VC data model, SD-JWT, and OID4VC are IETF and W3C standards with multiple independent implementations. An SD-JWT VC from one provider can be verified by any compliant verifier. ProofPack is open source but not yet a ratified standard—though it is worth noting that ProofPack does not invent new cryptographic primitives. It composes well-established, standards-track components: JWS (RFC 7515), standard hashing algorithms (SHA-256), and Merkle combination. The novelty is in the architecture, not the ciphers. Enterprise procurement teams who need a rubber stamp will still want formal ratification; teams who evaluate the primitives directly will find nothing exotic.

Enterprise SSO compatibility. Because OID4VC is built on OAuth 2.0 and OIDC, it slots into existing enterprise identity infrastructure without requiring new protocols. For organizations already invested in that stack, the integration path is well understood.

Where ProofPack has the stronger answer

Agentic delegation. The IsDelegate chain (human → agent → sub-agent) with on-chain attestation via EAS refUID is a native, first-class capability. A backend can verify not just a claim but the entire delegation lineage, cryptographically, without calling an identity provider. In the W3C VC ecosystem, delegation between agents is still largely handled through ecosystem-specific extensions with no standardized interoperability story. If you are building infrastructure for autonomous agents, ProofPack has a concrete, deployed answer today.

Transport agnosticism and general-purpose data sharing. A ProofPack is a file. It can be emailed, downloaded, attached to a webhook, passed in an HTTP header, or embedded in a URL—without any wallet software on either side. The W3C VC ecosystem was designed around credential presentation flows where both parties run compatible wallet infrastructure. ProofPack deliberately makes no such assumption: a recipient needs only the ProofPack library to verify, and a sender needs only to share a file. This makes it practical for the full breadth of verifiable data sharing—not just identity—including attaching a verified invoice to an email, sharing a redacted bank statement as a file upload, or embedding a selective proof in an API response. Where the VC stack asks both parties to adopt a new protocol, ProofPack asks them to share a document.

Broader use case coverage. Because ProofPack is a general selective disclosure container—not specifically an identity credential format—it applies naturally to invoices, bank statements, insurance quotes, RWA tokenization, and supply chain provenance. The W3C VC data model can technically be stretched to cover some of these, but it was designed for identity credentials and shows its seams outside that domain.

Tighter attestation binding. The Merkle root in a ProofPack binds the specific proof to the specific attestation. A verifier can confirm that the fields being presented were part of the exact document that was attested on-chain. This is a stronger guarantee than verifying that an issuer's DID key signed a credential that claims certain things—because the binding is to the data structure itself, not just to the issuer's authority.

A note on NIST IAL2

IAL2 comes up frequently in identity discussions alongside VCs and ProofPack, so it's worth placing it correctly. IAL2 is a process assurance level—it describes the rigour of the identity proofing process (government ID verification, remote biometric liveness check, binding to the real person). It is not a credential format or a cryptographic protocol. Any issuer, whether using W3C VCs or ProofPack, can perform IAL2-equivalent identity proofing before issuing. Zipwire Attest uses IAL2-grade processes before anchoring a human attestation on-chain; that assurance level is independent of the ProofPack format itself.

The identity proofing behind Zipwire's ProofPack issuance is powered by Yoti, whose digital identity technology is certified by NIST under the National Voluntary Laboratory Accreditation Program (NVLAP) for biometric testing. Yoti's liveness detection and document verification have been independently validated against NIST standards—the same body that defines IAL2. This means that when Zipwire issues a ProofPack backed by a human attestation, the underlying identity proofing rests on independently accredited, NIST-approved technology, not just a vendor's self-assessed compliance claim.

Which to choose

The two approaches are not mutually exclusive, but they do suit different contexts.

The W3C VC stack makes more sense if you are integrating with existing enterprise identity infrastructure, targeting users who already have W3C-compatible wallets, operating in a jurisdiction where public blockchain usage is restricted, or building something that needs to interoperate with standardized VC ecosystems today.

ProofPack makes more sense if you are building for the agentic economy (delegation chains, MCP servers, autonomous agents), need selective disclosure outside the identity domain (invoices, supply chain, asset tokenization), want proofs that work without wallet software on either side, or want attestation that binds specifically to a data structure on-chain rather than to an issuer's general signing authority.

For identity specifically, the two are converging in practice: ProofPack's JWS envelope is JOSE-compatible, and the future direction in the docs explicitly describes a path toward JWT-embedded VCs that combine ProofPack's Merkle attestation with W3C credential structure. The primitives are compatible; the ecosystems are not yet connected.

Getting started

If you want to explore ProofPack:

• GitHub: github.com/zipwireapp/ProofPack — source, spec, and examples

• npm: npm install @zipwire/proofpack @zipwire/proofpack-ethereum

• NuGet: dotnet add package Zipwire.ProofPack Zipwire.ProofPack.Ethereum

• Attestation: zipwire.io/attest to get your human attestation on Base

For the delegation and agent use case specifically, see our earlier posts: When Agents Come Calling covers the IsDelegate flow end to end, and ProofPack and Real-World Asset Tokenization shows the same Merkle primitives applied outside the identity domain.

---

Learn more