How ArcVelvet works
A plain-language walk-through, for readers who have never encountered C2PA or provenance infrastructure before.
The problem this addresses
Creators making work in the AI era face a question of how authorship gets documented when the tools that produce work are mixed. Sometimes the work is entirely human-made. Sometimes it uses AI as a tool, the same way a photographer uses a camera or a designer uses a brush. Sometimes the line between the two is genuinely blurry. Existing systems for documenting authorship (copyright registration, blockchain-based ownership claims, metadata fields that get stripped on the first re-upload) all have known gaps. ArcVelvet's answer is provenance at creation: a cryptographic signature applied at the moment the creator uploads the work, embedded inside the file itself, verifiable forever by anyone with a C2PA reader.
The phrase to remember is the signature travels with the file. Not in a database. Not on a blockchain. Inside the file's own metadata. When the file gets shared, sold, downloaded, or re-uploaded somewhere else, the authorship claim is still attached.
The user journey, step by step
Whether you painted, photographed, composed, wrote, recorded, programmed, or used AI tools as part of the process, the work exists when you have a file you want to put your name on. ArcVelvet does not care what tools you used. It cares that you are willing to assert authorship of the file and that you can disclose, accurately, what was involved in making it.
When you upload, the platform applies a cryptographic signature using your authorship claim and the platform's certificate. The signing happens server-side, in a Cloud Function, using the c2pa-node library which wraps the C2PA reference implementation written in Rust. You see this as a progress indicator and a confirmation. Under the hood, the platform is computing the signature, embedding it in the file, and writing the C2PA manifest into the file's metadata structure.
This is the part that distinguishes provenance from registration. There is no separate database entry that the signature points to. The signature lives inside the file. For images, it goes into a JUMBF container in the file's metadata. For audio and video, it goes into the appropriate format-specific metadata location. For supported formats (JPEG, PNG, WebP, TIFF, MP4, MOV, WAV), the embedding is invisible to normal use of the file. The signature does not change how the file looks, sounds, or plays. It does change what a verifier can prove about the file.
You share the file on social media, sell it through ArcVelvet's marketplace, license it to a buyer, post it to your own website, send it to a client, or drop it on a hard drive for safekeeping. Wherever the file goes, the signature goes with it. The signature is not stripped when the file gets downloaded. It is not stripped when the file gets re-uploaded somewhere else. It can be stripped by deliberate metadata removal, but the act of stripping is itself detectable, and the original file on ArcVelvet remains the signed reference.
A buyer, a researcher, a journalist, a publishing house, or anyone with a copy of the file can verify the signature using any C2PA-conformant tool. The three readily available verifiers are Adobe's Content Authenticity inspector (a browser extension and a web tool at contentcredentials.org), the contentcredentials.org public verifier, and ArcVelvet's own verifier endpoint at /verify. The verification confirms the authorship claim, the timestamp, the signing certificate, and the integrity of the file's bytes since signing.
Not in a platform you have to trust. Not on a service that might go offline. The signature is a property of the file. If ArcVelvet disappeared tomorrow, every file already signed would continue to verify against the C2PA standard, using the same external tools, with no dependency on the platform staying online. This is the architectural commitment named in the trust documentation: provenance infrastructure has to outlast the platform that produced it.
What the signature claims, and what it does not claim
Honest framing matters here because the question of what a cryptographic signature proves is genuinely contested in the broader provenance discourse.
What the signature claims: the file was uploaded to ArcVelvet at a specific timestamp, under a specific authorship claim, by an account that controlled the platform's signing key at the moment of signing. The bytes of the file have not changed since signing (any modification would invalidate the signature). The disclosed tool-chain (if the creator disclosed any AI tools, source materials, or collaborators) is part of the signed record.
What the signature does not claim: that the work is original in any metaphysical sense. That the creator owns the underlying rights. That the work has not been derived from other sources. That the authorship claim is true in a way a court would accept as decisive evidence. That the work is good, valuable, or legally protectable. These are separate questions from the cryptographic record, and we treat them as separate.
The signature is a verifiable claim about a moment in time. It is not a substitute for copyright, contracts, or human judgment about whether a work is what it claims to be.
What happens if you stop using ArcVelvet
This is the question the architecture is designed around. Three specific facts:
Files already signed continue to verify. The cryptographic record is in the file. A buyer who purchased rights from you in 2026 can still verify the file in 2030, using a C2PA reader, with no involvement from ArcVelvet. The signature is durable past account closure, past platform shutdown, past the SSL.com cert rotation, past whatever happens to the company.
The deletion policy preserves what has been transacted. If you delete your account, the platform's policy is to preserve signed-on records of work that has associated sales, with your authorship attribution replaced by "Account Deleted" in the platform's user-facing surfaces. This is so buyers retain verifiability of what they purchased. The cryptographic record stays intact. The full deletion policy is documented in the trust page at /trust.
Recovery is supported. If you have funds owed to you at the time of deletion, the platform attempts a Stripe payout. If the payout fails, the funds go into a 12-month escrow window during which you can recover them by email-verified request, even with the account already closed. The recovery flow does not require the account to still exist.
What signing AI-involved work means
ArcVelvet signs work that involves AI tools the same way it signs work that does not. The signature itself does not change. What changes is the disclosure inside the signed manifest. Creators can declare which models, prompts, source materials, and collaborators were involved. The disclosure becomes part of the signed record, verifiable in the same way the signature is verifiable. The platform's posture on this is informed by the Thaler v. Perlmutter ruling: copyright requires human authorship. The signature records the human's authorship claim and the disclosed tool-chain. It does not adjudicate whether the work is copyrightable. That is a question for the human and their counsel.
Common questions
The full FAQ is at /faq and covers the dozen questions first-time visitors most often ask. The reference page at /references documents the standards and external work the platform implements and references. The trust page at /trust is the source-of-truth for the platform's operational posture, written for peer architects who want to verify claims against the live code.