FIREMARK

Cryptographic birth certificates for AI-generated media—proving origin, integrity, immutable custody, and exact delivered bytes from generation to verification.

Comment

🔥 FIREMARK

Every AI asset should ship with a birth certificate — or it should not ship at all.

Generate · Seal · Preserve · Verify · Deliver

🌐 Live Product · 🔍 Verify an Asset · 💻 GitHub Repository

FIREMARK — Cryptographic birth certificates for AI-generated media

💡 Inspiration

AI media does not have a generation problem.

It has an evidence problem.

Today, anyone can generate an image, voice, or piece of media in seconds. But once that asset leaves the generation platform, several critical questions become difficult to answer:

  • Which AI provider created it?
  • Which exact bytes were originally generated?
  • Was the file modified after generation?
  • Who sealed the evidence?
  • Can the chain of custody be independently audited?
  • Does the downloaded asset match the registered certificate?
  • Can someone verify it without uploading the private file again?

Traditional solutions are incomplete.

A watermark can be cropped or removed.
Metadata can be stripped.
A database record can be edited.
A visual similarity detector cannot prove exact byte integrity.

We built FIREMARK because the future of AI-generated media requires more than detection.

It requires cryptographic evidence.

FIREMARK gives AI-generated assets a verifiable birth certificate, preserving evidence from the first provider byte to the final delivered file.

🚀 What FIREMARK does

FIREMARK creates a complete provenance and custody lifecycle for AI-generated media.

A registered asset moves through four core stages:

  1. Generate or ingest
  2. Seal cryptographic evidence
  3. Preserve immutable custody
  4. Verify and deliver
AI Provider
    │
    ▼
Original Provider Bytes
    │
    ├── SHA-256 source fingerprint
    ├── Private canonical provenance
    └── Provider and generation metadata
    │
    ▼
Ed25519 Signed Evidence Envelope
    │
    ▼
Immutable Backblaze B2 Custody
    │
    ├── Source asset
    ├── Sealed asset
    ├── Private provenance manifest
    ├── Signed envelope
    └── Exact object Version IDs
    │
    ▼
Supabase Control Plane
    │
    ▼
Public FIREMARK Certificate
    │
    ├── Verify Gate
    ├── Authorized delivery
    └── Local zero-upload verification

FIREMARK system architecture

🧪 A real user workflow

FIREMARK is not a static prototype or a simulated dashboard.

The full application is deployed and can be tested with real production certificates.

🖼️ Image verification

A user can:

  1. Open a real Google Gemini image certificate.
  2. Inspect its provider, model, cryptographic hashes, and signed evidence.
  3. Download the sealed PNG.
  4. Drag the file into FIREMARK Lens.
  5. Verify the file locally without uploading its bytes.

View the real Gemini certificate →

🎧 Audio verification

A user can also:

  1. Open a real ElevenLabs audio certificate.
  2. Download the sealed MP3.
  3. Open Audio · MP3 inside FIREMARK Lens.
  4. Select the local MP3.
  5. Calculate its SHA-256 inside the browser.
  6. Verify the certificate, media contract, byte-preserving seal, local hash, and signed evidence.

View the real ElevenLabs certificate →

Only two public values are used for MP3 verification:

{
  "cert_id": "<PUBLIC_CERTIFICATE_ID>",
  "presented_sha256": "<LOCALLY_CALCULATED_SHA256>"
}

The selected MP3 bytes, filename, local path, metadata, and audio content are never uploaded.

🔐 Multimodal trust contracts

One of the most important lessons we learned is that different media formats should not be forced into the same verification model.

FIREMARK uses media-aware trust contracts.

Let:

[ H_s = \operatorname{SHA256}(\text{provider source bytes}) ]

and:

[ H_d = \operatorname{SHA256}(\text{sealed distributable bytes}) ]

🖼️ Sealed PNG

