Trust Engine

A PRIVACY‑PRESERVING PROVENANCE PROTOCOL

August 2025.

01 — ABSTRACT

Abstract

Everyone defines trust differently in digital media. A publisher cares about reputational credibility and timing whereas a platform cares about policy precedence (who filed first, who’s verified). Think about courtrooms. They care about verifiable chain of custody whereas a retail consumer cares about attribution (“who made this meme?”). Existing solutions (Fox News's & Polygon's Verify, Truepic, Adobe C2PA/CAI, Numbers Protocol) all try to impose one definition of authenticity, or lock it into their ecosystem. Trust Engine doesn’t define trust. Rather, the Trust Engine protocol is built on the pretext that trust means different things to different people. We take a binary approach to trust. We connect the dots between two entities. A human and a piece of media.

Trust Engine enables a tamper-proof, privacy-preserving connection between digital media and the entity that registers it on the protocol. This is to empower the internet of consumers to make informed decisions. The protocol doesn't determine "truth", adjudicate ownership, or decide content accuracy. Rather, digital media registered on the protocol can carry a portable badge that resolves to an entry on our public registry, linking the media (in its hash form) to its registrant. Since the media piece is in its hash form, it is by nature privacy-preserving, meaning no one can derive the original digital media piece from it by simply browsing the registry. To improve the informed decision-making process for the internet of consumers (publishers, platforms, courts, etc.), registrants can optionally authenticate their social media profiles and conduct a Proof of Humanity process.

Currently built for developers at this stage, Trust Engine provides a straightforward API/SDK integrations to register media and a lightweight widget to display portable badges on the digital media piece in minutes. The result is an internet-scale, verifiable rail for attribution: simple to integrate, neutral in judgment, and strong enough for newsroom workflows, platform policy, legal discovery, and everyday credit.

02 — PROBLEM & CONTEXT

Problem & Context

The rampant rise of digital media distribution has made it nearly impossible for consumers to verify the responsible entity for what they see online, leading to severe misattribution. AI‑generated media compounds this by flooding platforms with unattributed content.

Bad actors exploit the confusion to steal, misrepresent, or falsely claim authorship over both human and AI creations. Platforms are forced to make policy calls with weak signals; publishers face reputational and legal risk; audiences are left guessing. The result is a systemic trust failure at internet scale.

03 — WHO WE SERVE (ICP) & PAIN POINTS

Who We Serve (ICP) & Pain Points

Primary ICP

Developers building for content creators and for content platforms.

01 — Attribution & Provenance Infrastructure Complexity

Pain:

Building attribution from scratch is prohibitively complex. Teams burn 25–100% of their time maintaining crypto/blockchain/legal toolchains¹. No API delivers privacy‑preserving, universal attribution.

Trust Engine:

A drop‑in SDK that handles crypto, blockchain anchoring, and privacy in three lines of code.

02 — Fragmented Attribution Data

Pain:

Attribution is scattered across multiple platform APIs with inconsistent models.

Trust Engine:

Single API for universal, portable attribution across platforms.

03 — Integration Friction & DX

Pain:

Much integration time is lost to auth, docs gaps, workflow weirdness. Devs want 1‑2‑3 guides and trials.

Trust Engine:

Best‑in‑class DX, interactive docs, clear error handling.

04 — SOLUTION OVERVIEW (NON‑TECHNICAL)

Solution Overview (Non‑Technical)

Trust Engine provides a universal, privacy‑preserving way to link digital media to a registrant without exposing the file. We don't decide rightful ownership or content accuracy. We inform decision-making for digital media consumers.

Proof of Existence

Blockchain timestamps: "Wallet A registered fingerprint H at time T."

Cryptographic Integrity

SHA-256 hashing proves the registrant had access to the exact file content at registration time.

Tamper Evidence

Any content changes produce a completely different hash, indicating a clear difference between the original and modified content.

Privacy Preservation

Only fingerprints + minimal metadata stored; raw content never exposed or transmitted.

Competing Claims Transparency

Multiple registrations for the same content are surfaced chronologically with identity proofs.

Neutral Infrastructure

Provides verifiable facts (timing, identity, hash consistency) without making ownership or accuracy judgments.

05 — REAL-WORLD USE CASES

Real-World Use Cases

