A protocol for verdicts, not a vendor for them.

What dfpn actually is

Reduced to one paragraph: a client posts a request to a Solana program (the analysis marketplace), several workers fetch the media from off-chain storage, run their own models, commit to a hashed result, reveal the result after the commit window closes, and the chain aggregates everything into a reputation-weighted verdict with a confidence score. Workers and the model developers whose models were used are paid out of the request fee; misbehavior is slashed.

The chain holds hashes and metadata, not media. Inference happens on operator GPUs. There is no central server doing detection, and there is no admin endpoint that can quietly rewrite a verdict.

What dfpn is not

The repo’s threat-model document is unusually direct about scope. dfpn is explicitly not:

• A takedown mechanism. The protocol does not remove content from platforms or social networks.
• A legal attribution layer. It does not prosecute, dox, or identify originators of synthetic media.
• A fully private on-chain inference platform. Inference is off-chain by design; the chain coordinates and audits.
• A claim of perfect detection. The README and threat model both flag adversarial examples and the fact that generation improves faster than any one model can update.

Treating those as out of scope is a feature, not a limitation. A protocol that tries to be a court, a content moderator, and a detector at once tends to do all three badly.

The threat model in one read

The dfpn threat-model doc enumerates six adversary classes worth keeping in mind:

• Malicious workers who submit incorrect results for profit. Countered by stake + slashing and multi-worker redundancy.
• Malicious model developers who ship overfit or biased models. Countered by hidden test sets, periodic benchmark rotation, and a model-stake floor.
• Sybil attackers who run many low-stake worker identities. Countered by stake floors, reputation weighting, and per-epoch caps.
• Colluding cartels coordinating across workers and models. Countered by random assignment, diversity constraints, and a challenge window before slashing.
• Spammers who flood low-fee requests to degrade availability. Countered by dynamic fees, rate limits, and priority fees.
• External attackers against off-chain storage, indexers, or APIs. Countered by on-chain content hashes, multi-source retrieval, and the rule that indexers are never the source of truth.

Each of those is paired with a concrete mitigation in the protocol design rather than “we’ll figure it out.” That is the part of dfpn worth taking seriously: the assumption that adversaries are competent and patient.

Trust assumptions, named

The repo is also direct about what dfpn does trust:

• Solana provides finality and liveness within expected parameters. dfpn lives or dies with the L1.
• Off-chain storage links are available — but their integrity is never trusted. Workers always verify against the on-chain hash.
• Benchmarks are curated and rotated under governance. Static benchmarks become attack surfaces; rotation is part of the security model.

Project philosophy

Detection of synthetic media is sliding from “technical curiosity” toward “public infrastructure.” That transition tends to go badly when the infrastructure is owned by a single company that can change terms with a blog post. The civic case for decentralizing detection is essentially the case for decentralizing the press, the postal service, or any other trust-bearing institution: it should not be possible for one party to flip a switch and change what counts as real for everybody else.

That does not mean dfpn is anti-vendor. Centralized detection companies are doing real work and will keep shipping models. dfpn’s claim is narrower: that the final verdict layer — the one platforms, newsrooms, and trust & safety teams cite — should be reproducible, auditable, and not controlled by a single counterparty. Diversity of detectors is a security property, not a marketing point.

How dfpn relates to provenance work

Provenance standards like C2PA are complementary, not redundant. Provenance answers “where did this come from?” via signed manifests at capture time. Detection answers “does this look generated or manipulated?” via models, after the fact. Real-world trust & safety pipelines need both: provenance is strong when capture devices cooperated, detection is what you have when they did not. The C2PA comparison and Truepic comparison pages go through this in more detail.

Who is building it

dfpn is a project of cryptuon. The repository is MIT-licensed, the Solana programs use Anchor 0.30.1, the worker is written in Rust with a Python detection bridge, the SDK is TypeScript, and the documentation site is MkDocs. The README and milestone plan are the authoritative source for the timeline; the marketing claims on this site never get ahead of what is actually in the repo.

How to engage

If you run GPU infrastructure and want to operate a node, the entry path is the worker getting-started doc. If you are a platform or newsroom evaluating detection-as-a-service, the SDK guide is the right starting point — but please treat current numbers as forward-looking until mainnet beta. If you are an ML researcher with a detector, the model-developer guide explains stake, registration, and reward share.

Everything else lives on GitHub.