A Study on Broker-Assisted Blockchain Trust Chains for Provenance and Integrity Verification of Generative Media Using Watermarking, Semantic Fingerprinting, and C2PA

Abstract

The widespread availability of generative artificial intelligence has increased the volume of images and videos shared online, while making it difficult to verify origin and integrity after routine post-processing such as re-encoding, resizing, and transcoding. This research proposes a broker-assisted trust chain architecture that treats authenticity verification as an evidence registration and validation workflow rather than a single-signal decision. A trust chain broker seals submitted media by embedding a robust hidden watermark, deriving an embedding-based semantic fingerprint, and producing standardized provenance metadata, then stores the sealed media off-chain using content-addressed storage and anchors only compact evidence on an immutable ledger. The anchored evidence binds the content identifier of the sealed artifact with semantic and provenance hashes, timestamps, and the broker signature, while scalable candidate discovery is supported through an off-chain Facebook AI Similarity Search (FAISS)-based nearest-neighbor similarity index. We evaluate the retrieval stage on a COCO 2017 validation subset (N = 200) under representative post-processing transformations (JPEG compression, resizing, and center cropping), and observe near-perfect candidate identification performance with Recall@1 = 0.9988 and Recall@5/10 = 1.000. During verification, the broker retrieves candidates by embedding similarity, validates ledger inclusion and broker signatures, applies consistency checks across evidence fields, and issues an operational verdict with a signed verification report that is independently checkable. We also implement an EVM-based proof-of-concept for on-chain anchoring and report low ledger-side overhead for a representative registration transaction (gasUsed = 25,380) when recording fixed-size compact evidence fields. The proposed architecture does not prevent copying itself, but improves traceability and auditability under realistic transformation and redistribution conditions by combining watermarking, semantic association, provenance binding, and tamper-evident evidence anchoring within a clear service accountability boundary.

1. Introduction

The widespread availability of generative AI has increased the volume of images and videos produced and circulated through online platforms [1,2,3]. In practical distribution pipelines, media objects are routinely re-encoded, resized, transcoded, or partially edited. The resulting challenge is not limited to judging whether a content item appears authentic, but to establishing whether its origin and integrity can be verified with evidence that remains meaningful after common post-processing. This requirement becomes critical in scenarios such as public announcements, journalism, dispute resolution, brand protection, and evidentiary review, where a verifiable proof trail is required rather than subjective inspection [4,5]. Conventional integrity verification of digital objects relies on cryptographic primitives such as hashing and digital signatures. These mechanisms provide strong guarantees when the object remains bit-identical. However, media files rarely remain unchanged in real workflows. Even benign operations such as re-encoding or resizing invalidate a conventional hash, despite preserving the semantic meaning of the content. A verification mechanism for media therefore must tolerate legitimate transformations while still enabling tamper-evident integrity checking. Robust watermarking has been considered as a method to embed an authenticity signal directly into media content [6,7]. When the watermark survives typical processing, it provides a persistent indicator that the content has passed through a particular sealing process. However, watermark detection alone does not provide a full provenance view, and its reliability depends on both the embedding method and the severity of subsequent transformations. Provenance metadata frameworks, including the Coalition for Content Provenance and Authenticity, provide standardized representations of creation and editing assertions [8]. Nevertheless, provenance metadata can be removed or altered unless it is bound to a tamper-evident mechanism that prevents undetected modification [4,5].

Our research approaches generative media authenticity as an evidence and validation workflow that combines complementary signals and anchors compact evidence in an immutable record. The core design separates large media storage from minimal integrity evidence recording. Large sealed media objects are stored off-chain, while compact evidence values are committed to a blockchain ledger [4,5]. Verification then becomes a process of extracting signals from a query media object, retrieving candidate records, and validating immutable evidence and signatures. Figure 1 illustrates the overall architecture of the proposed broker-assisted trust chain for content sealing and verification. A creator submits an image or video to a trust chain service operated by a broker. The broker performs sealing as an attested preprocessing step before evidence is recorded. During sealing, the broker embeds a robust watermark into the media [6,7], extracts embedding features [9] from the sealed media (e.g., images or video keyframes), and derives a semantic fingerprint represented as a fixed-length semantic hash [10,11]. The broker also generates a provenance manifest in a standardized format and binds the manifest to the sealed media and the extracted evidence values [8]. After sealing, the broker stores the sealed media in the InterPlanetary File System [12,13], which returns a content identifier that uniquely addresses the stored object. The broker then commits a compact content record to the blockchain ledger [4,5]. The on-chain record stores only minimal evidence required for later verification, including the content identifier, evidence hashes (e.g., semantic hash and provenance manifest hash), timestamps, and the broker’s digital signature. This structure provides a tamper-evident binding between the sealed media stored off-chain and the integrity evidence recorded on-chain, while keeping on-chain storage minimal [4,5]. Scalable candidate retrieval is supported through an off-chain Facebook AI Similarity Search (FAISS)-based nearest-neighbor similarity index [14,15]. Because semantic fingerprints [10,11] are intended for similarity-based matching rather than exhaustive on-chain scanning, the broker maintains an off-chain index for embedding-based search [14,15]. During registration, the broker updates this index with the embedding representation and associated content identifier, enabling later retrieval of top-k candidates for a given query [14,15]. Verification begins when a verifier submits a query media object to the broker. The broker extracts verification signals from the query, including watermark detection results (when applicable) and an embedding-based semantic fingerprint [6,7,10,11]. The off-chain similarity search index is used to retrieve candidate content identifiers [14,15]. The broker then queries the blockchain ledger for the corresponding on-chain content records and validates the broker signature and chain inclusion [4,5]. If additional evidence is required, the broker can retrieve the sealed media from the InterPlanetary File System using the content identifier and compare it against the query under the verification policy [12,13]. The verification output is issued as a signed report to provide accountability and enable third-party checking. In operational terms, verification outcomes can be expressed as verdicts such as Verified (registered origin and integrity are consistent), Derived (content remains strongly linked to a registered ancestor under allowable transformations), Unverified (no corresponding evidence exists), and Suspected Tampered (conflicting evidence, hash inconsistency, or insufficient similarity). This broker-assisted design provides a clear responsibility boundary, supports real deployment where platforms request verification as a service, and enables provenance and integrity checking that remains robust under common media post-processing.

