Deepfake Detection as a Decentralized AI Network

Q: How does commit-reveal stop operators from copying each other?

During the commit window a worker publishes only SHA-256(score ‖ modelid ‖ salt), from which the score cannot be recovered. No worker can see another's answer until every commitment is already fixed on-chain. After the reveal deadline the plaintexts are published and verified against the digests, so a copied answer either does not exist yet or does not match its commitment. The random per-job salt is what makes the small score space un-invertible.

A decentralized deepfake detection network replaces the single-vendor detection API with an open market of independent operators who each run their own models on their own hardware, commit their verdicts before anyone can see them, and stake capital against being wrong. Cryptuon’s DFPN implements exactly that on Solana: a client submits a content hash and a fee, several workers analyse the media independently, a commit-reveal protocol prevents them from copying each other, and a reputation-weighted consensus produces a verdict that is anchored on-chain with a permanent audit trail. The interesting engineering claim is not “our detector is more accurate” — it is that detector diversity plus an auditable record is a better answer for contested media than any single accuracy number from a single vendor.

TL;DR

The failure mode of centralised detection is correlation, not accuracy. One vendor means one model family, one training distribution, and one blind spot that every customer inherits simultaneously.
DFPN is a coordination layer, not a model. Anchor programs on Solana handle job creation, commitments, reveals, scoring, and payment. Detection itself runs off-chain on operator GPUs as Python subprocesses or HTTP services.
Commit-reveal makes free-riding unprofitable. A worker publishes hash(verdict ‖ salt) first and the plaintext verdict only after the reveal window opens, so copying a neighbour’s answer is impossible during the window and detectable afterwards.
Economic security is staked, tiered, and challengeable. Operators post DFPN stake, earn per-job fees, and face graduated slashing with a challenge window so honest errors are handled by reputation decay rather than confiscation.
The chain holds hashes, not media. Content bytes live in IPFS, Arweave, or S3; Solana holds the content hash, the commitments, the reveals, and the final verdict. That buys integrity and permanence, and explicitly does not buy privacy.
Provenance and detection are complements. C2PA-style signing answers “where did this come from?” at capture time; detection answers “does this look manipulated?” afterwards. A newsroom needs both.
See how we run detection and provenance evaluations, or describe your project if you are integrating verification into a pipeline.

Why single-vendor detection breaks as civic infrastructure

Every commercial deepfake detector is a classifier trained on a corpus of known generators. That is a perfectly reasonable engineering approach and it produces useful software. The problem appears when the same classifier becomes the arbiter for a newsroom, a court filing, a platform’s trust-and-safety queue, and an insurance claim at the same time.

Correlated failure

If a thousand organisations all query the same API, they do not have a thousand independent opinions. They have one opinion, replicated. When a new generator lands that happens to sit outside the vendor’s training distribution, every one of those organisations gets the same wrong answer on the same day, and none of them has a second source to notice the discrepancy. Statistically, buying detection from one vendor is buying a single sample and treating it as an ensemble.

A network of independent operators inverts that. Operators are free to run different architectures, different fine-tunes, and different preprocessing pipelines. A verdict is the aggregate of several genuinely different opinions, and — critically — the disagreement itself is recorded. A 5-to-0 consensus and a 3-to-2 split both produce a verdict, but only one of them should trigger an automated takedown.

The audit problem

The second failure is evidentiary. When a detection result is contested six months later — in an editorial correction, a platform appeal, or a legal proceeding — a REST response body is not evidence. It has no timestamp anyone else can verify, no record of which model version ran, and no way to demonstrate that the answer was not amended after the fact.

DFPN’s answer is to make the record itself the product. Every stage of a verdict lands on Solana: the job, each worker’s commitment, each reveal, the scoring, and the final aggregate. Months later you can reconstruct precisely who said what, when, and in what order, without asking anyone’s permission and without trusting the operator of the network.

The censorship problem

A centralised detector is a centralised veto. Whoever runs it can decline a job, throttle a customer, or quietly retire a model. For media verification — which is increasingly a civic function rather than a commercial one — that is a structural weakness, not a service-level issue. A permissionless network where any operator with a GPU can join removes the single point of refusal.

Architecture: what runs on-chain and what does not

DFPN splits cleanly along a well-worn line. The chain does coordination, money, and memory. The GPUs do machine learning. Nothing about the detection model itself is on-chain, and that is deliberate — an EVM or SVM program cannot run a video classifier, and pretending otherwise produces protocols that never ship.

