Provenance: What It Actually Takes to Prove Creator Data Dignity

We red-teamed an AI royalty proof-of-concept system we are building

Provenance by Vektor Memory: Another weekend coding project and why proposals for paying creators when AI trains on their work is more difficult than discussions.

Note: Article is written in natural human language for general readers—for deeper technical dives, see our other 70 articles or website.”

After watching Jaron Lanier argue for years that AI models are compressions of human labor, not independent intelligences, we finally tried to turn that thesis into working code. An account of where the theory held up and where it cracked.

We spent the last few weekends building a five-layer system for tracing AI-generated content back to the creators whose work shaped it, and paying them. We spent the weekend stress-testing every single layer until we found the cracks.

Then we fixed the first layer, actually shipped it, and tested it against 27 different file formats.

The concept is compelling. The execution is where things get interesting, because almost every piece that looks reasonable on paper fails in a specific, predictable way once you attack it or try to build it without the data needed.

Why this idea exists
The argument is straightforward: if an AI model is a compression of human training data, then the people who created that data should get paid when the model generates revenue. It’s not a complete fix for content attribution or copyright law. It’s one small attempt at one piece of a much larger problem.

But “one small piece” turns out to require solving several separate, genuinely hard problems at once. Content provenance. Attribution math that works under adversarial conditions. Governance that can’t be captured by a coordinated attacker. Economics that don’t accidentally subsidize the bad actors. And legal frameworks that don’t exist yet.

We decided to build it in layers, test each one until it broke, and publish what we found.

The five-layer architecture
The system splits into five independent, testable layers. Here’s the flow from a creator’s work to a payout:

Layer 1: Provenance Registry Your work gets signed and timestamped through two independent, non-colluding anchors. One is a traditional timestamp authority. The other is the Bitcoin blockchain. This creates a verifiable record of what existed and when, without depending on trusting us or any single gatekeeper.

Layer 2: Streaming Safety Guard The AI platform’s output gets checked in real time, before the user sees it, looking for combinations of risky content rather than just flagged words. Single-word blocklists are trivial to route around. Combinations are harder.

Layer 3: Attribution and Staleness Decay We estimate how much a registered piece of work shaped a specific output, then lower that confidence continuously as the underlying model keeps training and drifting away from the version we measured.

Layer 4: Anti-Sybil Governance When attribution claims get contested, we route them to a small jury sampled at random from a bonded pool instead of an open vote. An attacker can’t know in advance which of their fake accounts will be eligible to vote on any given case.

Layer 5: Settlement and Economics Contested payouts go into escrow. Disputes resolve through appeals. Fees scale based on an account’s own risk profile, not flat usage volume.

Each layer has built-in failure modes.

CREATOR'S WORK AI PLATFORM'S RESPONSE
| |
v v
[1] PROVENANCE REGISTRY [2] STREAMING SAFETY GUARD
Signs and timestamps the work Checks the model's output
through two independent, non- in chunks as it's generated,
colluding anchors, so there's a before the user ever sees it,
verifiable record of what existed for combinations of risky
and when. content, not just single words.
| |
+------------------------+-------------------- +
|
v
[3] ATTRIBUTION AND STALENESS DECAY
Estimates how much a piece of registered
work actually shaped a given output, and
lowers that confidence continuously as the
underlying model keeps training and drifting
away from the version that was last measured.
|
v
[4] ANTI-SYBIL REDUNDANCY AND GOVERNANCE
Checks whether a submission is a genuine
duplicate or a disguised resubmission using
three different signals, and routes contested
attribution claims to a randomly sampled,
bonded jury instead of an open vote.
|
v
[5] SETTLEMENT AND ECONOMICS
Holds contested payouts in escrow, resolves
disputes through a tiered appeals process, and
funds the whole system through fees scaled to
each account's own risk, not flat usage volume.
|
v
CREATOR GETS PAID

Layer 1 is shipping now
The provenance layer is a working CLI tool called Prov. It signs your code or your body of work into a cryptographic manifest, timestamps it through two independent services that actively distrust each other, and gives you a verifiable record that doesn’t depend on trusting us.

We released it as open source a few weeks ago. But the real test started last week when we tried to make it work with multiple file formats that matter.

27 formats: Images. Code. PDFs. Documents. Fonts. Anything you’d actually want to prove authorship over.

The format problem nobody talks about
The C2PA standard (the same one Adobe uses for content credentials) works great for images and video. PNG, JPEG, WAV, MP4 all have standard ways to embed cryptographic manifests. You sign the file, embed the signature, read it back out.

But most creator work isn’t just images. It’s source code. Text. PDFs. Office documents. Fonts. These are completely different containers with completely different structures.