The remainder of this paper is organized as follows. Section 2 reviews related work. Section 3 describes the broker service model and its registration and verification workflows. Section 4 presents the integrated trust chain model with the UML diagrams and algorithms. Section 5 presents the experimental evaluation. Section 6 discusses practical considerations, security implications, and limitations. Section 7 outlines future works and Section 8 concludes the paper.

2. Related Works

Many researchers have devoted sustained efforts to practical content security, spanning copyright-oriented protection protocols, robust media protection mechanisms, privacy-preserving visual sharing, and governance-driven transparency requirements. Frattolillo [16] proposed a blockchain-assisted watermarking protocol that adapts “buyer-friendly” and “mediated” designs to smart-contract execution, aiming to reduce trusted third-party exposure while keeping purchase transactions traceable and dispute-ready. In subsequent work, the same author [17] further extended this line by combining blockchain with cloud computing resources so that computationally burdensome, on-the-fly personalized watermark insertion can be outsourced while compact transaction evidence is anchored and validated through smart contracts. Qureshi and Megías Jiménez [18] synthesized a broader landscape by surveying blockchain-based multimedia content protection systems and organizing prior work across encryption, DRM, watermarking, and fingerprinting/transaction tracking, while emphasizing persistent gaps in deployability, interoperability, and scalability. Ye et al. [19] explored joint encryption-and-watermarking approaches for secure social image sharing, highlighting the ongoing need to balance confidentiality with traceability under platform-oriented constraints. Zhao et al. [20] surveyed visual content privacy protection and systematized adversary models and countermeasures, reflecting how privacy risks and content sharing security increasingly intersect in modern visual ecosystems. García-López et al. [21] reviewed challenges of integrating generative AI tools in education, including data security and governance concerns, while Quintais [22] analyzed how regulatory transparency obligations and copyright compliance requirements are evolving in the context of generative AI and the EU AI Act. In contrast to these studies that either focus on copyright purchase protocols, platform-oriented encryption/watermarking security, privacy-preserving vision, or legal/policy requirements, our work targets operational authenticity verification for generative media by integrating robust watermarking [6,7], embedding-based semantic fingerprints [10,11], and standardized provenance manifests (e.g., C2PA) [8] into an evidence-driven workflow; separating large-scale media storage from minimal on-chain anchoring by leveraging IPFS content addressing and retrieval [12,13]; enabling scalable candidate retrieval via an off-chain similarity search index [14,15]; and issuing signed verification reports with actionable verdicts suitable for real deployment.

To clarify the novelty and positioning of our broker-assisted workflow, we summarize representative related approaches and their covered components in

Table 1. Comparison of related approaches and the proposed workflow components.

Works	Watermark	Semantic Embedding/Fingerprint	Similarity-Based Retrieval	Provenance Manifest (C2PA)	Off-Chain Storage (IPFS)	On-Chain Anchoring
Frattolillo [16]	✓	-	-	-	-	✓
Frattolillo [17]	✓	-	-	-	-	✓
Ye et al. [19]	✓	-	-	-	-	-
Farhan et al. [5]	-	-	-	-	-	✓
Igonor et al. [4] (survey)	(survey)	(survey)	(survey)	-	-	(survey)
Qureshi & Megías Jiménez [18] (survey)	(survey)	(survey)	(survey)	-	-	(survey)
Our work	✓	✓	✓	✓	✓	✓

. The comparison focuses on whether a work operationally integrates (i) robust watermarking, (ii) embedding-based semantic fingerprinting, (iii) similarity-based candidate discovery, (iv) standardized provenance packaging, (v) off-chain storage, and (vi) minimal on-chain anchoring, rather than merely discussing these elements conceptually.

As summarized in Table 1, many prior studies emphasize specific sub-problems such as buyer–seller watermarking protocols and blockchain-based traceability, or provide surveys of protection mechanisms. However, they typically do not unify similarity-based candidate discovery and ledger-anchored evidential validation into a single operational workflow, nor do they provide a deployable responsibility boundary with broker accountability and signed verification outputs. In contrast, our work integrates robust watermarking, embedding-based semantic fingerprinting, standardized provenance manifests (C2PA-compatible packaging), off-chain storage for large media, and minimal on-chain anchoring of compact evidence. Verification is treated as a workflow of recording, retrieval, and evidential validation, enabling scalable candidate narrowing via similarity search and final validation via immutable ledger records and broker signatures, with multi-class operational verdicts suitable for real distribution pipelines.

