Multiple independent workers per request
Every analysis request is dispatched to several independent workers running their own models on their own hardware. A commit-reveal flow stops them from copying each other before the consensus window closes.
Synthetic media is a public-trust problem. Detection should not be a monopoly.
The decentralized immune system against synthetic media.
dfpn is a coordination layer on Solana for deepfake detection. Independent operators run their own detection models on their own GPUs. Commit-reveal stops them from copying each other. Stake, rewards, and slashing keep them honest. No central authority decides what counts as real.
Modalities
image · video · audio
covered by the reference worker client
Coordination
commit · reveal · consensus
on-chain audit trail per request
Incentives
stake · reward · slash
DFPN SPL token settles each epoch
The problem
Synthetic media is cheap. Trust is not.
Generation outpaces detection
Face swaps, voice clones, AI-generated images, and manipulated video are all easier to produce each quarter. Any defender that depends on a single static model loses ground fast.
Centralized detection is a chokepoint
A handful of vendors decide what counts as "real" for billions of people. That is a single point of failure for outages, for policy capture, and for adversaries who only need to compromise one company.
Black boxes do not survive scrutiny
Newsrooms, courts, and platforms need to show their work. A verdict without an audit trail is worth less than no verdict at all.
dfpn's bet is straightforward: economic incentives plus independent operators plus on-chain transparency produces more durable detection than any single vendor can ship. Detection becomes a market, not a monopoly.
How dfpn thinks
Six properties the protocol is built around
Stake, slash, repeat
Workers and model developers post DFPN stake before they can participate. Accurate, on-time work earns a share of the request fee. Fraud, collusion, or missed deadlines get slashed and erode reputation.
Bring your own model, bring your own GPU
The protocol is the coordination layer, not a model provider. Operators choose their algorithms; model developers publish metadata on-chain and earn whenever a worker runs their model on a paid request.
Every verdict has a paper trail
Request, assigned workers, commitments, reveals, and the final consensus verdict are all anchored on Solana. Anyone can reconstruct how a piece of media was judged and which models contributed.
No central inference, no central kill switch
dfpn never sees the inference itself. If a single operator drops offline, the rest of the pool keeps serving requests. Detection capacity scales with whoever wants to plug in a GPU.
Diversity constraints + challenge windows
Random assignment, reputation-weighted aggregation, and a short challenge window before slashing make cartels expensive and slow. Diversity of models and operators is treated as a security primitive.
Lifecycle of a verdict
From "is this real?" to a signed, on-chain verdict
01 · submit
Submit
Client posts a media hash, fee, deadline, and required modalities to the analysis marketplace program.
02 · route
Route
Workers poll for matching requests. Assignment is randomised to limit gaming.
03 · analyze
Analyze
Each worker fetches the media from off-chain storage and runs detection locally. The protocol never sees inference.
04 · commit
Commit
Workers post a SHA-256 commitment of their result plus a salt. Nobody can copy what they have not yet read.
05 · reveal
Reveal
After the commit window closes, workers reveal results and the chain checks each one against its commitment.
06 · consensus
Consensus
A reputation-weighted aggregation produces the verdict and a confidence score.
07 · reward
Reward
Workers and the model developers whose models were used are paid out of the fee. Wrong, late, or no-show workers can be slashed.
On-chain programs: content registry · analysis marketplace · model registry · worker registry · rewards & treasury.
Who runs the network
Three roles, three incentive surfaces
Node operators
GPU operators, infrastructure providers
Stake DFPN, run the worker daemon on your own GPUs, and earn a share of every request you process accurately. Worker stake floor: 5,000 DFPN. Hardware target: RTX 3080-class GPU or better.
65% of request fees
Clients & platforms
Social platforms, newsrooms, content-trust teams
Submit images, video, or audio for analysis through the TypeScript or Python SDK. Get a consensus verdict from several independent workers plus a full on-chain audit trail. Fees are paid in SOL (DFPN discount optional).
Per-request fee, paid in SOL
Model developers
ML researchers, detection algorithm authors
Register a detection model on-chain, post the developer stake, and earn a cut of every request that runs through your model. Modalities currently supported by the worker reference client: image, video, audio, face, voice.
20% of request fees
Why decentralized matters here
Detection is a civic problem, not a SaaS feature
Diverse models survive adversarial drift
A single vendor optimizes one model family. dfpn rewards model diversity directly: the more independent detectors register and run, the harder it is for any one generator to game the whole network.
No vendor can rewrite the verdict
Every commitment, reveal, and aggregated verdict is anchored on Solana. There is no admin endpoint that silently flips a result, no off-the-record reweighting of model scores. The audit trail is the product.
Open participation, capped power
Anyone can stake and run a worker. Stake floors and reputation weighting keep sybil attackers expensive, and per-epoch caps mean even well-funded operators cannot quietly become the network.
Censorship resistance for verifiers
Journalists, content-trust teams, and platforms can submit requests without first signing a vendor contract. If one operator refuses to serve a request, others will — that is what the open pool is for.
Stack
What the reference implementation is built on
| Layer | Components |
|---|---|
| Blockchain | Solana, Anchor 0.30.1, SPL Token |
| Worker client | Rust, Tokio, Clap |
| Indexer | Rust, Axum, Tantivy |
| Detection runtime | Python, PyTorch (model-dependent) |
| SDK | TypeScript, @solana/web3.js |
| Dashboard | Vue 3, TypeScript, Tailwind, Chart.js |
Specific architectures, modalities, and performance numbers for the reference detection models are documented in the repo. We deliberately don't republish benchmark figures here — they evolve, and the README is authoritative.
Common questions
What teams ask before integrating
+ What problem is dfpn actually solving?
Synthetic media — face swaps, voice clones, AI-generated images and video — is getting cheaper to produce and harder to spot. Centralized detection services concentrate that authority in a few companies; they create single points of failure and an opaque definition of "real." dfpn decentralizes detection so no single party owns the verdict.
+ Is dfpn a deepfake detection model?
No. dfpn is a coordination layer. Detection models are run by independent operators using their own hardware. The reference worker client ships with four pre-configured models covering face manipulation, AI-generated images, video authenticity, and voice cloning, but operators and model developers can register more.
+ How does economic security actually work here?
Workers stake DFPN before they can serve requests. They earn a share of fees when their results agree with consensus, and they get slashed for invalid results, fraud, or missed deadlines. Model developers stake separately and earn a cut whenever their model is used.
+ Where does inference actually run?
Entirely off-chain, on operator hardware. The on-chain programs track request lifecycle, commitments, reveals, scoring, and payouts. The chain holds hashes and metadata, not media.
+ How is collusion prevented?
Commit-reveal stops one worker from copying another. Random assignment, diversity constraints, reputation weighting, and a challenge window before slashing make coordinated attacks costly. The full threat model is in the dfpn docs.
+ Is this production-ready today?
The README is upfront about timeline: devnet, then testnet, then mainnet beta within roughly twelve to eighteen months. Read the milestone plan and roadmap in the repo before integrating.
+ What is dfpn not trying to do?
It is not a takedown service, a legal-attribution mechanism, or a private on-chain inference platform. Those are out of scope by design. dfpn answers a narrower question: "does the network agree this piece of media is manipulated, and on what evidence?"
Trust, but verify. At scale.
Read the protocol, run a worker, register a model, or integrate verdicts into your trust & safety stack. Everything is open source under MIT.