We built custom implementations for all of them in JS. PDF needed its own manifest embedding strategy because c2pa-python has no native PDF writer. EPUB, DOCX, ODT, OXPS are all ZIP containers but with different rules about where files can go and what can be compressed.

Fonts (OTF, TTF, SFNT) have their own table structure and a pre-standard C2PA specification that’s still sitting in an open GitHub issue, waiting for the standards body to ratify it.

We pulled the actual C2PA specification and font spec proposals, read the code in the reference implementations, and built each one to spec.

Then we tested all 27 of them round-trips: cryptographic validation. Real c2pa. Reader parsing.

The MIME type trap
The c2pa-python library accepts any MIME type you hand it, but internally it’s selective about what it actually signs. We tried signing an M4A audio file as audio/mp4 (the obvious choice) and it failed silently with “NotSupported.”

We spent time chasing that before realizing the library was rejecting the MIME type hint, not the file itself. Signing it with application/octet-stream (a generic, content-agnostic type) worked fine. The lesson: never assume MIME type handling is transparent.

The attribute shape mismatch: The c2pa-text library we integrated for source code embedding has three different embedding methods (invisible Unicode, structured comments, HTML).

Each one returns a different data shape. We assumed they all returned the same TextEmbedResult object with .text, .exclusion_start, and .exclusion_length.

Two of them return something completely different. We caught it by actually inspecting the function signatures before running anything, not after.

The DSIG coexistence problem: When we tested font embedding against real-world OTF files, we discovered that production fonts often already carry a DSIG (digital signature) table from their foundry.

The C2PA spec proposal says they shouldn’t coexist. We had to add a configurable policy: refuse to sign a font that already has a DSIG, or strip it first and proceed. Both approaches are defensible, depending on your use case.

Here’s what’s in the release:
27 file formats verified working with real cryptographic signatures. That breaks down as follows:

19 Tier-1 native formats (PNG, JPEG, WAV, MP4, WebP, HEIC, HEIF, GIF, MP3, AVI, TIFF, AVIF, M4A, DNG, M4V, MPA, SVG, FLAC, JPEG XL)
1 custom implementation for PDF (write support, which the base library didn’t have)

4 ZIP-container formats (EPUB, DOCX, ODT, OXPS) with custom collection-data-hash logic

3 font formats (OTF, TTF, SFNT) with DSIG handling

Plus 5 source-text formats (.py, .js, .yaml, .sql, .md) and HTML, which nobody else in the C2PA space covers because they require a separate text-embedding specification that c2pa-python completely ignores.

Every single one has a smoke test. Every smoke test uses real files (not synthetic test data), real signing, real validation through the actual c2pa.Reader library, not mocked calls.

Layers 2 through 5: where theory meets reality
The other four layers are simulations. We didn’t ship them yet because every single one has structural vulnerabilities that an attacker would exploit in the first week.

We’d rather find them now, in simulation, than after there’s real creator money behind them.

Open voting — dispute resolution system
We built a dispute resolution system where a committee votes on contested attribution claims. We assumed quadratic voting would handle it, because quadratic voting is supposed to blunt the advantage of concentrated capital.

What it doesn’t do is stop an attacker from splitting that same capital across more identities. Under quadratic voting, total voting power actually increases as you split a fixed budget into more accounts. We ran a simulation with a coordinated cartel trying to capture a committee’s vote, and they succeeded nearly every time.

The math is straightforward: if you have 100 tokens to vote with, quadratic voting gives you sqrt(100) = 10 voting power. If you split that into 10 accounts with 10 tokens each, you get 10 accounts with sqrt(10) = 3.16 power each, for a total of 31.6. You just increased your voting power by 3x by splitting your tokens.

We fixed it by replacing open voting with a small jury randomly sampled from a bonded pool. An attacker doesn’t know which of their fake accounts will be eligible to vote on any given case.

If an attacker controls 30 percent of a 10,000-person pool, they have roughly a 0.04 percent chance of capturing a 63-member jury’s majority on any single dispute. We verified that number two ways: a closed-form probability calculation and an independent simulation. They agreed.

A perfect safety filter can still be defeated by buffer management
We built a streaming content filter that runs on the AI platform’s output in real time, looking for combinations of risky terms rather than single flagged words. The detector works exactly as designed when both terms appear in the same chunk.

It fails completely when we split the same two terms across a chunk boundary. The system has no memory of what it already saw. It checks the first chunk, finds nothing (because it’s only half the risky combination), forgets about it, then checks the second chunk and finds nothing there either (because it’s missing the first half). The risky content passes through untouched.

The vulnerability has nothing to do with the detector’s intelligence. It’s a structural gap in how the buffer forgets its own history. We added a small memory window to track terms from the previous chunk. That fixed the immediate version of the problem.