3. Trust Chain Broker Service

This section describes the trust chain broker service as the operational core of the proposed approach. The broker is implemented as an application-layer service that performs content sealing at registration time and produces accountable verification outcomes at query time. The blockchain ledger is not treated as the service logic. Instead, the broker executes the workflow that generates and validates evidence, while the ledger provides an immutable anchor for compact evidence records. This design keeps large media objects off-chain, while preserving an auditable trail that is resistant to undetected alteration.

3.1. Internal Architecture and Interfaces

Figure 2 illustrates the internal architecture of the trust chain broker service and the two interfaces it exposes. A creator invokes the registration interface as register (media, creator_id, parent_id). The optional parent_id is provided when the submitted media is intended to be linked to a previously registered ancestor, enabling the service to represent derivative relationships explicitly. A verifier invokes the verification interface as verify (query_media, policy) to request provenance and integrity validation for an observed media object, where the policy specifies operational parameters such as candidate retrieval size, similarity thresholds, and optional evidence retrieval settings. The broker processes both requests by orchestrating internal engines and by accessing external back-ends through adapters. Watermark embedding is performed as part of sealing so that the media carries a hidden marker that can remain detectable after common post-processing, depending on the selected watermarking method and policy. Semantic fingerprint extraction is performed by deriving an embedding representation from the media and converting it into a fixed-length semantic hash. Provenance metadata is generated in a standardized format compatible with the Coalition for Content Provenance and Authenticity framework, and the resulting manifest is hashed so that a compact binding value can be anchored. Evidence persistence is separated from evidence anchoring: sealed media is stored through an InterPlanetary File System client adapter and returns a content identifier, while compact evidence records are committed and queried through a blockchain ledger client adapter. Scalable retrieval is supported through an off-chain similarity-search client adapter, which returns a small candidate set without scanning on-chain data. Finally, the broker signs evidence records and verification reports so that registration and verification results are broker-accountable statements that can be checked independently. The broker exposes registration and verification interfaces and orchestrates watermarking, semantic fingerprinting, provenance manifest generation, evidence storage, evidence ledger commitment, similarity-based candidate retrieval, and signed report issuance.

3.2. Registration Workflow: Content Sealing and Evidence Commitment

Figure 3 presents the registration workflow executed by the broker. Registration begins when a creator submits a media object together with identifiers through the registration interface. The broker performs content sealing before anchoring any evidence. A robust watermark is embedded into the submitted media, and the watermark payload binds the registration context, such as a broker-issued content identifier and time information, so that the marker can serve as an in-content code under common transformations. The broker then extracts an embedding representation from the sealed media and derives a semantic fingerprint represented as a fixed-length semantic hash. For video, embeddings are computed from representative keyframes so that the fingerprint reflects semantic content rather than the exact byte sequence. After sealing and fingerprint extraction, the broker stores the sealed media through the InterPlanetary File System adapter and obtains a content identifier. The content identifier is a content-addressed reference that can later be used to retrieve the stored sealed media. The broker then builds a provenance manifest compatible with the provenance standard, binds the relevant evidence values in that manifest, and computes a manifest hash. The off-chain similarity search index is updated with the embedding representation so that future verification queries can retrieve candidates efficiently. The broker then composes a compact evidence record that binds the content identifier to the semantic hash and the manifest hash, together with identifiers and timestamps. The broker signs this record and commits it to the blockchain ledger, receiving a transaction reference. The registration output is returned to the creator as a receipt containing the broker-issued content identifier, the content identifier of the sealed media, and the ledger transaction reference. The broker embeds a watermark, derives a semantic fingerprint, stores sealed media to obtain a content identifier, finalizes a provenance manifest, updates the similarity index, commits a signed content record to the ledger, and returns a receipt to the creator. Algorithm 1 summarizes the broker registration procedure corresponding to Figure 3.

Algorithm 1: Broker.RegisterMedia (request).
Input: request.media, request.creator_id, request.parent_id (optional) Output: receipt = {content_id, content_identifier, tx_reference}
1:	content_id ← GenerateContentId()
2:	timestamp ← Now()
3:	wm_payload ← Encode(content_id, request.creator_id, timestamp)
4:	sealed_media←WatermarkEngine.Embed(request.media, wm_payload)
5:	embedding ← FingerprintEngine.ExtractEmbedding(sealed_media)
6:	semantic_hash ← FingerprintEngine.DeriveSemanticHash(embedding)
7:	content_identifier ← EvidenceStoreAdapter.Store(sealed_media)  // returns a content identifier
8:	manifest ← ProvenanceManifestEngine.Build(sealed_media, creator_id = request.creator_id, evidence = {content_identifier, semantic_hash, timestamp}, parent_id = request.parent_id)
9:	manifest_hash ← Hash(manifest)
10:	SimilarityIndexAdapter.Upsert(content_id, embedding)
11:	record_fields ← {content_id, parent_id, content_identifier, semantic_hash, manifest_hash, creator_id, broker_id, timestamp}
12:	record_signature ← RecordSigner.SignContentRecord(record_fields)
13:	tx_reference ← EvidenceLedgerAdapter.Commit(record_fields, record_signature)
14:	return {content_id, content_identifier, tx_reference}

3.3. Verification Workflow: Candidate Retrieval and Signed Reporting

