18. RandProof Provenance: Content Authenticity and Chain of Custody

RandProofCertify (Section 9.1.4) is implemented and tested: a client hashes a file and registers it on-chain, and anyone can later verify a candidate

[Layer 1: Core, Design Stage]

RandProofCertify (Section 9.1.4) is implemented and tested: a client hashes a file and registers it on-chain, and anyone can later verify a candidate copy against that hash with a single public function call. RandProof Provenance is the next evolution of that primitive, extending a single hash registration into a capture-to-publish chain of custody, so that a piece of media can carry verifiable evidence of where it came from and whether it has changed since, rather than only a yes-or-no match against one registered hash.

RandProof Provenance does not replace RandProofCertify. Every provenance record is, underneath, a RandProofCertify registration; Provenance adds a chain-of-custody schema and a keeper-attested capture-time signature check on top of the existing register-and-verify mechanism Section 9 already specifies and has tested.

18.1 What This Product Is, Stated Precisely, Before What It Is Not

RandProof Provenance answers one question: does this piece of content match a chain of custody that was cryptographically registered at or near the moment of capture, and has it been modified since. It does not answer a different, harder question: is this content real, in the sense of not being AI-generated or manipulated. Those are not the same question, and the difference is not a technicality; it is the entire design boundary of this product, stated here as plainly as the fidelity-versus-correctness boundary already drawn for PoIF (Section 13.4) and the provenance-versus-fidelity boundary already drawn for PoRC (Section 13.4).

18.2 The Deepfake-Detection Problem RandProof Does Not Solve

Detecting whether an arbitrary, previously unregistered piece of media is AI-generated or manipulated is a machine-learning classification problem, not a consensus problem. No amount of keeper attestation can supply a verdict on content that carries no prior cryptographic signal from its moment of creation; keepers running a detection model and agreeing on its output would only prove the model ran consistently, not that its verdict is true, since detection models carry real, non-zero false-positive and false-negative rates. RandProof Provenance is deliberately not built to make this claim, and any integration or marketing of this product must not imply that it can look at an arbitrary video and declare it fake or real.

18.3 The Problem RandProof Provenance Does Solve

For content whose creator chooses to participate, a chain of custody can be established and later checked by anyone, with three components:

Capture-time signature: a camera, phone, recording device, or AI-generation tool signs the raw content with a device-held or software-held key at the moment of creation, the same model already standardized by the Coalition for Content Provenance and Authenticity (C2PA) for camera manufacturers and, increasingly, AI generation tools that choose to label their own output rather than conceal it.
Keeper-attested registration: the signed content hash and its capture-time signature are submitted to RandProof Provenance, where N keepers independently verify the signature chain, confirm the timestamp against an already-tested entropy/time source, and register the record on-chain, following the same commit-reveal-consensus pattern used throughout this document family.
Public verification: at any later point, anyone holding a candidate copy of the content can check it against the registry. A match confirms the content is unmodified since registration. A mismatch confirms modification since registration, not fakery in some absolute sense, a materially different and more defensible claim, stated precisely rather than oversold.

18.4 Execution Flow


Phase	Description
1. Capture-time signing	A participating device or tool signs raw content with a registered key at the moment of creation. This step occurs outside RandProof’s keeper network, at the creator’s own device or software, and is a precondition RandProof cannot enforce; it can only attest to signatures that already exist when a client submits them.
2. Registration request	The signed content hash, the signature, the signing key’s public identifier, and a claimed capture timestamp are submitted as a ProvenanceRequest, following the same request pattern as RandProofCertify (Section 9.1.4).
3. Independent verification	N keepers independently verify the signature against the claimed key and confirm the timestamp is plausible against an already-attested time source, following the same independent-check pattern used throughout RandProof Oracle (Section 14.2) and RandProof Identity (Section 15.2).
4. Commit-reveal and registration	Keepers commit and reveal their independent findings; consensus registers a ProvenanceCertificate on-chain, referencing the content hash, the signing key, the capture timestamp, and the participating keepers, using the same commit-reveal-consensus mechanism as RandProofCertify’s existing 2-of-3 agreement logic.
5. Public verification	Any party holding a candidate copy of the content computes its hash and checks it against the registry via a public function, following the same single-function verification pattern (verifyHash) already implemented and tested in RandProofCertify.

18.5 Key Registry and Revocation

A signing key used at capture time is only as trustworthy as the party or device that holds it. RandProof Provenance maintains a public key registry recording which keys are associated with which registered devices, software tools, or organizations, and supports key revocation: if a signing key is compromised or a device is decommissioned, its future registrations are flagged, without invalidating content already registered under that key before the compromise was discovered and disclosed.

