Skip to main content

​
General Questions

No. Trust Engine does NOT decide or arbitrate rightful ownership of digital media. Instead, it provides the transparency and context needed for consumers to make informed judgments about rightful ownership.We don’t dictate whether digital media is AI-generated, stolen, original, or rightfully owned. Rather, our system links the digital media piece to the entity who registered it on our protocol as an immutable, timestamped entry on our public registry.
  • Trust Engine doesn’t attempt to settle ownership disputes or certify originality. That’s not practical—or even possible—in an open digital ecosystem.
  • Even if a bad actor registers a stolen digital media piece before the “rightful” owner, our protocol still allows the “rightful” owner to register that same piece.
  • The transparent, public, on-chain record empowers media consumers to make informed choices with all relevant history at their fingertips.
Key point: Trust Engine’s power lies in provable attribution and open, chronological provenance—not in acting as a judge. Consumers get the factual record and evaluate credibility using the cryptographic and social signals our protocol surfaces.
Trust Engine solves the growing problem of verifying digital media authenticity in an era of AI-generated media. With deepfake fraud costing businesses an average of $500,000 per incident (Regula, 2024; Eftsure, 2025) and global damages potentially exceeding $40 billion (Deloitte, 2024), consumers and platforms need a reliable way to verify who created digital media.Unlike watermarks (which can be removed) or centralized databases (which create single points of failure), Trust Engine provides you the ability to record tamper-proof provenance records for your digital media. The provenance record is cryptographically secured on the blockchain. Media consumers can instantly confirm a digital media piece’s origin through our public registry system.
Watermarks and metadata:
  • ❌ Easily removed or manipulated
  • ❌ Altered user experience and aesthetics
  • ❌ Offer no independent, cryptographically verifiable claim on origin
Conventional content registries:
  • ❌ Depend on central authorities or platforms
  • ❌ History is only as reliable as operator integrity
  • ❌ Can be silenced, censored, or tampered with
Trust Engine’s impact for creators, developers, and consumers:
  • ✅ Directly cryptographically proves registration and attribution—every record is impossible to edit, erase, or forge
  • ✅ Digital media privacy is preserved by default; only hashes and provenance proofs are published, never private media
  • ✅ Provenance info and trust signals travel with your digital media piece anywhere online—empowering platforms, consumers and creators regardless of where or how their work is shared
Media Creators: Photographers, artists, journalists, and creators who need to prove originality and defend against theft.Platforms & Publishers: Social media platforms, news organizations, and media platforms that need to combat misinformation and verify sources.Consumers: Anyone who wants to verify the authenticity and origin of digital media they encounter online.Developers: Applications that need to integrate media verification and provenance checking into their workflows.

​
Technical Questions

Even tiny changes create completely different cryptographic hashes, so modified files won’t match existing provenance records. This is by design - it ensures integrity verification is extremely precise.Scenarios:
  • Identical file: ✅ Matches existing provenance record
  • Compressed/resized: ❌ Creates new hash, needs new registration
  • Metadata changed: ❌ Creates new hash, needs new registration
  • Single pixel different: ❌ Creates new hash, needs new registration
Short answer: No — for self usage you don’t need SOL. All normal API calls and flows run without you holding SOL.How it works: For API-initiated flows, Trust Engine uses a fee payer wallet we fund to cover on-chain SOL costs — including transaction fees, rent, wallet creation, and submission fees — so you don’t have to. You do not pay anything, and all is sponsered by Trust Engine.

​
Privacy & Security

Trust Engine is designed for privacy by default. We minimize centralized storage and keep only what’s required to verify provenance.What we store (centrally):
  • ✅ Cryptographic hash (e.g., SHA-256) of your file
  • ✅ Metadata you provide (title, description, custom fields)
  • ✅ IPFS CIDs that reference what you registered (digital media and metadata)
  • ✅ Blockchain transaction references and timestamps
What we do not store (centrally):
  • ❌ Raw media bytes of your file (beyond transient processing required to compute the hash and pin to IPFS)
  • ❌ Personally identifiable information unless you explicitly include it in submitted metadata
  • ❌ Any separate copy of embedded file metadata (e.g., EXIF) — we don’t extract or store it
Important clarifications:
  • IPFS storage: If you upload a digital media file, the file is pinned to IPFS under its CID so it can be independently verified. IPFS is a public, decentralized storage layer; anyone with the CID can retrieve the file. We do not maintain a proprietary central copy.
  • Embedded metadata: If your file contains embedded metadata (like EXIF), it remains within the file on IPFS. We don’t extract or store EXIF separately. If that’s sensitive, strip it before uploading or encrypt the digital media file prior to registration.
  • Permanence: On-chain records (hashes, proof status, and timestamps) are permanent and immutable.
  • IPFS availability: IPFS availability is governed by pinning/replication; we pin to keep your digital media piece available, but distribution follows IPFS network behavior.