To accomodate a varied definition of trust, Trust Engine serves diverse decision-makers across media, legal, platform, and enterprise contexts. Each use case demonstrates how immutable timestamps, identity proofs, and competing-claims visibility enable better-informed decisions.

Use Case 1 — Publisher's Dilemma (Breaking-News Photo)

Exploring 1 of 16 detailed scenarios

1 / 16

Navigate 16 Use Cases:

Click any number

...

Context & Decision-Maker

News publisher encounters a digital media authenticity challenge.

The Situation

Two registry entries exist for the same hash. Entry A: anonymous wallet, registered 2 hours ago. Entry B: wallet linked to @Reuters_photographer (Twitter verified, ~50k followers, professional track record), registered 6 months ago.

Critical Decision Point

Should the photo be published and credited to the Reuters photographer?

Available Evidence

Trust Engine provides these verifiable signals:

▪Temporal precedence

▪Identity proofs (social link)

▪Fingerprint match

▪Public registry via trust badge deep-link

Resolution & Value

Editorial confidence and defensible crediting based on precedence + verified identity; reduced reputational risk; auditability.

← Previous: Research Priority & Academic IntegrityNext: Platform Content-Policy →

06 — THREAT LANDSCAPE & PUBLIC INTEREST

Threat Landscape & Public‑Interest Urgency

Manipulated Media: National‑Security‑Scale Risk

US agencies (NSA, FBI, CISA) warn deepfakes threaten NSS/DoD/DIB; they publish mitigation guidance.

Wartime Psy‑Ops

2022 Zelensky surrender deepfake; better forgeries could be worse

Financial Markets

Fake Pentagon explosion image briefly moved US equities—real financial impact

Elections

AI robocalls impersonated sitting president; charges and penalties followed

Courts

Rising "deepfake defense"; rules and standards being revisited

Financial Crime

FinCEN warns GenAI used to subvert KYC and commit fraud

Law Enforcement

AI‑generated CSAM burden escalating

NIST AI Safety Institute

Explicitly calls for provenance infrastructure as public‑interest tooling.

07 — SYSTEM ARCHITECTURE (HIGH‑LEVEL)

System Architecture (High‑Level)

Core Mechanism

Immutable cryptographic linkage between creator (wallet) and content fingerprint (hash/commitment), anchored with blockchain timestamps and optional IPFS‑backed metadata, all without exposing raw content.

1. Client Hash
SHA-256 of media

2. Claim Hash
Hash of metadata

3. IPFS Upload
Metadata → CID

4. On-Chain
Immutable record

5. Registry
Combined display

08 — SYSTEM ARCHITECTURE (LOW‑LEVEL)

System Architecture (Low‑Level)

1) Client‑Side Hashing (Privacy‑Preserving)

Files are hashed locally in the browser/client to generate a unique SHA-256 fingerprint. The original file never leaves the user's device during this process, ensuring privacy-by-design.

// Web Crypto API example - runs entirely in browser
async function hashFile(file) {
    const buf = await file.arrayBuffer();
    const hash = await crypto.subtle.digest('SHA-256', buf);
    return Array.from(new Uint8Array(hash))
        .map(b => b.toString(16).padStart(2, '0'))
        .join('');
}

Privacy Guarantee: The hash uniquely identifies the content but cannot be reversed to recover the original file. This enables verification without exposure.

2) IPFS Metadata Storage (Optional but Recommended)

Rich metadata is stored on IPFS for decentralized, content-addressed retrieval. Only metadata is stored, never the actual media content.

IPFS Data Structure:

{
  "file_metadata": {
    "contentTitle": "Human-readable content title",
    "fileName": "original-filename.jpg", 
    "fileSize": 1234567,
    "mimeType": "image/jpeg"
  },
  "public_metadata": "Optional description, tags, or context"
}

Required Fields

• file_metadata object
• contentTitle, fileName
• fileSize, mimeType

Optional Fields

• public_metadata (user descriptions)
• Custom metadata fields
• Tags and categories

Retrieval URL: https://trustengine-ipfs.quicknode-ipfs.com/ipfs/{CID}

3) Blockchain Registration (Solana)

The on-chain ContentRegistration account stores minimal, immutable data. Each registration costs ~200 bytes of blockchain storage.