Figure 4 presents the verification workflow. Verification begins when a verifier submits a query media object together with a verification policy. The broker reconstructs verification signals from the query and validates them against immutable evidence records. Watermark detection can be configured as an optional step depending on media type and deployment policy. Independently, the broker extracts an embedding representation from the query media and uses it to perform off-chain similarity search. Similarity-based retrieval returns a small candidate set of registered content identifiers, which enables scalable lookup without exhaustive scans over on-chain data. For each candidate, the broker queries the blockchain ledger to obtain the corresponding evidence record and validates the broker signature and record inclusion. The broker evaluates evidence consistency by checking the semantic similarity score against the policy threshold and by checking the consistency of recorded hashes and bindings. If the verification policy requires stronger evidence, the broker retrieves the sealed media using the stored content identifier and refines the decision based on additional checks. The broker then generates a verification report containing the operational verdict and evidence references required for independent checking, and signs the report before returning it to the verifier. The broker extracts verification signals from the query, retrieves candidates via off-chain similarity search, validates corresponding on-chain records, optionally retrieves sealed media by content identifier, and returns a signed verification report to the verifier (Algorithm 2).

Algorithm 2: Broker.VerifyMedia (request).
Input: request.query_media, request.policy (thresholds, k, evidence_fetch flag) Output: signed_report = {verdict, evidence_refs, tx_reference, score, signature}
1:	wm_result ← WatermarkEngine.Detect(request.query_media) // optional
2:	emb_q ← FingerprintEngine.ExtractEmbedding(request.query_media)
3:	candidates ← SimilarityIndexAdapter.Search(emb_q, k = request.policy.k)
4:	best ← None
5:	for each candidate_content_id in candidates do
6:	record ← EvidenceLedgerAdapter.Query(candidate_content_id)
7:	ok_sig ← VerifySignature(record.fields, record.signature)
8:	score ← Similarity(emb_q, record.semantic_hash or record.embedding_ref)
9:	ok_evd ← CheckEvidenceConsistency(record, wm_result, score, request.policy)
10:	if ok_sig and ok_evd and score is best-so-far then
11:	best ← {record, score}
12:	end if
13:	end for
14:	if best is None then
15:	verdict ← UNVERIFIED
16:	else
17:	verdict ← DecideVerdict(best.record, best.score, request.policy)
18:	if request.policy.fetch_evidence then
19:	sealed_media ← EvidenceStoreAdapter.Get(best.record. content_identifier) // optional
20:	verdict ← RefineVerdictWithEvidence(sealed_media, request.query_media, verdict)
21:	end if
22:	end if
23:	report ← BuildReport(verdict, best, wm_result, request.policy)
24:	signed_report ← RecordSigner.SignVerificationReport(report)
25:	return signed_report

4. Integrated Trust Chain Model

This section formalizes the integrated trust chain model by specifying how sealed media, compact evidence records, and similarity-based retrieval interact across storage and ledger components. The broker service described in Section 3 produces three outputs during registration: a sealed media object, a compact evidence record anchored on an immutable ledger, and an off-chain retrieval handle through similarity indexing. Verification uses these outputs jointly: similarity search narrows the candidate set at scale, while final validation is anchored in ledger-backed evidence and broker signatures.

4.1. Separation of Storage, Evidence Anchoring, and Retrieval

The integrated trust chain model is organized around three complementary functions: storing sealed media objects, anchoring compact evidence in an immutable ledger, and retrieving candidates efficiently for similarity-based verification. Sealed media objects are large and are handled as off-chain artifacts, while integrity and provenance evidence is anchored as compact records so that bindings remain tamper-evident even when media is redistributed across platforms. Candidate retrieval is treated as a scalability component that narrows the search space using embedding similarity, whereas the final decision is anchored by ledger-backed evidence and broker signatures. This separation addresses practical characteristics of real media workflows. Media objects are frequently re-encoded, resized, and transcoded, which makes bit-level equality checks fragile. The model therefore treats verification as a two-stage process in which similarity-based retrieval produces a small candidate set, and ledger-backed validation confirms whether the query is consistent with immutable evidence bindings. Content-addressed storage provides a stable reference to sealed artifacts through content identifiers, and provenance metadata is anchored by hashing and signature mechanisms so that provenance bindings cannot be modified without detection.

4.2. Evidence Binding Model

In this model, $M$ denotes a media object submitted for registration. The broker produces a sealed media object $M_s$ by embedding a robust watermark that encodes a broker-defined payload under a watermarking policy ${\pi }_{wm}$. The sealing step is expressed as

$$M_s\leftarrow \mathrm{E}\mathrm{m}\mathrm{b}\mathrm{e}\mathrm{d}\mathrm{W}\mathrm{M}(M,\mathrm{p}\mathrm{a}\mathrm{y}\mathrm{l}\mathrm{o}\mathrm{a}\mathrm{d};{\pi }_{wm}),$$

(1)

The watermark is treated as an in-content code intended to remain detectable after common post-processing, subject to the robustness conditions of the chosen watermarking method and policy. A semantic representation is then derived from the sealed media. An embedding representation $\mathbf{e}$ is extracted and converted into a fixed-length semantic fingerprint $h_s$ under a fingerprinting policy ${\pi }_{fp}$:

$$\mathbf{e}\leftarrow \mathrm{E}\mathrm{x}\mathrm{t}\mathrm{r}\mathrm{a}\mathrm{c}\mathrm{t}\mathrm{E}\mathrm{m}\mathrm{b}(M_s;{\pi }_{fp}),h_s\leftarrow \mathrm{D}\mathrm{e}\mathrm{r}\mathrm{i}\mathrm{v}\mathrm{e}\mathrm{H}\mathrm{a}\mathrm{s}\mathrm{h}(\mathbf{e};{\pi }_{fp}),$$

(2)

This fingerprint is designed for similarity-oriented association rather than bit-level equality. For video, the embedding extraction is applied to representative keyframes so that the semantic representation reflects content semantics rather than the exact bitstream. The use of compact hash-like fingerprints for retrieval and association is consistent with the semantic hashing and locality-sensitive hashing literature, where the goal is to preserve similarity relationships in a compact form. The sealed media $M_s$ is stored in a content-addressed store, and the storage returns a content identifier $cid$ that can be used as a stable reference to retrieve $M_s$ independent of location:

$$cid\leftarrow \mathrm{S}\mathrm{t}\mathrm{o}\mathrm{r}\mathrm{e}\left(M_s\right),$$

(3)

In the InterPlanetary File System, this content identifier is a $cid$, which is derived from cryptographic hashing of the underlying content and functions as a content-addressed pointer rather than a location-based address. Provenance is represented through a standardized provenance manifest $P$ that binds provenance assertions to the registered artifact and evidence values under a provenance policy ${\pi }_{pv}$. A compact manifest hash $h_p$ is derived for anchoring:

$$P\leftarrow \mathrm{B}\mathrm{u}\mathrm{i}\mathrm{l}\mathrm{d}\mathrm{M}\mathrm{a}\mathrm{n}\mathrm{i}\mathrm{f}\mathrm{e}\mathrm{s}\mathrm{t}\left(M_s,cid,h_s,\mathrm{identifiers},\mathrm{timestamps};{\pi }_{pv}\right),$$

(4)

$$h_p\leftarrow \mathrm{H}\mathrm{a}\mathrm{s}\mathrm{h}\left(P\right),$$

(5)

This follows the C2PA model in which a manifest contains assertions and cryptographic bindings to content, and validators use content binding and hashing assertions to check integrity of the provenance package. The manifest hash used here is treated as a compact anchoring value that binds the provenance package to the broker-issued registration context. A compact content record $R$ is then formed to bind the sealed media reference and the evidence hashes, and the broker signature ${\sigma }_R$ is generated over the record fields before ledger commitment:

$${\sigma }_R\leftarrow \mathrm{S}\mathrm{i}\mathrm{g}\mathrm{n}\left(R\right),tx\leftarrow \mathrm{C}\mathrm{o}\mathrm{m}\mathrm{m}\mathrm{i}\mathrm{t}\mathrm{L}\mathrm{e}\mathrm{d}\mathrm{g}\mathrm{e}\mathrm{r}(R,{\sigma }_R),$$

(6)

The ledger transaction reference $tx$ provides an immutable anchoring point for later audit and verification, while the broker signature provides an explicit accountability boundary for broker-issued records. In parallel, the embedding representation is inserted into an off-chain similarity index to support scalable candidate discovery:

$$\mathrm{U}\mathrm{p}\mathrm{s}\mathrm{e}\mathrm{r}\mathrm{t}\mathrm{I}\mathrm{n}\mathrm{d}\mathrm{e}\mathrm{x}(id,\mathbf{e}),$$

(7)

Similarity search indices are widely used for efficient retrieval over high-dimensional vectors, and graph-based structures such as Hierarchical Navigable Small World (HNSW) are common in practical systems and libraries. In this research model, the index is treated as a performance component that provides candidate identifiers, while the ledger-backed record and signatures remain the correctness anchor.

4.3. Ledger Record Semantics and Derivative Linking

The ledger record defines the canonical binding for a registered content item. The record anchors a reference to the sealed media through the content identifier and anchors integrity and provenance evidence through compact hash values. The content identifier provides a stable retrieval reference to the sealed media. The semantic hash represents the fingerprint used for similarity-based association between a query object and the registered record. The provenance manifest hash anchors standardized provenance assertions in a tamper-evident way, even when the manifest itself is distributed separately or is subject to removal attempts.

Derivative relationships are represented through an optional parent link in the record. When an edited or transcoded media object is registered, a new sealed media object is produced and anchored as a new record, while the parent link references an ancestor record. This structure enables lineage representation without forcing bit-level reproduction of previous media objects. The trust chain is expressed as a sequence of ledger records linked through parent identifiers, while the sealed media references and compact evidence hashes remain explicit at each node in the chain.

4.4. Verification Semantics and Operational Verdicts

