From generation to certificate in 200 ms: a creator's walkthrough

What happens in 200 milliseconds

You click generate. Two hundred milliseconds later, the image is on your screen and a verifiable certificate is publicly accessible at a URL you can share. In those 200 milliseconds, six things happen. Each one is a cryptographic operation. Each one has a specific failure mode if it does not run correctly. This article is a walkthrough of the proof pipeline as a creator sees it (or rather, does not see it). The compliance happens in the background.

Step 1: identity lookup (skipped on Basic tier)

If you are on Verified or Brand tier, your identity has been bound to your Shield account in advance. We are not re-verifying you per generation. The identity binding is referenced. The binding uses one of three signals depending on tier.

• H1: government ID document, verified by a third-party identity provider (Stripe Identity or Persona)
• H2: phone-number-bound, with a verified SIM at a registered carrier
• H3: biometric liveness check, generally not required unless H1 was inconclusive
• H4: organizational binding for brand tier, where your account is attached to a registered legal entity

The identity claim is in the certificate. Verifiers downstream can see which tier signed the generation. Latency for this step: 2 milliseconds (lookup, not re-verification).

Steps 2 and 3 are the AI model generating the output (1 to 8 seconds, outside Shield's control), then the Adobe TrustMark watermark embedding (180 milliseconds, the slowest single step in the Shield pipeline). The watermark survives resizing, recompression, format conversion, screenshots, and most editing operations that preserve more than 80% of the original pixels.

Step 4: C2PA Content Credentials signing

The C2PA manifest is constructed. It includes the asset hash (cryptographic fingerprint of the file), generation timestamp to the millisecond, AI model identifier (referenced to the EU AI Office registry), creator identity (referenced to the H1-H4 tier), generation parameters (model version, prompt hash, seed), and a cryptographic signature anchored to Shield's key infrastructure.

The manifest is embedded in the asset's metadata. Any C2PA-compliant verifier can read it without our involvement, anywhere in the world, forever.

Latency: 8 milliseconds.

Steps 5 and 6: timestamping and anchoring

• Step 5: an independent timestamping authority (currently DigiCert) signs the moment of generation per RFC 3161. This step survives time. Even if Shield's signing keys are later compromised, the RFC 3161 timestamp from the third-party authority remains valid.
• Step 6: the certificate's hash is written to the Polygon blockchain. The blockchain receipt is a transaction hash that anyone can look up via a public Polygon explorer.
• Polygon is used because it is fast (sub-2-second confirmation), cheap (sub-€0.01 per anchor), and operationally credible since 2020.
• The certificate is not stored on-chain (too expensive); only its hash is. This is sufficient to prove tamper-evidence.

What the certificate proves

A properly issued Shield certificate proves the asset was generated by AI at a specific timestamp, by a specific creator at a specific identity tier, using a specific AI model with disclosed parameters where applicable, and that the asset has not been modified since the certificate was issued. All of the above are independently verifiable by any third party, without our cooperation.

Why 200 milliseconds matters

The latency floor is the difference between "Shield is part of the creator workflow" and "Shield is a checkpoint that slows down the creator workflow". At 200 ms, creators do not notice us. The pipeline runs invisibly. At 2 seconds, every generation feels slower. At 10 seconds, no creator deploys the compliance layer voluntarily. The technical investment in the 200 ms floor is what makes the compliance layer adoptable, not just available. Two hundred milliseconds. Six cryptographic operations. One verifiable certificate per generation. That is the proof layer.