About ArcVelvet

Bring it or make it. Your art is yours, we just help you show it.

What ArcVelvet is

ArcVelvet is a no-subscription studio and marketplace for all your digital art. Bring work you already made, paintings, photos, music, any art, or make new work here in the studio. Either way, you own it, with a record of creation on every piece, and you sell it or license it in the same place, on your terms. The studio is one way in, not the only way.

There is no subscription and no monthly fee. You buy credits when you want them and pay only for what you make. Your work stays yours. It is never taken, never sold out from under you, and never used to train AI models.

Two surfaces run on the same foundation. The first is the ArcVelvet marketplace, where you publish your work, list or license it to buyers, and hand over a sale record with the record of creation attached. The second is ARC, a kit that signs anything you can photograph together with documentation of the making, from physical goods to documented creative practice. Both produce files that verify with open standards tools. Both treat authorship as a property of the work, not a property of the platform.

How it is built

The thing that makes this more than a generator is the record of creation. Whether you make a piece here or bring one you already made, ArcVelvet attaches a cryptographic record of who made it and when, embedded in the file itself on the open C2PA standard. The record is written when you add the work, not reconstructed after the fact, and it is not stored in a database the file has to call home to. When the file moves to a social platform, a marketplace, an archive, or a hard drive, the record moves with it, so your authorship travels with the work.

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 reconstruct 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.