Stelais vs C2PA: What Content Credentials Can’t Do

C2PA — the Coalition for Content Provenance and Authenticity — is the most significant industry effort to date to solve the content authenticity crisis. Backed by Adobe, Microsoft, Google, OpenAI, Intel, Leica, Nikon, and others, it defines an open standard for attaching cryptographic metadata to media files: who created them, how they were edited, and whether AI was involved. If you work with digital content, C2PA matters. It is the foundation of what Adobe calls Content Credentials, and it is being embedded into cameras, editing software, and social platforms at accelerating pace.

This page is not an argument against C2PA. It is an argument that C2PA solves the authentication problem but leaves the permanence problem entirely unaddressed — and for creators, the permanence problem is the one that actually determines whether your provenance survives contact with the real world.

What C2PA Does Well

C2PA deserves recognition for what it accomplishes. Before C2PA, there was no standardized, cryptographically verifiable way to attach origin information to a media file. EXIF data was trivially editable. Watermarks were lossy and proprietary. Platform-specific metadata was siloed and non-portable.

C2PA solved these problems with a technically sound architecture:

• Cryptographic signing. Content Credentials use X.509 certificates to sign a manifest that binds content to a set of assertions about its origin and edit history. The signature is mathematically verifiable.
• Chain of custody. Each edit, export, or transformation can add its own signed assertion to the manifest, creating a verifiable history of how a file moved from creation to publication.
• Industry adoption. Adobe Photoshop, Lightroom, Firefly, Microsoft Bing Image Creator, Leica cameras, and Google's SynthID all integrate C2PA in some form. This is real deployment, not vaporware.
• Open standard. The C2PA specification is publicly available, and the reference implementation (c2pa-rs) is open source. Anyone can verify a Content Credential without vendor lock-in.

For the problem of “is this photo authentic and unmanipulated,” C2PA is a strong answer. For the problem of “can I permanently prove I created this work,” it is not.

The Five Gaps

The limitations below are not theoretical edge cases. They are structural properties of C2PA's architecture that affect every creator who depends on provenance for legal protection, licensing enforcement, or AI training consent.

1. Metadata stripping

C2PA credentials are embedded in the file itself — typically as JUMBF (JPEG Universal Metadata Box Format) data within the media container. When a file passes through a system that does not support C2PA, the credential is stripped. This is not a bug in those systems. It is the default behavior of virtually every content pipeline on the internet.

• Social media platforms routinely strip or re-encode uploaded images, discarding embedded metadata in the process.
• Content management systems, email clients, and messaging apps re-compress images on upload.
• AI training pipelines extract plain text from WARC files, discarding all container-level metadata including any C2PA manifests.

C2PA acknowledges this gap with “soft bindings” — perceptual hashes that can survive re-encoding and link back to a credential stored on a separate validation server. But soft bindings require that the validation server remains operational, that the platform checking the content supports the lookup protocol, and that the hash survives the specific transformation applied. Each of these is a point of failure that reduces the credential from proof to probability.

A credential that survives only when every intermediary cooperates is a signal, not a proof. The distinction matters when the intermediary is an AI training pipeline that processes petabytes without examining metadata.

2. Certificate authority dependency

C2PA credentials derive their trustworthiness from X.509 certificates issued by certificate authorities (CAs). This is the same trust model used by HTTPS — and it inherits all of the same structural risks.

• Certificates expire. A Content Credential signed with a certificate that has since expired requires timestamp verification to confirm it was valid at signing time — adding complexity and a dependency on timestamping authorities.
• Certificates can be revoked. If a CA is compromised or changes its policies, credentials signed under that CA's certificate chain become unverifiable or untrusted.
• Trust lists are maintained by organizations — the C2PA Trust List, or individual platform trust stores — that can change their inclusion criteria at any time. A credential that is trusted today may not be trusted tomorrow if the issuing CA is removed from the trust list.

For short-lived authentication (verifying a photo is unmanipulated when you view it), this model works well. For long-lived provenance (proving you created something five years from now in a legal proceeding), it introduces dependencies on institutions that may not exist, may have changed their policies, or may have been acquired.

3. No on-chain permanence

C2PA credentials are stored in one of two places: embedded in the file, or on a validation server maintained by the credential issuer. Neither location is permanent in the architectural sense.

Embedded credentials are lost when the file is re-encoded (see gap 1). Server-stored credentials persist only as long as the server operator maintains them. There is no protocol-level guarantee of permanence. Adobe could shut down its Content Credentials cloud service. A startup issuing credentials could go bankrupt. A platform storing credential lookups could deprecate the API.

This is not hypothetical. The history of digital infrastructure is littered with services that were “permanent” until they weren't — Google Reader, Geocities, Vine, and countless others. For a creator whose livelihood depends on provenance, “the company promises to keep the server running” is not a sufficient guarantee.