The on-chain programs are Anchor 0.30.1. The worker daemon is Rust. The client SDK is TypeScript. Detection models run as Python subprocesses or as local HTTP services on operator hardware, which means an operator can bring any model they like — a research checkpoint, a commercial licence, or something they trained themselves — without the protocol needing to know what it is.

The account layout

The on-chain state is small and boring by design. A job account carries the content hash and the fee; commitment and reveal accounts are program-derived from the job and the worker so a worker can commit exactly once per job.

use anchor_lang::prelude::*;

#[account]
pub struct DetectionJob {
    pub requester: Pubkey,
    /// SHA-256 of the media bytes. The bytes themselves live off-chain.
    pub content_hash: [u8; 32],
    /// Storage locator: an IPFS CID, an Arweave tx id, or a presigned URL hash.
    pub locator: [u8; 64],
    pub media_kind: MediaKind,
    pub fee_lamports: u64,
    pub commit_deadline: i64,
    pub reveal_deadline: i64,
    pub workers_committed: u8,
    pub workers_revealed: u8,
    pub state: JobState,
    pub bump: u8,
}

#[derive(AnchorSerialize, AnchorDeserialize, Clone, Copy, PartialEq, Eq)]
pub enum MediaKind { Image, Video, Audio }

#[derive(AnchorSerialize, AnchorDeserialize, Clone, Copy, PartialEq, Eq)]
pub enum JobState { Open, Committing, Revealing, Scored, Challenged, Finalized }

#[account]
pub struct Commitment {
    pub job: Pubkey,
    pub worker: Pubkey,
    /// SHA-256(verdict_score_le || model_id || salt)
    pub digest: [u8; 32],
    pub committed_at: i64,
    pub bump: u8,
}

#[account]
pub struct Reveal {
    pub job: Pubkey,
    pub worker: Pubkey,
    /// Basis points: 0 = confidently authentic, 10_000 = confidently synthetic.
    pub score_bps: u16,
    pub model_id: [u8; 32],
    pub salt: [u8; 32],
    pub revealed_at: i64,
    pub bump: u8,
}

Note what is absent. There is no field for the media itself, no field for the requester’s identity beyond a public key, and no field for a human-readable label. The protocol records a numeric score, the identity of the model that produced it, and the cryptographic material needed to prove the score was fixed before the reveal window opened.

Why the chain holds hashes and not media

Putting media bytes on a public ledger would be expensive, permanent, and — for the newsroom and trust-and-safety use cases that matter most — actively harmful. The contested video in a harassment case should not become permanently retrievable because someone asked whether it was real.

Storing only the content hash gives integrity: anyone holding a copy of the media can recompute the hash and prove it is the same artefact the network judged. It does not give privacy or availability. If every copy of the media disappears, the verdict remains but the thing it judged does not. That tradeoff is stated plainly rather than papered over, because the alternative — a protocol that quietly leaks the exact material its users most want contained — is worse.

Commit-reveal: making free-riding unprofitable

The economic attack on any multi-party scoring network is copying. If verdicts are visible as they arrive, the cheapest strategy is to skip the GPU entirely, wait for the first honest answer, and echo it. Every copier that succeeds dilutes the reward for the operator who actually spent compute, and the network converges on a single opinion with extra steps.

Commit-reveal removes the information that makes copying possible. Each worker first publishes a digest binding its score, its model identity, and a random salt. Nothing about the score is recoverable from the digest. Only after the commit deadline passes does the reveal window open, and by then every commitment is already fixed on-chain.

Cryptuon maintains commit-reveal as a standalone, dependency-free Python library precisely because this primitive keeps recurring across the portfolio — in DFPN’s scoring, in MEV-resistant ordering, and in sealed-bid auctions. The client side is trivial:

import os, hashlib, struct

def commit(score_bps: int, model_id: bytes, salt: bytes | None = None):
    """Produce the digest a DFPN worker publishes during the commit window."""
    assert 0 <= score_bps <= 10_000, "score is in basis points"
    assert len(model_id) == 32, "model_id is a 32-byte registry key"
    salt = salt or os.urandom(32)
    preimage = struct.pack("<H", score_bps) + model_id + salt
    return hashlib.sha256(preimage).digest(), salt

digest, salt = commit(score_bps=8_742, model_id=bytes.fromhex("a3" * 32))
# publish `digest` now; publish (score_bps, model_id, salt) after the reveal opens