Server logs are minimal and rotated per policy; they don’t include your raw media.
Short answer: We don’t retain your media. For registration, your file is processed transiently on secure servers to compute its hash and pin it to IPFS, then discarded.During upload:
  • File is transmitted to our secure processing service to compute a cryptographic hash and pin to IPFS
  • We store only the hash, user-supplied metadata, the IPFS CID(s), and related on-chain references
  • The original file bytes are discarded after processing; we do not keep a centralized copy
Privacy tips:
  • Don’t include sensitive PII in public metadata unless you intend to disclose it
  • If your file has embedded EXIF or sensitive metadata, strip it before uploading or encrypt the file and register the encrypted artifact
We never keep a centralized copy of your media. We do briefly process it to compute the hash and pin to IPFS, then discard it.

​
Integration & Development

Trust Engine provides simple REST APIs that work with any programming language:Basic integration steps:
  1. Create user wallets via /create-wallet (one-time per user)
  2. Register media via /register when users upload files
  3. Verify provenance via /search when users view media
  4. Display verification status in your UI
See our Quickstart Guide for complete examples.
Yes. Two ways:Registry UI (Client-side):
  • Select a file; it’s hashed locally in your browser (SHA-256) and searched on-chain by its hash
  • The file never leaves your device in this flow
API (Server-side):
  • POST /search with a file; our backend computes the hash server-side, searches for matches, and discards the file after hashing
What you can search by (Registry UI):
  • File hash (SHA-256)
  • Creator address
  • Filters: status, category, date range, minimum reputation
Privacy note:
  • Registry UI flow: The file is not uploaded to our servers; hashing happens locally
  • API flow: The file is used transiently to compute the hash and is then discarded

​
Developer Questions

Trust Engine requires linking user IDs to wallet addresses for:
  • Searchability: Find content by user ID or wallet address
  • Attribution: Connect registrations to identifiable users
  • Access control: Prevent unauthorized wallet usage
Create the relationship:
# Option 1: Create new wallet (automatically links) - ONE TIME ONLY
curl -X POST /create-wallet -d '{"userID": "user123"}'

# Option 2: Link existing wallet
curl -X POST /link-wallet -d '{"userID": "user123", "walletAddress": "..."}'
Current limits per IP address:
  • General endpoints: 100 requests per 15 minutes
  • File registration: 10 requests per hour
Handling rate limits:
const makeRequestWithBackoff = async (apiCall, maxRetries = 3) => {
  for (let i = 0; i < maxRetries; i++) {
    try {
      return await apiCall();
    } catch (error) {
      if (error.statusCode === 429 && i < maxRetries - 1) {
        const delay = Math.pow(2, i) * 1000; // 1s, 2s, 4s
        await new Promise(resolve => setTimeout(resolve, delay));
        continue;
      }
      throw error;
    }
  }
};
No - each unique content hash can only be registered once.Why: Prevents duplicate registrations and ensures unique provenance recordsWorkaround: If you need multiple registrations:
  1. Modify the file slightly (add metadata, change filename in content)
  2. This creates a different hash, allowing new registration
  3. Or use different metadata in the same registration
Check for existing registration:
curl -X POST /search -d '{"contentHash": "your-hash"}'
File types: All file types supported (PDF, images, videos, documents, code, etc.)Size limits:
  • API uploads: Up to 100MB per file
  • Hash-only registration: No size limit (you calculate hash locally)
Best practices:
  • For large files (>100MB): Calculate hash locally, register hash-only
  • For sensitive files: Always use hash-only registration
  • For public content: Either method works
Hash-only registration (recommended for large/sensitive files):
// Calculate hash locally, don't upload file
const hash = await calculateFileHash(largeFile);
await sdk.registerFile({
  contentHash: hash,
  contentTitle: 'My Large Video',
  walletAddress: wallet,
  walletType: 'managed'
});

​
Still Have Questions?

Developer Community

Join our Discord for real-time help and discussions with other developers

Technical Support

Contact our technical support team for integration assistance

Documentation

Browse our complete API documentation and guides

Feature Requests

Suggest new features or improvements to our roadmap
Can’t find your answer? Our FAQ is continuously updated based on user questions. Reach out to us and we’ll add your question to help other developers.
⌘I