About ArcVelvet

Creator-side provenance infrastructure built on the C2PA open standard.

What ArcVelvet is

ArcVelvet is a platform that lets creators cryptographically sign their work at the moment of creation, so the chain of authorship survives wherever the work travels. The signature is embedded directly inside the file using the C2PA standard, not stored in a database the file has to call home to. When the file moves from ArcVelvet to a social platform, a marketplace, an archive, or a hard drive somewhere, the authorship claim moves with it.

The core proposition is narrow on purpose: provenance at creation, for working creators, using open standards. Not a marketplace primarily. Not a blockchain anything. Not an enterprise asset management system. A signing surface that produces files third-party tools can verify, paired with the platform features that make signing the natural part of a creator's workflow rather than an extra step.

The platform ships two related surfaces on a shared cryptographic substrate. The first is the ArcVelvet marketplace, where creators publish signed work, license it to buyers, and receive provenance-attached sale records. The second is ARC, a provenance kit that signs anything photographable with documentation of the making, from physical goods through documented creative practice. Both surfaces produce C2PA-conformant files. Both verify against the same standards-body tooling. Both treat authorship as a property of the work, not a property of the platform.

Who built it

ArcVelvet is built by Pat Casino, sole founder of ArcVelvet Studios LLC, based in Ohio. The platform is a solo project, funded by personal time and resources, built outside any institutional framework.

The honest framing on credentials: Pat is finishing a computer science bachelor's degree while shipping the platform. The work is undertaken with no university affiliation, no faculty advisor, no institutional research support. The standards-community engagement, the C2PA implementation, the substrate-level architectural decisions, and the public-facing surfaces have all been built and shipped by one person on personal time.

This is presented as context rather than disclaimer. The platform is small but the work is serious. The C2PA infrastructure is real. The trust document at /trust is the operational source-of-truth that an external peer architect can verify against the live code. The certificate posture is honestly disclosed as pre-production with an SSL.com cert in transit. The deletion flow respects user rights with a 30-day grace period and a documented escrow mechanism for non-zero balances. The decisions a serious-but-small team makes are visible throughout.

Why it exists

Two through-lines shape the architecture, and both deserve to be named directly.

Built to outlast the architect. Provenance infrastructure that depends on a single platform staying online is not provenance infrastructure. It is a database with a marketing surface. The signature on an ArcVelvet-signed file is verifiable using Adobe's Content Authenticity inspector, contentcredentials.org, or any C2PA-conformant verifier, with no dependency on ArcVelvet remaining operational. The file is the artifact of record. The platform is the place where signing is convenient. When the platform changes hands or ceases to exist, the files already signed continue to verify, because the cryptographic record lives in the file rather than in a service.

Making versus keeping. Authorship is a continuous practice, not a single event at the moment of creation. A creator who signs a work on ArcVelvet is not making a one-time claim of origin. They are entering an ongoing relationship with the work, where future actions on it (revising, selling, retracting, deleting an account that signed it) all leave traces in the provenance record. The platform treats keeping a work as carefully as making it. The deletion policy preserves signed-on records for buyers who paid for verifiability. The reversal assertion documents sales that get rolled back. The chain-of-custody record for ARC items stays intact even when the vendor account closes. The premise underneath is that authorship is care that continues, and the infrastructure should reflect that.

What is different about ArcVelvet

The platform sits in a small but growing ecosystem of provenance work. Adobe's Content Authenticity Initiative tooling and contentcredentials.org address the verification surface. Camera manufacturers shipping C2PA-signed capture (Leica, Sony, Nikon) address the capture surface. The C2PA standards body itself, plus the CAWG creator assertions working group, address the substrate. ArcVelvet is positioned in the gap between capture and large-platform tooling: a place where individual working creators can sign their own work without owning a Leica or being a Reuters photographer.

The distinguishing posture, stated honestly:

• Provenance at creation, not after the fact. The signature is applied at upload, when the creator is asserting authorship in real time. This is different from systems that try to retroactively prove a file's provenance after it has been posted somewhere.
• No blockchain. The cryptographic substrate is COSE signatures inside C2PA manifests inside the file. Verification does not require a distributed ledger, a token, or a wallet. It requires a verifier that can read the C2PA spec.
• Open standard. The signature format is C2PA, the canonicalization is JCS (RFC 8785), the signature algorithm is ES256. A third party who wants to verify an ArcVelvet-signed file does not need ArcVelvet's permission or cooperation. They need a C2PA verifier.
• Single-creator scope. The platform is built for individual working creators rather than enterprise media operations. The pricing, the feature set, and the operational decisions follow from this.
• AI-aware without being AI-fixated. The signature documents what was uploaded by whom, when, with what disclosed tool-chain. It does not attempt to detect or judge whether the work was produced by AI. Disclosure is a creator's decision; the signature records the disclosure.

Operating posture

The platform is honest about the stage of its trust posture. Two specific facts:

The production cert is currently the c2pa-rs pilot test fixture from the C2PA reference implementation, used in dev and pre-production deployments. The SSL.com production cert is pending issuance. The cutover to the production cert is a single env-var flip plus a Secret Manager rotation, with no code changes required. Manifests signed under the pilot fixture remain cryptographically verifiable after cutover, because manifest validity is a property of the signature over the manifest, not of the issuer's trust-list status at any given moment. The full operational detail is in the trust document.

The standards-body engagement is at the implementer level. ArcVelvet is not a paying member of C2PA. The platform implements the C2PA specification, ships C2PA-conformant manifests that verify in standards-community tooling, and engages with the community as a practitioner. Membership is on a separate track, treated as a function of platform maturity rather than a precondition for the work.

Operational documentation is published openly. The trust infrastructure document at /trust describes what the platform trusts, how, and where the trust model has known gaps. The security policy at /security-policy documents the vulnerability disclosure process. The accessibility statement at /accessibility documents the platform's accessibility commitments and known gaps. These are the artifacts an external auditor, a peer architect, or a curious user can read to calibrate the platform's claims against its operating reality.

How to engage

The platform welcomes outreach from researchers, standards-community participants, working creators, and curious peers. Email arcvelvet@arcvelvet.com with whatever you want to discuss. The trust documentation is the recommended starting point for technical readers. The how-it-works page at /how-it-works is the recommended starting point for readers new to provenance infrastructure. The references page at /references documents the standards, specifications, and external work the platform implements and references.