Verification begins from a query media object that may differ from the originally registered artifact due to common post-processing or partial editing. The broker reconstructs verification signals from the query, primarily by deriving an embedding representation and using it to locate candidate registrations through the off-chain similarity search structure. Similarity search is used to retrieve a small candidate set, which avoids exhaustive scans and supports platform-scale operation. For each candidate, the broker retrieves the corresponding evidence record from the blockchain ledger and validates the broker signature and ledger inclusion. This step establishes that the record is broker-issued and tamper-evident. A similarity score is then evaluated between the query embedding representation and the candidate fingerprint reference under the configured policy. Consistency checks are performed across the anchored evidence fields, including the semantic fingerprint evidence and the provenance binding evidence. Watermark detection can be applied as a policy-controlled signal. When watermark detection is enabled, the broker checks whether the extracted watermark signal is consistent with the registration context expected for a candidate record. When higher assurance is required, the broker can retrieve the sealed media using the content identifier and use this canonical artifact as additional evidence for decision refinement. These optional steps are treated as strengthening mechanisms and do not replace ledger-based validation. The verification outcome is expressed as an operational verdict that is signed by the broker. A Verified outcome indicates that the query media is consistent with a registered record under the similarity and evidence-consistency policy, with broker signature and ledger inclusion validated. A Derived outcome indicates that the query media is strongly linked to a registered ancestor and remains consistent with allowable transformation rules, supported by the lineage relationship expressed through the parent link. An Unverified outcome indicates that no candidate record satisfies the policy thresholds and evidence consistency checks. A Suspected Tampered outcome indicates that evidence conflicts, that similarity is insufficient, or that bindings are inconsistent in a way that suggests manipulation or deceptive repurposing.

4.5. Independent Checkability of Broker-Issued Reports

The integrated model is designed so that the broker issues verification reports while still enabling third parties to validate broker claims independently. Independent checking is supported because the report contains broker signatures and references to ledger-anchored records. A third party can validate the report signature using the broker’s public key, confirm that the referenced ledger transaction exists, and verify that the ledger record fields match the evidence references stated in the report. When the provenance manifest is accessible, the manifest hash can be recomputed and compared to the ledger-anchored manifest hash. When sealed media retrieval is permitted, the content identifier can be used to retrieve the sealed media from the InterPlanetary File System, enabling additional consistency checks against the canonical sealed artifact.

This structure makes the broker a practical accountability boundary for deployment. Off-chain similarity search provides scalability for candidate discovery, content-addressed storage provides stable sealed media references, and the immutable ledger anchors compact evidence so that provenance and integrity bindings remain tamper-evident. The signed report format then turns verification results into accountable, auditable statements suitable for integration into media distribution pipelines.

While the model specifies how registration outputs (sealed media, ledger-anchored evidence, and similarity-based retrieval handles) jointly support verification, the practical feasibility of this workflow depends on whether similarity-based candidate discovery remains reliable under common post-processing and whether minimal on-chain anchoring introduces acceptable overhead. Therefore, the next section evaluates (i) retrieval robustness under representative transformations and (ii) the on-chain anchoring overhead using an EVM-based proof-of-concept.

5. Experimental Evaluation

To validate the feasibility of the proposed provenance verification workflow under realistic distribution-time post-processing, we evaluate (i) the robustness of retrieval-driven candidate discovery using semantic embeddings and (ii) the overhead of anchoring compact evidence on an EVM-based ledger. We emphasize that the purpose of this evaluation is not to benchmark or outperform specific watermarking algorithms. Instead, our goal is to verify that, after common transformations such as compression, resizing, and cropping, a query item can still be reliably linked to its registered original through similarity-based retrieval, and that minimal on-chain evidence anchoring can be performed with low ledger-side overhead.

For retrieval evaluation, we use a subset of the COCO 2017 validation split [23]. To ensure reproducibility, we randomly sample 200 images with a fixed random seed. For each sampled image, we generate transformed query variants that emulate typical post-processing in real distribution pipelines: (i) JPEG compression with quality factors Q = 50 and Q = 80, (ii) resizing to 0.5× resolution using bicubic interpolation, and (iii) center cropping with a 10% area reduction. For semantic fingerprinting, we employ a pretrained CLIP image encoder (ViT-B/32) [24] to extract L2-normalized image embeddings. Because the embeddings are normalized, inner-product similarity corresponds to cosine similarity. We index the original embeddings using FAISS [25] and perform nearest-neighbor retrieval for each transformed query. We report Recall@k, which measures whether the correct original image is returned within the top-k retrieved candidates. This metric directly reflects the reliability of the candidate discovery stage in our registration–retrieval–evidential validation workflow.

Table 2. Per-transformation retrieval performance (COCO 2017 val subset, N = 200).

Transformation	Recall@1	Recall@5	Recall@10
JPEG compression (Q = 50)	100.0%	100.0%	100.0%
JPEG compression (Q = 80)	100.0%	100.0%	100.0%
Resize (0.5×, bicubic)	99.5%	100.0%	100.0%
Center crop (10%)	100.0%	100.0%	100.0%
Overall (aggregated)	99.9%	100.0%	100.0%

summarizes retrieval performance by transformation type. Across all transformed queries, the retrieval stage achieves near-perfect performance: Recall@1 = 0.9988, Recall@5 = 1.0000, and Recall@10 = 1.0000 (overall aggregated). These results indicate that semantic embedding-based fingerprints remain stable under common transformations such as compression, resizing, and cropping, enabling robust candidate discovery without relying on bit-identical matching. The slight drop in Recall@1 suggests that rare confusions can occur under certain perturbations, while top-5 retrieval remains reliable, which is sufficient for the subsequent evidential validation stage that checks ledger-anchored hashes and broker signatures.

Overall (aggregated) is computed over all transformed queries (200 images × 4 transformation types), counting a hit if the correct original image appears within the top-k retrieved candidates. In addition to retrieval robustness, we quantify the overhead of recording minimal integrity evidence on a blockchain ledger. We implement an EVM-based proof-of-concept using a local Anvil testbed and a minimal EvidenceRegistry smart contract. Each registration anchors fixed-size evidence fields, including a CID hash (bytes32), semantic fingerprint evidence hash (bytes32), provenance manifest hash (bytes32), and a timestamp (uint64), while the broker address is represented by the transaction sender. We measure per-registration overhead using gasUsed from the transaction receipt. In our prototype, a representative registration transaction consumed 25,380 gas for anchoring the compact evidence fields, demonstrating that minimal on-chain evidence recording can be performed with low ledger-side overhead while leaving large media objects off-chain.