pub struct ContentRegistration {
    pub content_hash: [u8; 32],    // SHA-256 hash of the media file
    pub claim_hash: [u8; 32],      // Hash of registrant's claim metadata  
    pub creator: Pubkey,           // Registrant's wallet address
    pub ipfs_cid: String,          // Pointer to IPFS metadata (optional)
    pub timestamp: i64,            // Unix timestamp of registration
}

Field Explanations:

• content_hash: SHA-256 fingerprint uniquely identifying the media
• claim_hash: Hash of registration metadata (prevents tampering of claims)
• creator: Solana wallet public key that submitted the registration
• ipfs_cid: Link to decentralized metadata (can be empty string if no metadata)
• timestamp: When the registration was anchored on-chain

4) Registration Data Flow

1. Client Hash
SHA-256 of media

2. Claim Hash
Hash of metadata

3. IPFS Upload
Metadata → CID

4. On-Chain
Immutable record

5. Registry
Combined display

Data Separation Benefits

• On-chain: Immutable proofs, tamper-evident timestamps
• IPFS: Rich metadata, decentralized but updatable context
• Privacy: Original files never stored anywhere

Required vs Optional

• Required: content_hash, claim_hash, creator, timestamp
• Optional: ipfs_cid (can be empty for minimal registrations)
• Never stored: Private keys, raw media content

5) Wallet Types & Transaction Flows

Managed Wallets

API‑assisted signing with server fee‑payer sponsoring SOL transaction costs for fast confirmations.

Client → Hash → API → Signed TX → Blockchain

Self Wallets

Action‑link flow generates unsigned transaction for Phantom/Solflare wallet signing in‑browser.

Client → Hash → API → Action Link → User Signs → Blockchain

6) Storage & Privacy Summary

Stored On-Chain

• Content hash (32 bytes)
• Claim hash (32 bytes)
• Creator wallet (32 bytes)
• Timestamp (8 bytes)
• IPFS CID (variable, optional)

Stored in IPFS

• File metadata (name, size, type)
• Content title/description
• Public metadata/tags
• User-provided context

Never Stored

• Raw media content
• Private keys
• Sensitive file paths
• Hidden metadata/EXIF

9 — REGISTRY, DISCOVERY, & IDENTITY

Registry, Discovery, and Identity Integration

What the Registry Serves

• Binary, privacy‑preserving linkage: fingerprint → registrant with timestamps
• Public verifiability & immutability: Anyone can verify a hash was registered at time T by account A
• Identity layering: Users can connect social accounts and complete Proof of Humanity via self.xyz
• Creator control: We do not dictate disclosures; no ownership arbitration and no disclosure arbitration

Back‑dated Creations

Authors can anchor fingerprints of prior works now. This doesn't rewrite history; it creates a tamper‑evident claim from this point forward.

Judgment Targets

Editorial, policy, legal, attribution, and investment decisions—hence neutral data, not verdicts.

10 — VERIFICATION & TRUST STAMPS

Verification & TRUST Stamps

Search Methods

By File Upload

Local hash generation

By Hash String

Direct SHA‑256 lookup

By Creator Address

Wallet‑based search

Multi‑Claim Surfacing

We enumerate competing claims for the same fingerprint and order them chronologically.

TRUST Stamp Widget

A single‑tag script that can auto‑scan media elements, query the registry, and overlay a verification stamp:

<script
    src="[PARTNER_WIDGET_URL]"
    data-api-base-url="https://core-api-server.onrender.com"
    data-stamp-position="top-right"
    data-stamp-size="medium"
    data-auto-scan="true">
</script>

Verification Response (Illustrative)

{
    "searchMode": "content_hash_and_wallet",
    "totalResults": 1,
    "registrations": [{
        "contentHash": "a1b2c3d4...",
        "registeredBy": "9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM",
        "timestamp": "2024-01-15T14:30:25.000Z",
        "validationStatus": "Verified",
        "consensus": "85%",
        "explorerUrl": "https://explorer.solana.com/address/...",
        "onChainData": {}
    }]
}

Utility Examples

News Photo Checks

Editorial verification

E‑commerce Assets

Product authenticity

NFT Platforms

Provenance display

Academic Materials

Research verification

11 — PRIVACY MODEL & HASH ABSTRACTION

Privacy Model & the "Hash Abstraction" Debate

Where Privacy Actually Matters

1. Bulk Protection Against AI Training

Registry can't be mass‑scraped for training data absent creator consent; badges don't yield systematic harvesting.

2. Legal/Regulatory Compliance