Then we tested it by splitting the risky terms even further apart, across multiple chunks and multiple seconds of output. The same failure came back. The memory window has a hard limit. Split the terms far enough and you defeat the filter again.

You can’t fix this by making the memory window larger without introducing latency penalties that destroy the entire point of streaming detection. You can’t fix it by making the detector stateless because then it can’t remember anything. It’s a fundamental constraint of how streaming systems work.

Hardware isolation doesn’t work the way you think
The instinct is to run your safety check on separate hardware from the main model. That way, under load, the safety check won’t get starved for compute.

We tested this three different ways. First with a placeholder safety check that barely does any work, moving it to a separate process. Performance got worse, not better, because the overhead of the inter-process communication outweighed the benefit of separation.

Then we did it with a real model doing real computation. Separation won decisively, and latency degradation under load dropped by roughly 30 times. The safety check was protected.

Then we pinned both processes to completely separate CPU cores using hardware affinity, to test true resource isolation rather than just process separation.

And we found a bottleneck neither test had caught: even with the safety model sitting on completely idle cores, the calling process (the one issuing the request to the safety check) was starved by the same contention, because it shared cores with the load.

You can isolate the safety check’s compute, but you also have to guarantee resources for the caller. Most designs only think about one half of that.

Flat fees subsidize the problem actors
A common approach to funding safety infrastructure is to charge a flat percentage fee on every API call. You’re charging for volume.

We simulated this against a real distribution of user behavior: mostly legitimate enterprise customers, a small tail of research accounts, and a handful of accounts repeatedly flagged for violations.

The high-volume legitimate customers ended up paying roughly eight times their fair share of the actual cost their traffic imposed on the safety infrastructure. Meanwhile, accounts flagged repeatedly for violations paid a fraction of theirs.

We shifted the fee model to scale with an account’s own observed history. That fixed most of the second problem. A habitual violator now pays a realistic cost for the risk they cause.

It only partly fixed the first problem, because the legitimate high-volume customers still have to cross a flat base rate before the risk-adjusted pricing kicks in. Our first writeup overstated how well this worked. Once we looked at the actual numbers instead of the intended design, we corrected it.

The lesson: when you’re designing economics, the numbers matter more than the theory.

Known problems we can’t solve in this design
The cold start problem: AI labs won’t integrate an attribution system until creators have registered their work. Creators won’t bother registering until AI labs start paying them. Solving this requires either regulatory force or a massive coordinated developer movement.

The GDPR paradox: Public cryptographic ledgers are immutable by design. They can’t delete data. But GDPR’s Article 17 says creators have the right to erase their personal data. Designing systems that can sever real-world identities from public commitments without breaking historical provenance is deeply non-trivial.

Training data attribution doesn’t exist yet: Our system assumes you already have attribution scores telling you which training data influenced a given output. No real training-data attribution exists at scale. We can track staleness of scores over time, but we can’t generate the scores in the first place. That’s a separate, unsolved problem.

The incumbent incentive mismatch: Hyperscalers have strong structural incentives to keep training data pipelines opaque. They avoid liability, copyright exposure, and margin compression by keeping everything closed. Forcing them to adopt an open attribution standard requires either severe regulatory pressure or a developer revolt.

Governance capture is reduced, not eliminated: Our jury model is much harder to attack than open voting, but it’s not impossible. With enough budget and sophistication, a determined attacker could still find ways to bias the jury pool. We reduced the problem from “captured almost every time” to “captured maybe once in ten thousand tries.” That’s an improvement, not a solution.

The technical foundation
Layer 1 builds on real standards work:

C2PA (Consortium for Content Provenance and Authenticity) is the same specification Adobe uses for content credentials. We implemented it fully for 27 file formats instead of just image and video.

Our dual-anchor timestamping follows RFC 3161 for traditional timestamp authorities and OpenTimestamps for Bitcoin-based anchoring, so no single gatekeeper can control the registry.

Shamir’s Secret Sharing for custody of the identity-vault key, so key compromise doesn’t automatically compromise the registry. Implemented and verified, not theoretical.

Generative Content ID research from Deng et al. for the attribution framework, adapted from music to text.

Influence-function based staleness decay for understanding why attribution scores get noisier over time.

Data Dignity work from RadicalxChange for the governance framing, treating this as collective bargaining infrastructure instead of a single company’s black box.

Caveats: Known Challenges

1. Computational & Scaling Complexities (The Math Problem)

The Scale of TDA (Training Data Attribution): Running exact attribution models to figure out which datasets or creator nodes influenced a specific token output is computationally prohibitive[1]. Even state-of-the-art approximations (like TRAK or influence functions) require massive matrix multiplications, massive storage for pre-computed gradients, and continuous re-computation overhead.