The on-chain verification is the same three lines in reverse, and it is the only place the protocol needs to be strict:

pub fn reveal(ctx: Context<RevealVerdict>, score_bps: u16, model_id: [u8; 32], salt: [u8; 32]) -> Result<()> {
    let job = &mut ctx.accounts.job;
    let clock = Clock::get()?;

    require!(clock.unix_timestamp > job.commit_deadline, DfpnError::RevealTooEarly);
    require!(clock.unix_timestamp <= job.reveal_deadline, DfpnError::RevealTooLate);
    require!(score_bps <= 10_000, DfpnError::ScoreOutOfRange);

    let mut preimage = Vec::with_capacity(2 + 32 + 32);
    preimage.extend_from_slice(&score_bps.to_le_bytes());
    preimage.extend_from_slice(&model_id);
    preimage.extend_from_slice(&salt);

    let expected = anchor_lang::solana_program::hash::hash(&preimage).to_bytes();
    require!(expected == ctx.accounts.commitment.digest, DfpnError::CommitmentMismatch);

    let reveal = &mut ctx.accounts.reveal;
    reveal.job = job.key();
    reveal.worker = ctx.accounts.worker.key();
    reveal.score_bps = score_bps;
    reveal.model_id = model_id;
    reveal.salt = salt;
    reveal.revealed_at = clock.unix_timestamp;

    job.workers_revealed = job.workers_revealed.saturating_add(1);
    Ok(())
}

A worker that commits and then fails to reveal is treated as a non-participant and forfeits its share of the job fee. A worker that reveals a score which does not match its digest is simply rejected — the protocol never has to decide whether the mismatch was malice or a bug, because the outcome is the same either way.

Why the salt has to be per-job

A fixed salt would let anyone build a rainbow table over the 10,001 possible scores and invert every commitment instantly. Because the score space is small, the salt is not optional garnish — it is the entire reason the commitment hides anything. Thirty-two random bytes per job, regenerated every time, is the whole requirement.

The verdict lifecycle

Seven steps run between a client’s request and a finalised verdict.

Submit. The client hashes the media, uploads the bytes to IPFS, Arweave, or its own S3 bucket, and opens a job on-chain with the hash, the locator, and a fee.
Accept. Workers polling the program see the open job and claim a slot. Slot count and stake floor are governance parameters, not per-job choices.
Fetch and verify. Each worker downloads the media from the locator and recomputes the hash. A mismatch aborts the job for that worker — this is the check that stops a requester from serving different bytes to different operators.
Detect. The worker runs its own model. The protocol imposes no architecture, no framework, and no latency target beyond the commit deadline.
Commit. The worker publishes SHA-256(score ‖ model_id ‖ salt).
Reveal. After the commit deadline, each worker publishes the plaintext. The program verifies the digest.
Score and settle. Revealed scores are combined under a reputation weighting, the fee is split, reputations are updated, and the job is finalised.

The sixth and seventh steps are where the design earns its keep. Because every commitment is timestamped before any reveal exists, the ordering of opinions is not something the network operator can assert after the fact — it is a property of the ledger.

Economic security: stake, reward, and graduated slashing

Reputation alone is not enough, because reputation is cheap to rebuild under a new key. DFPN pairs reputation with stake denominated in the DFPN SPL token, so that a worker who wants to be trusted has something to lose.

The design deliberately separates two very different offences. Protocol violations — committing and never revealing, revealing a mismatched preimage, serving a verdict on media whose hash does not match — are mechanical, provable on-chain, and slashed. Accuracy disputes are not mechanical. A model that is honestly wrong on a hard sample is not the same thing as an operator running a random number generator, and a protocol that confiscates stake for the former will drive away exactly the careful operators it needs.

DFPN handles that split with severity tiers running from roughly one per cent to half of stake, a challenge window during which a challenger must post their own stake to contest a verdict, and reputation decay as the primary instrument for persistent underperformance. Being slowly de-weighted for six months of mediocre calls is a proportionate response; losing half your stake for one hard sample is not.

Detector drift and rotating benchmarks

A paid model registry has a subtle failure mode: if the benchmark used to score models is public and static, it stops being a benchmark and becomes an attack surface. Operators optimise for the test set, scores rise, and real-world performance does not move at all.

