Decentralized Asset Verification Protocol

DAVP: Decentralized Asset Verification Protocol

Prove authorship, integrity, and timestamp of any digital asset - text, code, images, videos, or artworks. Verification is always free, with optional enterprise services for businesses and organizations.

#How it works

DAVP is a decentralized protocol for publishing and verifying cryptographic proofs. Truth is determined by cryptography, distribution is handled by peer-to-peer networking, and no node is ever trusted with authority.

Asset Proofs

Proof objects binding a BLAKE3 content hash to metadata and a UTC timestamp, signed by a creator Ed25519 key. Proofs are locally verifiable; the signature is the trust primitive.

Decentralized Network

Optional peer-to-peer TCP mesh with gossip replication. A tracker can help with peer discovery, but it does not certify proofs and is not an authority.

Verification

Always verify the Ed25519 signature over the proof payload. Optionally verify the asset hash if you have the bytes. Issuer certificates are an optional identity label resolved off-chain.

Monetization

Protocol usage is always free. Optional enterprise services can exist out-of-band (e.g., bulk registration, legal-grade timestamps, operating infrastructure, or API access) without protocol-level payment enforcement.

Security

BLAKE3 hashing and Ed25519 signatures. Metadata is fully signed. Proofs are immutable. Protocol versioning ensures forward compatibility. No trust by position—only cryptographic trust.

Adoption

Reference Rust implementation with client, node, and CNT. Start with text, code, and images. SDK and documentation provided. Scale as invisible infrastructure.

#Core concepts

Understand the building blocks of DAVP: assets, hashes, proofs, and verification identifiers. These primitives are cryptographically simple and locally verifiable.

Asset

Any digital content treated as raw bytes (typically a file). DAVP does not interpret file formats.

Asset hash (BLAKE3)

A BLAKE3 hash of the asset bytes, embedded in the proof. This is the cryptographic link between a proof and a specific byte sequence.

Proof

A signed object containing asset_hash, timestamp, asset_type, ai_assisted, and metadata. The signature is over a serialized payload and does not include the verification_id.

Verification ID

A 64-character lookup identifier generated from randomness. It is not a trust primitive and does not prove global uniqueness; authenticity comes from signature (and optional hash check).

#Issuer certificates

Optional identity labels that do not affect cryptographic validity. Certificates are fetched off-chain and can be used to associate proofs with known issuers.

Issuer certificates are an optional identity label layer. They do not change what makes a proof cryptographically valid.

  • Valid proof: signature verifies (and if asset bytes are provided, hash matches).
  • Certified proof: valid proof + issuer certificate validation succeeds for the referenced issuer_certificate_id.
  • Uncertified proof: valid proof + no issuer_certificate_id, or certificate validation fails/not found.

Certificates are fetched from https://davpfoundation.github.io/site/certs.json by default.

#Get Started

DAVP demonstration in GUI mode

Demo representation of DAVP in GUI mode

Installation

Open source Rust implementation. Run as a CLI tool, server, or embed in your app.

#Proof lifecycle

From asset bytes to a verifiable proof: hash, signature, metadata, and more.

Phase 1 — Asset intake
Read asset bytes Example: file contents
Compute asset hash asset_hash = BLAKE3(asset_bytes)
Set timestamp timestamp = current UTC time
Build signing payload asset_hash, timestamp, asset_type, ai_assisted, metadata
Phase 2 — Signing & identification
Serialize payload bincode
Sign payload Ed25519 signature with creator keypair
Derive public key creator_public_key from the keypair
Generate verification ID 64-char lookup ID derived from randomness
Phase 3 — Storage & distribution
Assemble Proof Fields + signature + verification_id
Store locally Write proof to storage_dir
Replicate to peers Peer-to-peer TCP gossip replication
Verification is offline-checkable: signature is mandatory; file hash checking is optional.

#CLI example

Generate a keypair, create a proof for any file, and verify it. All operations are local and deterministic.

$ davp keygen --new

$ davp create --file artwork.png \
              --keypair_base64 <base64> \
              --asset_type image \
              --ai_assisted false \
              --storage_dir output
→ verification_id: 12SpRWz...

$ davp verify --verification_id 12SpRWz... \
              --file artwork.png \
              --storage_dir output
→ issuer: Goolge Inc.
→ verification_id: 12SpRWz...
→ status: verified

#What DAVP is NOT

  • No global consensus, ordering, or finality
  • No blockchain, mining, or consensus mechanism
  • No global immutability guarantees across the network
  • No truth claims about metadata or real-world identity of a key
  • No global namespace or authority for verification IDs

DAVP avoids global consensus, blockchains, and trusted authorities. It is a simple, local-first protocol for cryptographic proofs.

#Storage model

Local-first storage with simple file formats. Each node’s directory is authoritative; replication is optional and best-effort.

  • Local-first: the storage directory is authoritative for a node’s proofs.
  • <verification_id>.bin: bincode-serialized Proof
  • <verification_id>.meta.bin: optional metadata containing issuer_certificate_id
  • hash_index.bin: asset_hash → list of verification_ids
  • No global state: different nodes can have different subsets; replication is best-effort.