Device and tool registration is voluntary and identity-disclosed at the registering party’s choice; RandProof does not itself vet or certify that a registering camera manufacturer or AI tool is who it claims to be, the same trust boundary already disclosed for RandProof Identity’s third-party credential attestation (Section 15.1).
A revoked key’s prior registrations remain on the permanent record, consistent with RandProof Audit’s permanence model (Section 16.2), with the revocation itself also permanently recorded, so a verifier can see both that content was registered under a key and that the key was later revoked, and reason about the gap between those two events.

18.6 AI-Generated Content: Honest Labeling Instead of After-the-Fact Detection

The most direct application of this product to the deepfake problem is not detection but disclosure. An AI generation tool that chooses to participate can sign its own output at the moment of generation, registering a ProvenanceCertificate that states plainly: this content was generated by model X, at time T, by tool Y. This does not stop a non-participating tool or a bad-faith actor from generating unlabeled synthetic content, the same limitation that applies to C2PA and every other opt-in provenance standard. It does mean that participating tools, and the platforms that choose to require or prioritize provenance-registered content, can offer a materially stronger authenticity signal than the current default of no signal at all.

18.7 Threat Model


Threat	Mitigation
Non-participating content has no provenance record at all	Disclosed explicitly as a fundamental limitation, not a gap to be closed; RandProof Provenance can only attest to content whose creator chose to register it, and absence from the registry is a weak, not a strong, negative signal.
A compromised signing key registers fraudulent provenance for manipulated content	Key revocation (Section 18.5) limits damage to the window between compromise and disclosure; a revoked key’s prior registrations remain visible with the revocation flag, letting a verifier weigh the risk rather than being silently misled.
A keeper falsely attests a signature or timestamp check	Same VRF-seeded keeper rotation and slashing model used throughout RandProof applies; a keeper’s false attestation diverging from independently-verified honest consensus is detectable and punishable identically to a false entropy, data-feed, or identity report.
Content is misrepresented as provenance-verified when it is only detection-scored	Addressed structurally by Section 18.2’s explicit scope boundary and by keeping any future detection-model integration, should one be added, as a clearly distinct, separately labeled product rather than folded into Provenance certificates.
A registered device or tool’s identity claim is false (the registering party is not who it claims to be)	Disclosed explicitly as outside RandProof’s scope, the same trust boundary already disclosed for RandProof Identity’s third-party credential attestation (Section 15.1); RandProof attests that a claimed key signed claimed content, not that the key’s registered owner is accurately identified.

18.8 Use Cases

[Layer 3] News organizations and wire services registering footage at capture, so viral clips claiming to originate from them can be checked against the registry before republication.
[Layer 3] Government agencies and courts requiring a verifiable chain of custody for video and image evidence, extending the same integrity guarantee already offered for reserve and custody attestation (Section 17) to evidentiary media.
[Layer 3] AI generation platforms choosing to label their own output at the point of creation, turning deepfake disclosure into an opt-in creation-time practice rather than an after-the-fact detection arms race.
[Layer 3] Social platforms and content aggregators surfacing a provenance-verified badge for registered content, the same pattern C2PA already established for camera-native photos, extended to a decentralized, keeper-attested registry rather than a single company’s signing infrastructure.
[Layer 2] BIT5050’s own winner-announcement and audit-relevant media, such as livestream recordings of raffle draws, registered at capture so entrants can verify a draw recording has not been altered after the fact.

18.9 What RandProof Provenance Does Not Claim

RandProof Provenance does not detect whether unregistered content is AI-generated or manipulated; it has no mechanism to evaluate content that was never signed at capture, and does not attempt to.
RandProof Provenance does not verify the real-world identity of a registering party; it verifies that a claimed key signed claimed content at a claimed time, consistent with the same identity-scope boundary already disclosed for RandProof Identity.
RandProof Provenance does not prevent the creation or distribution of unlabeled synthetic content by non-participating tools or bad-faith actors; it offers a positive signal for participating content, not a universal filter.
A hash mismatch against a registered original proves modification since registration, not that the modification was malicious or that the original claim of authenticity was itself accurate.

18.10 Honest Status

RandProof Provenance is an architectural extension of RandProofCertify.sol, which is implemented and tested (26 passing tests, 4 adversarial probes, Section 9.1.4, Section 29.18) and staged for Base Sepolia testnet deployment. The chain-of-custody schema, the capture-time signature verification logic, and the key registry and revocation mechanism described in this section have not been implemented or audited as their own contract extension. As with every design-stage product in this document family, this section states the architecture and the scope boundary precisely; it does not claim working code exists beyond the RandProofCertify base it builds on.

18. RandProof Provenance: Content Authenticity and Chain of Custody

On this page