The mitigation is hidden, rotating evaluation sets managed under governance. Operators know that scoring happens and roughly how, but not which samples will appear next. This is the same reason a machine-learning team holds out a test set, applied to a setting where the people being tested have a direct financial incentive to see it.

DFPN resources: dfpn.cryptuon.com · Documentation · Source on GitHub

Integrating the verification API

For a consuming application the network looks like an async job queue. Submit, wait, read the verdict and the dissent.

import { DfpnClient } from "@cryptuon/dfpn-sdk";
import { Connection, Keypair } from "@solana/web3.js";

const client = new DfpnClient({
  connection: new Connection(process.env.SOLANA_RPC_URL!, "confirmed"),
  payer: Keypair.fromSecretKey(/* ... */),
});

const media = await fs.readFile("./contested-clip.mp4");

const job = await client.submit({
  media,                       // hashed locally; bytes are uploaded, not put on-chain
  mediaKind: "video",
  storage: "ipfs",
  feeLamports: 2_000_000,
  minWorkers: 5,
});

const verdict = await client.awaitVerdict(job.address, { timeoutMs: 180_000 });

console.log(verdict.scoreBps);        // reputation-weighted aggregate, 0..10000
console.log(verdict.reveals.length);  // how many operators actually answered
console.log(verdict.dispersion);      // spread across reveals — the number that matters

// Route by consequence, not by a single threshold.
if (verdict.scoreBps > 8_000 && verdict.dispersion < 1_200) {
  await autoLabel(job.address);       // strong, tight consensus
} else if (verdict.scoreBps > 6_000) {
  await queueForHumanReview(job.address);
}

The dispersion field is the one most integrations under-use. A tight cluster at 0.87 and a bimodal split averaging 0.87 are completely different epistemic situations, and only the first justifies an automated action.

How the approaches compare

Approach	What it proves	Where it genuinely wins	Where it falls down	Maturity
DFPN (open detection network)	Several independent models judged the artefact, and here is the tamper-evident record	Detector diversity, censorship resistance, contestable audit trail, no single vendor veto	Higher latency than a local call, cost per job, needs enough operators to be meaningfully diverse	Active development
Centralised detection API (e.g. Reality Defender, Sensity)	One vendor’s model returned a score	Lowest integration effort, predictable latency, commercial support and SLAs, mature tooling	One model family, one blind spot, a response body is not evidence, vendor can decline service	Production, widely deployed
C2PA provenance	This file carries a signed capture-and-edit history	Strongest possible answer when the signature is present and the chain of edits is intact	Silent on unsigned media, which is most media; a stripped manifest looks identical to no manifest	Open standard, growing adoption
Generative watermarking	The generator that made this marked its own output	Near-zero cost and high reliability for cooperating generators	Only covers generators that opt in; absence of a mark proves nothing at all	Vendor-specific, uneven
In-house detector	Your model returned a score on your hardware	Best privacy — media never leaves your network — plus lowest marginal cost and latency	You are the only opinion; independence is exactly what you cannot self-certify	Depends entirely on your team

The honest reading of that table is that DFPN is not a replacement for three of the five rows. If you control the generator, watermark. If you control the camera, sign with C2PA. If your media is too sensitive to leave the building, run in-house and accept that you are your own auditor. DFPN’s claim is narrower: when the artefact arrives from outside, carries no provenance, and the verdict may be contested by someone who does not trust you, an open network with a public record is the only one of these that produces something an adversary can check.

Business outcome: what an auditable verdict is worth

The value of the network is not the classification. It is the elimination of two specific categories of cost.

Dispute cost. A platform that removes content on a detection verdict eventually faces an appeal. With a vendor API, handling that appeal means re-running the same model and hoping it agrees with itself, or paying a second vendor for a fresh opinion with no record of the first. With an on-chain trail, the appeal starts from an immutable record of five independent opinions, their spread, and their timing. The investigative work collapses from a re-litigation into a lookup.

Vendor concentration risk. Any organisation whose moderation pipeline depends on one detection API has an operational dependency it cannot hedge. Price changes, terms-of-service changes, and model retirements all land without negotiation. An open network with multiple operators turns that from a counterparty risk into a market.

There is a third, softer benefit for newsrooms and provenance teams: publishable evidence. A correction that says “our verification vendor flagged this” is an assertion. A correction that links to a verdict with five reveals, a timestamp, and a reproducible content hash is a demonstration. For editorial credibility, that difference is the entire point.