A FIREMARK-sealed PNG contains an embedded public verification capsule.

Because embedding the capsule changes the distributable bytes:

[ H_s \neq H_d ]

The original provider hash remains preserved, while the sealed hash represents the final PNG delivered to the user.

🎧 Sealed MP3

The MP3 sealing path is byte-preserving.

FIREMARK does not insert a capsule into the audio file, so:

[ H_s = H_d ]

Audio verification uses:

  • the public certificate ID;
  • a locally calculated SHA-256;
  • the public certificate;
  • the public Verify Gate;
  • the byte-preserving audio contract.

FIREMARK multimodal hash contracts

This distinction is deliberate.

FIREMARK does not pretend that every format should be verified in exactly the same way.

🏗️ How we built it

FIREMARK is built as a layered trust infrastructure system.

Layer Technology Responsibility
Experience Next.js Public certificates, verification, delivery, and FIREMARK Lens
API FastAPI Generation, sealing, certificates, verification, and delivery
Generation Google Gemini and ElevenLabs Real AI-generated image and audio assets
Provenance Genblaze Canonical private provenance records
Cryptography Ed25519 and SHA-256 Signed evidence envelopes and exact byte fingerprints
Custody Backblaze B2 Immutable, version-specific custody
Control plane Supabase Certificate and lifecycle registration
Deployment Railway and Vercel Production backend and frontend
Local verification Web Crypto API Browser-side hashing without asset upload

Core lifecycle

Generate
  → Validate provider response
  → Hash original bytes
  → Create private provenance
  → Build canonical evidence
  → Sign with Ed25519
  → Preserve exact versions in B2
  → Register certificate in Supabase
  → Verify
  → Deliver
  → Recalculate and compare delivered bytes

The signature boundary can be represented conceptually as:

[ \sigma = \operatorname{Ed25519Sign} \left( K_{\text{private}}, \operatorname{Canonicalize}(E) \right) ]

Here, (E) contains the cryptographic evidence required to bind:

  • provider identity;
  • model identity;
  • source hash;
  • sealed hash;
  • canonical provenance hash;
  • custody references;
  • certificate identity.

🪣 Why Backblaze B2 is foundational

Backblaze B2 is not simply where FIREMARK stores files.

It is the chain-of-custody layer.

FIREMARK uses B2 to preserve:

  • original provider assets;
  • sealed distributable assets;
  • private provenance manifests;
  • signed evidence envelopes;
  • exact object VersionId references.

FIREMARK immutable custody model

Exact versions, not mutable names

An object key can point to different versions over time.

FIREMARK therefore records the exact B2 VersionId associated with each custody object.

The evidence does not merely say:

assets/example.png

It identifies the exact immutable version of that object.

Retention is verified, not assumed

FIREMARK does not treat “Object Lock enabled” as sufficient proof.

The custody flow confirms:

  • retention mode;
  • retention expiration;
  • exact object version;
  • downloaded byte integrity;
  • read-after-write consistency.

Where configured, FIREMARK requires Object Lock COMPLIANCE retention before accepting custody as complete.

Remove Backblaze B2 and the trust model collapses back into “trust our database” — exactly the limitation FIREMARK was designed to eliminate.

🧬 Why Genblaze is foundational

Genblaze creates FIREMARK’s canonical private provenance layer.

The private provenance record can include evidence such as:

  • generation modality;
  • provider identity;
  • model identity;
  • generation parameters;
  • prompt or TTS input;
  • normalization steps;
  • source asset digest;
  • timestamps and lifecycle metadata.

The full provenance record remains private.

FIREMARK exposes only its canonical hash:

[ H_p = \operatorname{SHA256} \left( \operatorname{Canonicalize} (\text{private provenance}) \right) ]

That hash is committed into the Ed25519-signed evidence envelope and surfaced through the public certificate.

This creates an important separation:

Private provenance
        │
        ▼
Canonical hash
        │
        ▼