4. No consent encoding

C2PA's specification focuses on authenticity and provenance — who created the content, how it was modified, and whether AI was involved. It does not include a standardized mechanism for encoding licensing terms or AI training consent preferences.

A C2PA credential can tell you that a photograph was taken by a specific photographer with a specific camera. It cannot tell you whether that photographer consents to the image being used in AI training, under what terms, or with what compensation requirements. The credential answers “who made this?” but not “what can you do with it?”

For the AI training consent crisis — which is the central provenance problem facing creators today — this is a critical gap. Proving authorship without encoding consent leaves the hardest part of the problem unsolved.

5. Voluntary adoption

C2PA is an opt-in standard. No law requires platforms to preserve Content Credentials on upload. No regulation mandates that AI training pipelines check for or respect C2PA manifests before ingesting content. Adoption depends entirely on voluntary industry participation.

This creates a structural asymmetry: creators bear the cost of generating credentials, but the parties who most need to respect those credentials — AI training pipelines, content aggregators, social platforms — face no consequence for ignoring them. The value of a provenance system that only works when the party you're trying to hold accountable voluntarily cooperates is, for enforcement purposes, limited.

The Comparison

The table below compares C2PA and Stelais across the dimensions that matter most for creator provenance.

Signal Layer vs Proof Layer

The cleanest way to understand the relationship between C2PA and Stelais is as two layers of a complete provenance stack.

C2PA is a signal layer. It tells you that a credential exists and is well-formed. It attests to the authenticity and edit history of a specific file at a specific moment. Its guarantees are contingent on the file remaining intact, the certificate chain remaining valid, and the verification infrastructure remaining operational.

Stelais is a proof layer. It tells you that a specific creator registered a specific work at a specific time, with specific consent terms, and that this record exists permanently on a decentralized ledger that no single party can modify or delete. Its guarantees are independent of any file format, any platform, any certificate authority, and any corporate infrastructure.

These are not competing standards. They are complementary architectures that address different failure modes. C2PA handles real-time authentication — verifying that a photo you're looking at right now is genuine. Stelais handles permanent provenance — proving five years from now that you created a work, when you created it, and what terms you set for its use.

C2PA answers: “Is this file authentic?” Stelais answers: “Can I prove I made this, permanently, regardless of what happens to the file?”

Why This Matters for AI Training

The AI training pipeline is where the distinction between signal and proof becomes existential for creators. When an AI company builds a training corpus from Common Crawl data, the pipeline processes petabytes of content through extraction, filtering, and deduplication stages that strip all container-level metadata. C2PA credentials embedded in image files are discarded. Soft-binding lookups are not performed. The content enters the training set as raw data with no provenance attached.

A Stelais proof, by contrast, exists on Arweave independently of the content's journey through any pipeline. An AI company that wants to verify the provenance of a training document needs only the content hash — computable from the extracted text — and access to the Arweave ledger, which is public and permanent. The proof does not need to survive the pipeline because it was never in the pipeline. It exists alongside it, permanently and independently.

This architectural independence is what makes consent enforceable at the training layer. A creator's Stelais record includes their explicit AI training consent preferences. An AI company can check those preferences before ingesting the content — not because the platform cooperated, not because the file metadata survived, but because the proof is on a permanent public ledger that anyone can query.

Who Should Use What

If you are a photographer or videographer whose primary concern is real-time image authenticity — proving to viewers that a photo is unmanipulated — C2PA Content Credentials are directly useful. Use them. They solve that problem well.

If you are a creator whose work may be scraped for AI training, whose copyright may be challenged, or who needs permanent proof of creation for legal or licensing purposes, you need a proof layer that exists independently of any file format or platform. That is what Stelais provides.

If you care about both — and most professional creators should — the answer is both. C2PA for real-time authenticity. Stelais for permanent provenance. The strongest position is a signal that can be verified in the moment, backed by a proof that exists forever.

Learn more about why Stelais uses Arweave for permanent provenance and why AI training data has a provenance problem.

Key References

C2PA Standard: C2PA Technical Specification 2.2 / 2.3. Coalition for Content Provenance and Authenticity (2024–2025).

Content Credentials: Adobe Content Authenticity Initiative, “Content Credentials: Overview and Implementation” (2024).

Government Guidance: NSA/CISA, “Strengthening Multimedia Integrity in the Generative AI Era” (January 2025).

WARC Architecture & Training Pipelines: Common Crawl Foundation technical documentation. NVIDIA NeMo Curator pipeline documentation.

Model Collapse & Data Quality: Shumailov, I. et al. “AI models collapse when trained on recursively generated data.” Nature 631, 755–759 (2024). Dohmatob, E. et al. “Strong Model Collapse.” ICLR 2025.