Cryptuon has written before about the wider family of this design in Verifiable On-Chain AI Without a Trusted Oracle, which covers the same trust question for LLM inference and market resolution, and about the underlying research lineage on the research page.

Limitations

Current limitations

Detection is probabilistic, and the protocol cannot change that. DFPN improves the process by which a verdict is produced and recorded. It does not make any individual model better, and a network of five mediocre detectors returns a well-audited mediocre answer.
Operator diversity is an assumption, not a guarantee. If most operators happen to run checkpoints derived from the same base model, the network’s ensemble advantage is largely illusory. Encouraging genuine architectural diversity is a governance and incentive problem that is not fully solved.
Latency is measured in the tens of seconds at best. A commit window and a reveal window are sequential by construction. Anything that needs a synchronous answer inside a request cycle should call a local model and use the network asynchronously for the record.
Media availability is the client’s problem. The chain holds the hash; if the IPFS pin lapses or the S3 object is deleted, the verdict survives and the evidence it refers to does not.
Cross-modal coverage is uneven. Image detection has the deepest model ecosystem; audio and long-form video are harder, slower, and have fewer mature open checkpoints for operators to run.

Roadmap items

Richer reputation weighting that accounts for a model’s demonstrated performance by media type rather than a single scalar per operator.
Structured dissent in the verdict record, so a persistent minority position is preserved as a first-class object rather than inferred from spread.
Tighter integration between provenance and detection, so a job that arrives with an intact C2PA manifest is scored differently from one that arrives bare.
Governance tooling for rotating benchmark sets, including the process for retiring a compromised set without disclosing its contents.

Frequently Asked Questions

What is a decentralized deepfake detection network?

It is a protocol where independent operators run their own detection models and are paid to produce verdicts on submitted media, with the coordination, payment, and record-keeping handled on-chain rather than by a single company. DFPN is Cryptuon’s implementation on Solana: workers stake, commit their scores, reveal them after a deadline, and a reputation-weighted consensus produces a verdict with a permanent audit trail.

How does commit-reveal stop operators from copying each other?

During the commit window a worker publishes only SHA-256(score ‖ model_id ‖ salt), from which the score cannot be recovered. No worker can see another’s answer until every commitment is already fixed on-chain. After the reveal deadline the plaintexts are published and verified against the digests, so a copied answer either does not exist yet or does not match its commitment. The random per-job salt is what makes the small score space un-invertible.

Is the media itself stored on the blockchain?

No. Only the SHA-256 content hash and a storage locator go on-chain. The bytes live in IPFS, Arweave, or the requester’s own object storage. This keeps cost bounded and avoids permanently republishing sensitive material, at the explicit cost of the chain guaranteeing integrity but not availability.

Can operators be slashed for being wrong?

Protocol violations — failing to reveal, revealing a preimage that does not match the commitment, or scoring media whose hash does not match the job — are provable on-chain and are slashed on a graduated severity schedule with a challenge window. Ordinary accuracy disagreements are handled through reputation decay instead, because confiscating stake for a hard sample would drive away careful operators and leave the network to gamblers.

How does DFPN relate to C2PA and content provenance?

They answer different questions and are complementary. C2PA attests where a file came from and how it was edited, and it is the stronger answer when the signature is present and intact. Detection asks whether an artefact looks manipulated when no such signature exists, which describes most media in circulation. A serious verification pipeline checks provenance first and falls back to detection.

What do I need to run a DFPN node?

A GPU capable of running your chosen detection models, the Rust worker daemon, at least one model exposed as a Python subprocess or local HTTP service, and enough DFPN stake to clear the current floor. The worker polls for open jobs, fetches and hash-verifies media, runs detection, commits, and reveals. Full setup steps are on the DFPN site and in the documentation.

The bottom line

Deepfake detection is not primarily a modelling problem any more. Good open checkpoints exist, and they get better every quarter. The unsolved problem is institutional: who do you believe, how do you prove what you were told, and what happens when the answer is contested by someone who has every reason to doubt your vendor.

DFPN’s bet is that those questions are answered by protocol design rather than by accuracy percentages. Independent operators remove the correlated blind spot. Commit-reveal removes the incentive to free-ride. Staking and graduated slashing give the honest operator something to defend and the dishonest one something to lose. And a hash on Solana turns a verdict from an assertion into a record that outlives the company that produced it.

If you are building a verification pipeline, want to run a node, or need the verification API in front of a moderation queue, describe your project — or see how we scope detection and provenance evaluations.