Skip to content
dfpn. Read the protocol

Home · How it works

From a hash to a signed verdict

dfpn splits cleanly in two: coordination and settlement live on Solana; media retrieval and detection live on a DePIN network of operator GPUs the protocol never touches. That split is what makes the AI verifiable — the chain doesn't run the model, it verifies a staked consensus of the operators who did. Here is exactly what runs where, and how a request becomes a verdict.

Lifecycle of a verdict

Seven steps, fully on the record

  1. 01

    Submit

    A client posts a media hash, storage URI, fee, deadline, and required modalities to the Analysis Marketplace program.

  2. 02

    Route

    Eligible workers poll for matching requests. Assignment is randomized and diversity-constrained to limit gaming.

  3. 03

    Analyze

    Each assigned worker fetches the media from off-chain storage, verifies it against the on-chain hash, and runs detection locally. The protocol never sees inference.

  4. 04

    Commit

    Each worker posts a SHA-256 commitment of its result plus a salt. Nobody can copy a result they have not yet read.

  5. 05

    Reveal

    After the commit window closes, workers reveal their results and the chain verifies each one against its commitment.

  6. 06

    Consensus

    A reputation-weighted aggregation produces the verdict label and a confidence score.

  7. 07

    Challenge & reward

    A challenge window allows disputes before payout. Workers and the model developers whose models were used are paid from the fee; wrong, late, or no-show workers can be slashed.

submit ─▶ route ─▶ analyze ─▶ commit ─▶ reveal ─▶ consensus ─▶ challenge ─▶ reward
   │                                                                         │
 hash + fee                                                        pay accurate workers
 (media stays off-chain)                                           slash the rest

On-chain (Solana · Anchor 0.30.1)

Five programs hold the rules

Content Registry

Stores media hashes and provenance metadata. The chain holds hashes, never the media.

Analysis Marketplace

Handles request creation, worker assignment, and result tracking through commit and reveal.

Model Registry

Holds model metadata, versioning, and developer stake. Permissionless — any developer can register a model.

Worker Registry

Tracks worker staking and reputation. Reputation feeds directly into consensus weighting and rewards.

Rewards + Treasury

Distributes epoch rewards, executes slashing, and routes fee splits to workers, model developers, treasury, and the insurance pool.

Off-chain services

Where the compute actually happens

Worker daemon

Rust · Tokio · Clap

Polls the indexer for matching tasks, fetches media, runs detection on the operator’s own GPU, then commits and reveals.

Indexer + REST API

Rust · Axum · Tantivy

Mirrors on-chain state for fast queries. Explicitly untrusted — clients always verify against on-chain state.

TypeScript SDK

TypeScript · @solana/web3.js

The client integration surface: submit requests, await consensus, read the audit trail.

Vue 3 dashboard

Vue 3 · Chart.js

Monitoring UI for requests, workers, and network health.

Storage model

Available, but never trusted for integrity

Media lives off-chain

Media is stored on IPFS, Arweave, or S3 and referenced by a URI. The chain stores only the content hash and metadata. Workers retrieve the bytes and verify them against the on-chain hash before running detection.

Indexers are untrusted

The indexer and REST API exist purely for speed. They are explicitly untrusted: clients verify every claim against on-chain state, so a compromised indexer cannot forge a verdict or substitute media.

For the adversary classes this design defends against — malicious workers, model developers, sybils, cartels, spammers, and storage attackers — see the threat model.

Ready to plug in?

Run a worker on your GPUs, register a detection model, or wire verdicts into your trust & safety stack.

Run a node Use cases