The Checkpoint Drift Problem: Production foundation models are under continuous fine-tuning, DPO (Direct Preference Optimization), and RLHF. Every single weight update instantly invalidates old attribution indices, requiring automated, resource-intensive re-projection pipelines running 24/7.

Inference Latency Costs: Adding parallel safety guardrails or logging telemetry introduces non-zero latency penalties. Scaling this across millions of concurrent enterprise users without degrading Time-to-First-Token (TTFT) requires dedicated, expensive parallel hardware infrastructure.

1. Economic & Game-Theoretic Complexities (The Money Problem)

The Micro-Payout Gas & Ledger Crisis: Distributing fractions of a cent ($0.0000001) across millions of global creators per LLM query will completely break traditional banking rails and rack up unsustainable blockchain gas fees unless channeled entirely through specialized Layer-2/Layer-3 zero-knowledge state rollups.

Adverse Selection in Surcharges: Funding safety infrastructure via a flat usage-based surcharge on API calls disproportionately penalizes honest, high-volume enterprise customers who pose minimal safety risks, subsidizing the overhead caused by a tiny fraction of bad actors.

Sybil Flooding & Value Extraction: Any system that pays out real money based on data contribution immediately invites sophisticated adversarial attacks — such as automated synthetic data farms engineered exclusively to maximize attribution scores and drain the royalty pool.

1. Governance, Trust & Adversarial Complexities (The Human Problem)

The Curation Cartel & Collusion: Decentralized committees or “courts” meant to arbitrate data disputes are chronically vulnerable to capture. Well-organized cartels or Sybil nodes can coordinate below voting thresholds to systematically vote down legitimate creators and slash their stakes.

The Subjectivity of “Causal Influence”: Unlike exact file matching (like audio copyright matching on YouTube), generative AI creates entirely new conceptual syntheses [2]. Proving mathematically how much an artist’s style or text snippet contributed to an abstract generated concept remains intensely legally and technically contested.

The Burden of Dispute Resolution: When millions of creators dispute low attribution scores, who handles the administrative backlog? Automated code cannot legally seize collateral or execute final financial penalties without triggering severe legal challenges in traditional courts.

1. Privacy, Compliance & Legal Complexities (The Regulatory Problem)

The GDPR “Right to Erasure” Paradox: Public cryptographic ledgers and append-only Verkle trees are immutable by design — they cannot delete data[2]. However, Article 17 of the GDPR dictates that a creator has the right to erase their PII and identity data completely. Designing systems that can sever real-world identities from public commitments without breaking historical provenance is deeply non-trivial.

Cross-Jurisdictional Compliance: A global creator economy must navigate radically conflicting international frameworks — such as the EU AI Act’s strict transparency and copyright mandates[2], US fair use doctrines, and varying regional data sovereignty laws.

Liability and Indemnification: If an AI platform uses a registered dataset that turns out to contain plagiarized or illegal content (e.g., leaked enterprise code or copyright-infringing text), who carries the legal liability — the platform, the creator who registered it, or the attribution protocol?

1. Ecosystem Coordination Complexities (The Adoption Problem)

The Cold-Start Problem (Two-Sided Marketplace Failure): AI labs won’t integrate an attribution and royalty protocol until creators flood it with data; creators won’t bother registering their work until major AI labs adopt the standard and start paying out real revenue.

The Incumbent Incentive Mismatch: Hyperscalers and frontier AI labs (OpenAI, Google, Anthropic, Meta) have strong structural incentives to keep training data pipelines opaque to avoid liability, copyright exposure, and margin compression. Forcing them to adopt an open attribution standard requires either severe regulatory pressure (such as enforced compliance frameworks like the EU AI Act)[2] or a massive, coordinated developer revolt.

What’s next
Layer 1 is production-ready and available open source.

https://github.com/Vektor-Memory/Provenance

Layers 2 through 5 are simulations of what a complete system would look like. We built them because we wanted to find the failure modes before there’s real creator money sitting behind them. Some you can’t fix without changing the whole architecture.

We’re asking whether this direction is worth pursuing at all. Whether the failures we found are the ones you’d expect or ones you’d never have guessed. Whether “tested this hard before launch” is a bar worth holding the rest of this category to.

They need:
Real training data attribution systems that don’t exist yet. Our staleness tracking works on top of attribution scores that already exist, but generating those scores at scale is still an open research problem.
Regulatory framework and legal counsel review. We don’t know yet whether this approach is even legally defensible without new law.

Real-world adversarial testing beyond simulation. An attacker with real resources and real incentives will find things a simulation won’t.
Ecosystem coordination. This only works if it actually gets adopted, which requires solving the cold-start problem for a two-sided marketplace.

VEKTOR Memory builds local-first, privacy-preserving persistent memory infrastructure for AI agents. Technical documentation at vektormemory.com.

Data Science
AI
Data Dignity
Provenance