Privacy‑by‑design helps with GDPR/CCPA and emerging AI rules; essential for enterprise and international adoption.

3. Registry‑First Discovery Protection

Browsing hashes doesn't reveal files; protects early registrations, sensitive content, and competitive workflows.

If Privacy Were Removed

Simpler architecture, clearer UX, easier developer integration

BUT: Compromised registry‑first privacy

If Privacy Is Maintained

Stronger positioning, systematic protection at scale, compliance‑friendliness, and creator trust.

12 — DEVELOPERS: JOURNEY & DX

Developers: Journey & DX

Entry Path

trustengine.org → /docs

Key Claims:

• Privacy‑first (client hash; only SHA‑256 onchain)
• No blockchain expertise needed (REST abstracts it)
• Instant verification
• Portable trust signals

Documentation Layout

Guides

API Reference

SDK (JS/TS)

CLI

TRUST Stamp

API Examples

Wallet Creation

POST /create-wallet
→ returns { 
    walletAddress, 
    chain, 
    transactionSignature, 
    explorerUrl 
}

Registration

POST /register
→ hash first (client), 
  optional IPFS metadata, 
  then onchain record

DX Patterns

SPA

SDK + wallet connect

Server Apps

REST

Static Sites

Widget

Mobile

Native hashing + HTTP

CLI Example

trust-engine-cli register \
  --file example.txt \
  --contentTitle "My Document" \
  --walletType managed

Architecture Flow

Developer

→

Create Wallet

→

Hash Content

→

Onchain

↓

Registry

TRUST Stamp

Portable

13 — CRITIQUES & OUR RESPONSE

Critiques & Our Response (Infrastructure vs. Arbitration)

False Premise

"Your data could lead users to wrong decisions."

Rebuttal

We're infrastructure. Like DNS or WHOIS, we publish neutral facts. Without Trust Engine, decisions are less informed, driven by unverifiable signals and subjective policy. With Trust Engine, decisions cite immutable timestamps, identity proofs, and transparent multi‑claim chronology.

Publisher Scenario

With TE: Same likely decision (credit the Reuters photographer), but now justified by precedence and verified identity rather than pure reputation.

Platform Policy Scenario

With TE: Honor/reject a takedown by referencing temporal precedence and identity proofs; outcomes become consistent and defensible.

Bottom Line

Imperfect information > no information. We increase transparency and reduce arbitrariness without removing user agency.

14 — HOW WE DIFFER FROM NFTS

How We Differ from NFTs (and Interoperate)

What NFTs Actually Prove

Uniqueness of a token, not authenticity/uniqueness of the media. Metadata pointers are often mutable; many contracts don't anchor a content hash onchain; link rot and "right‑click‑mint" abound.

Trust Engine vs. NFTs

Aspect	Trust Engine	NFTs
Object of Proof	Anchors the media fingerprint itself	Anchors a token + URI
Purpose	Provenance protocol (who claimed fingerprint H, when)	Transferable property primitives
Hash‑First	Fingerprint is canonical; not a mutable pointer	Typically mutable metadata pointers
Privacy	Keeps content private	Typically publicizes it
Conflicts	Enumerates competing claims for same fingerprint	Don't handle duplicates well
Identity	Optional, binary identity linkages without reputation scoring	Weakly modeled identity and precedent

Could NFTs Have Done This?

Only with strict conventions (onchain hashes at mint, immutable metadata, identity proofs, duplicate detection). Even then, NFTs remain about transferable tokens; TE remains about neutral provenance for any media, without minting or exposure.

Complementarity

• NFTs can reference a TE fingerprint
• Platforms can require TE match before display/sale
• Creators can use TE for author/precedence claims and NFTs for collectibles/access/membership

One‑Liner #1

"NFTs prove who owns a token. Trust Engine proves who claimed a media fingerprint and when—without revealing the media."

One‑Liner #2

"NFT metadata points to media; Trust Engine anchors the media's fingerprint itself."

Closing

Trust Engine's strength is architectural simplicity with strong guarantees: client‑side hashing, blockchain timestamps, and optional IPFS metadata create immutable, portable, privacy‑preserving provenance that scales across platforms and use cases. We surface competing claims, remain neutral on ownership and disclosure, and provide optional identity proofs—so editors, platforms, courts, and consumers can make better, faster, and more defensible decisions.