Figure 5 provides the exact commands and receipt fields used to obtain the gasUsed value reported in

Table 3. Gas overhead of on-chain evidence anchoring (EVM PoC).

Item	On-Chain Fields	Metric	Result
Registration (CID hash anchoring)	cidHash, semanticHash, manifestHash, timestamp	gasUsed	25,380

.

To address the practical deployment cost on Ethereum mainnet, we convert the measured anchoring overhead into an approximate monetary fee. The fee can be estimated as fee (ETH) = gasUsed × gasPrice (gwei) × 10⁻⁹, and we use the representative anchoring cost measured in our proof-of-concept (gasUsed = 25,380).

Table 4. Annual monetary cost estimation for evidence anchoring (Ethereum mainnet).

Year	Avg Gas Price (gwei)	Fee (ETH)	Fee (USD)
2020	59.33	0.001506	0.64
2021	99.56	0.002527	7.09
2022	51.04	0.001295	3.09
2023	30.79	0.000782	1.42
2024	21.57	0.000547	1.70
2025	3.84	0.000097	0.31
Current (Mar 2026)	0.068	0.00000173	0.0035

summarizes the annualized cost translation using monthly average gas prices (2020–2025) [26] and an approximate ETH yearly average price for USD conversion [27]. Based on these references, anchoring a fixed-size compact evidence record typically incurs an on-chain fee that is small relative to the media payload size being kept off-chain [26]. Using the current gas price reference from a public gas tracker, the estimated fee under a low-gas regime becomes very small on mainnet [28]. This supports the design choice of anchoring only compact evidence fields (rather than large media objects) while keeping the on-chain operational cost small and predictable.

Overall, the results support the practicality of the proposed workflow in two key aspects: (i) similarity-based candidate discovery using semantic embeddings remains highly reliable under representative post-processing transformations, and (ii) anchoring compact evidence on an EVM ledger incurs low overhead consistent with the design goal of keeping on-chain storage minimal. More aggressive distortions (e.g., rotation, strong noise, and adversarial perturbations), larger-scale datasets, and additional system-level measurements for full IPFS-based storage/retrieval workflows remain important extensions and are left for future work.

6. Discussion

The experimental results support the feasibility of treating provenance verification as a workflow of retrieval and evidential validation rather than as a single binary decision. The retrieval evaluation shows that embedding-based fingerprints can reliably identify the registered original content after representative post-processing transformations such as compression, resizing, and cropping (Table 2). This finding is important for practical distribution settings where bit-level equality is rarely preserved. At the same time, the proposed architecture intentionally separates candidate discovery from final validation: similarity search is used to narrow candidates efficiently, while the final decision is anchored in ledger-backed evidence fields and broker signatures. We assume attackers can apply common post-processing, attempt metadata removal, and manipulate distribution contexts.

Table 5. Threat model and mitigations for the broker-assisted trust chain workflow.

Threat/Adversary Capability	Attack Surface	Expected Impact	Mitigation in Our Workflow	Residual Limitation
Routine post-processing (re-encoding, resizing, cropping, transcoding)	Media content	Byte-level hash invalidation; provenance verification failure if bit-identical checks are used	Embedding-based similarity retrieval to associate transformed queries with registered originals; ledger-backed evidential validation for final decision	Very aggressive distortions may reduce similarity and require higher assurance (e.g., sealed media retrieval/policy tightening)
Provenance metadata stripping or modification	C2PA/provenance manifest	Provenance assertions removed/altered	Manifest hash anchored on ledger; report validation checks manifest-hash consistency when manifest is available	If manifest is unavailable, verification relies more on other evidence fields and policy thresholds
Watermark degradation/removal attempts	Watermark signal	Reduced watermark detectability	Watermark treated as a complementary signal (not a single point of failure); workflow still operates via semantic retrieval + ledger evidence	Robustness depends on watermark scheme and severity of manipulation
Watermark copy/transfer (copy watermark to another media)	Watermark + media	False association if watermark is used alone	Cross-checking across multiple evidence fields (CID reference, semantic hash, manifest hash, timestamps, broker signature); similarity retrieval must be consistent with anchored evidence	Extremely capable adversary might craft near-collisions across multiple signals; addressed by conservative verdict policies
Adversarial embedding manipulation (evasion/spoofing)	Embedding extraction/retrieval	Wrong candidate retrieval; misleading association	Top-k retrieval followed by ledger-backed evidential validation; thresholding and multi-class verdicts (e.g., Unverified/Suspected Tampered) when evidence conflicts	Strong adaptive attacks against the embedding model remain possible; requires extended evaluation and model hardening
Semantic hash collision attempts	Semantic fingerprint evidence	False match/collision-based confusion	Use of fixed-size evidence hashes anchored on ledger; inconsistency checks across fields and broker signatures; conservative verdicting when conflicts appear	Collision resistance depends on the specific semantic hashing/fingerprinting design and parameters
Off-chain index poisoning/tampering	Similarity index store	Candidate set manipulation	Index treated as a performance layer; final decision validated by immutable ledger evidence and broker signature; operational controls (access control, integrity monitoring)	If broker environment is compromised, index poisoning can cause operational disruption; audit logs and key control become important
CID substitution/wrong sealed artifact retrieval	Content-addressed storage reference	Retrieval of wrong sealed media	CID (or CID-hash reference) anchored on ledger; verification checks binding between CID reference and other evidence hashes	Availability of off-chain storage is assumed; if content is unavailable, verification becomes partial
Ledger record tampering/deletion (attempted)	Blockchain ledger	Evidence removal/modification	Immutable ledger assumption; broker-signed anchoring; third-party can independently verify inclusion and signature validity	Censorship/availability and long-term chain governance are outside the paper scope; mitigation via operational choice of ledger and redundancy
Replay of old evidence/stale reports	Reports/timestamps	Misleading verification outcome	Anchored timestamps and signed reports; policy can reject stale evidence or require recent anchoring	Requires explicit policy settings and clock/timestamp assumptions
Broker key compromise/broker compromise/collusion	Broker service boundary	Forged evidence anchoring and reports	Broker signatures make actions attributable; ledger anchoring makes records auditable; independent verification of signatures and inclusion	Compromised broker can still issue incorrect claims; architecture focuses on auditability/accountability, not unconditional trust
DoS/service disruption	Broker API/storage/retrieval	Verification unavailable	Off-chain retrieval and on-chain evidence separation reduces ledger load; operational rate limiting and redundancy recommended	Availability is an operational concern; not fully solved by architecture alone