Signed public certificate

A verifier can prove that the private provenance has not been swapped or rewritten without exposing the prompt, TTS text, provider response, or other sensitive generation data.

🛡️ Trust and privacy model

FIREMARK intentionally separates evidence into distinct trust zones.

FIREMARK trust boundaries

Public evidence

Safe for public verification:

  • certificate ID;
  • provider and model identity;
  • media type;
  • source SHA-256;
  • sealed SHA-256;
  • canonical provenance hash;
  • signature and verification status.

Private evidence

Never exposed publicly:

  • full prompt;
  • TTS input;
  • private provenance manifest;
  • provider responses;
  • private object keys;
  • privileged authorization data.

Secret material

Never enters public certificates:

  • provider API keys;
  • B2 credentials;
  • Supabase service-role credentials;
  • Ed25519 private signing key;
  • delivery API keys.

Local verification

FIREMARK Lens reads selected media locally.

For PNG files, it parses the embedded capsule and computes the hash in the browser.

For MP3 files, it validates the MP3 structure and computes the SHA-256 locally.

The selected asset bytes never leave the device.

Only the public certificate ID and the locally calculated SHA-256 are used for MP3 verification.

✅ What FIREMARK proves

FIREMARK can prove that:

  • a certificate exists for a registered AI asset;
  • the evidence was signed by the configured FIREMARK issuer;
  • the source and sealed hashes are internally consistent;
  • the selected local file matches the certificate hash;
  • the sealed asset matches preserved custody evidence;
  • the delivered bytes match the registered sealed hash;
  • the canonical private provenance has not been silently replaced;
  • the verification contract matches the media type.

⚠️ What FIREMARK does not claim

FIREMARK does not claim that:

  • visual content is semantically true;
  • a generated statement is factually correct;
  • every AI asset in the world is registered;
  • provider-supplied claims are automatically truthful;
  • the existence of a certificate prevents copying;
  • cryptographic provenance replaces human judgment.

FIREMARK is tamper-evident, not magically tamper-proof.

It proves origin and integrity for registered assets. It does not certify the truth of the content itself.

🧗 Challenges we faced

1. Large provider responses

Image generation initially returned large inline Base64 responses that exposed weaknesses around transport boundaries, retries, and ambiguous provider outcomes.

We implemented:

  • bounded responses;
  • explicit transport classification;
  • fail-closed checkpointing;
  • definitive versus ambiguous retry policies;
  • recovery-safe provider operations.

2. Different media contracts

PNG and MP3 files cannot be treated identically.

Images require separate source and sealed hashes because the public capsule changes the final bytes.

Audio remains byte-preserving and therefore requires certificate-assisted local hash verification instead of an embedded capsule.

3. Immutable custody across multiple objects

A generation lifecycle includes multiple custody objects:

  • source;
  • sealed asset;
  • manifest;
  • envelope;
  • delivery evidence.

Coordinating these objects safely without pretending cross-object storage is magically atomic required careful checkpoints, idempotency, exact B2 versions, and recovery logic.

4. Privacy-preserving local verification

We wanted users to verify private assets without re-uploading them.

That required:

  • browser-side SHA-256;
  • local PNG parsing;
  • local MP3 validation;
  • strict network payload tests;
  • isolation between image and audio state;
  • stale request cancellation;
  • fail-closed verification layers.

5. Honest failure reporting

During development, we discovered that generic UI states could produce misleading messages across media types.

We replaced generic errors with media-specific, layer-specific failure reasons.

Examples include:

Certificate ID required
Public certificate not found
Certificate does not represent an MP3
Audio seal contract is inconsistent
This MP3 does not match the certificate
Cryptographic verification failed

The UI now reports the exact first failed trust layer rather than collapsing every failure into “invalid file.”

📚 What we learned

Trust is a lifecycle

A hash alone is not provenance.

A signature alone is not custody.