summarizes the threat model and the corresponding mitigations and residual limitations in our broker-assisted workflow.

From an implementation and deployment standpoint, the EVM proof-of-concept indicates that anchoring compact evidence on-chain can be performed with low ledger-side overhead (Table 3). This aligns with the design goal of minimizing on-chain storage by committing only fixed-size hashes and timestamps while keeping large media objects off-chain. In operational workflows, this separation allows a platform to request verification as a service without requiring the ledger to store or process large artifacts.

Threat considerations motivate the multi-signal design. We assume an adversary can apply common transformations, attempt metadata removal, and redistribute or repackage content across platforms. Under these conditions, provenance metadata alone can be stripped, and watermark signals may degrade under aggressive manipulation. Therefore, watermarking is treated as a complementary signal rather than a standalone guarantee, while semantic fingerprinting supports similarity-based association even when the byte sequence changes. Ledger anchoring then provides a tamper-evident binding for compact evidence fields, enabling independent checking of broker-issued records and reports. In addition, policy-driven thresholds and optional sealed-media retrieval by content identifier provide adjustable assurance levels when higher confidence is required.

Limitations remain. First, the retrieval evaluation is conducted on a moderate-scale subset and under moderate transformations; stronger distortions (e.g., rotation, heavy noise, adversarial perturbations, and more severe cropping) may reduce similarity and should be evaluated further. Second, the broker is an operational accountability boundary, but broker compromise or collusion is not fully prevented by design; rather, the architecture aims to make broker-issued claims auditable through signatures and immutable record inclusion. Third, while similarity search provides scalability, index design choices (e.g., similarity-index configurations) introduce typical accuracy–latency trade-offs that should be characterized for large-scale deployments. These limitations are best handled through explicit policy settings, transparent reporting, and systematic evaluation under broader attack and transformation scenarios.

7. Future Works

Future work will extend the evaluation to larger-scale datasets and more aggressive transformations (e.g., rotation, heavy noise, adversarial perturbations, and more severe cropping) to better characterize robustness boundaries of embedding-based fingerprints. We will also investigate scalable index configurations and their accuracy–latency trade-offs under platform-scale settings, and integrate a broader set of watermarking robustness tests as a complementary signal within the same verification policy. On the ledger side, we plan to expand system-level measurements beyond per-transaction gas usage by considering end-to-end overhead across sealing, storage, retrieval, and verification, including evidence retrieval from content-addressed storage and verification report generation. Finally, we will refine the security analysis by explicitly modeling broker compromise and collusion scenarios and by evaluating mitigation options such as transparency logs, key management hardening, and third-party auditing workflows.

8. Conclusions

Our research presented a broker-assisted trust chain architecture for provenance and integrity verification of generative media under common post-processing. The proposed approach treats verification as an evidence registration and validation workflow, in which a broker performs content sealing and issues accountable verification outcomes. Sealed media is stored off-chain using content addressing, and only compact evidence values are recorded on an immutable ledger. These evidence values include content identifiers, semantic fingerprints, provenance manifest hashes, timestamps, and broker signatures. Scalable candidate discovery is supported through off-chain similarity search, whereas final decisions are validated against ledger-backed evidence and broker signatures. The proposed model provides a deployable service boundary that supports platform-scale verification and auditability without requiring on-chain storage of large media objects. The broker is treated as an operational accountability boundary, and the design aims to make broker-issued outcomes independently checkable rather than to assume unconditional trust in the broker. In the COCO 2017 validation subset experiment (N = 200) with representative post-processing transformations, the retrieval stage achieved Recall@1 = 0.9988 and Recall@5/10 = 1.000, supporting robust candidate identification under compression, resizing, and cropping. In addition, the EVM-based proof-of-concept demonstrated low ledger-side overhead for anchoring fixed-size compact evidence, with a representative registration transaction consuming 25,380 gas (gasUsed).