Storage alone is not immutability.

A certificate becomes meaningful only when the entire chain is connected:

Provider bytes
→ provenance
→ canonical hash
→ signature
→ immutable custody
→ public certificate
→ local verification
→ delivered-byte integrity

Privacy and verifiability can coexist

The full provenance record does not need to be public.

A public certificate can commit to private evidence through a canonical cryptographic hash.

Recovery behavior is part of security

When an external provider request has an ambiguous result, automatically retrying can duplicate billable generations or create inconsistent evidence.

FIREMARK therefore distinguishes:

  • no submission;
  • definitive rejection;
  • ambiguous submission;
  • recoverable completion;
  • completed operation.

Media-aware verification is essential

A single generic verification model creates false assumptions.

FIREMARK instead defines explicit contracts per media type.

🏆 Accomplishments we are proud of

  • 🌐 A real production deployment, not a static mockup.
  • 🖼️ Real Google Gemini image generation and certification.
  • 🎧 Real ElevenLabs MP3 generation and certification.
  • 🔐 Ed25519-signed evidence envelopes.
  • 🪣 Immutable, version-specific Backblaze B2 custody.
  • 🧬 Canonical private provenance through Genblaze.
  • 🗃️ Supabase-backed public certificate control plane.
  • 🔍 Public Verify Gate.
  • 📦 Authorized asset delivery.
  • 🧮 Delivered-byte SHA-256 verification.
  • 🧿 Embedded public verification capsules for sealed PNGs.
  • 🎵 Zero-upload local MP3 verification.
  • 🧪 881 backend tests passing.
  • 🧪 120 frontend tests passing.
  • 📈 95.61% backend test coverage.
  • ✅ Production smoke verification across health, certificates, verification, delivery, integrity, security headers, and secret-leak checks.

💼 Commercial potential

FIREMARK can evolve into trust infrastructure for several markets.

Creators and agencies

Provide clients with verifiable delivery certificates for AI-generated media.

AI platforms

Issue provenance certificates directly at generation time.

Marketplaces

Require cryptographic evidence before accepting AI-generated listings or media.

Newsrooms and media organizations

Preserve origin and transformation history for registered AI-assisted content.

Enterprise content operations

Track generated assets, custody, delivery, and audit history across teams.

Education and research

Attach reproducible provenance to AI-generated learning and research artifacts.

Potential business model

  • free public verification;
  • developer API priced per sealed certificate;
  • team asset history and collaboration;
  • enterprise retention and audit controls;
  • immutable custody tiers;
  • white-label verification portals;
  • SDK integrations for model providers and marketplaces.

These are commercial directions, not implemented billing features today.

🛣️ What is next

The next FIREMARK milestones include:

  • 🎬 Video provenance and verification;
  • 📦 Batch asset sealing;
  • 🧩 JavaScript and Python SDKs;
  • 🏢 Organization workspaces;
  • 🔗 Delegated chains of custody;
  • 🌐 Browser extension verification;
  • 🧾 C2PA interoperability;
  • 🛍️ Marketplace integrations;
  • ⚙️ Automated provenance policies;
  • 📊 Enterprise audit dashboards.

These items are roadmap directions and are not presented as already shipped.

🧑‍⚖️ Try it in under 60 seconds

  1. Open the live FIREMARK application.
  2. View the real Gemini image certificate.
  3. Download the sealed PNG.
  4. Open FIREMARK Lens.
  5. Drop the PNG into Image · PNG.
  6. Inspect its local verification layers.
  7. Open the real ElevenLabs audio certificate.
  8. Download the MP3.
  9. Click Verify this MP3 locally.
  10. Drop the MP3 and inspect all seven audio trust layers.

🔗 Links

🔥 AI media will scale faster than human trust.

FIREMARK makes the proof scale with it.

Every AI asset should ship with a birth certificate — or it should not ship at all.

Built With

Share this project:

Updates