Title Protocol

An open protocol that extracts verifiable facts from content — without showing the content to anyone.

What Title Protocol Is

Title Protocol is a general-purpose protocol for extracting objective, verifiable attributes from C2PA-signed content. It processes content inside a TEE, seals the extracted results with a TEE signature, and links them to cNFTs on Solana.

The key property is that nobody sees the raw content. The entire pipeline — from ingestion to result output — runs end-to-end encrypted. The TEE receives encrypted content, decrypts it internally, extracts the requested attributes, signs the results, and returns them encrypted. Only the extracted facts (e.g., "this certificate chain is valid," "the perceptual hash is X") are shared — never the content itself.

The TEE ensures the node operator never sees the raw content — only the extracted, signed facts leave the enclave. The trust comes from TEE hardware isolation: the signing key cannot be extracted, and the verification code (WASM) is pinned by an on-chain hash, so its correctness is publicly auditable.

Content-Origin Agnostic

The protocol does not care who signed the content. A Google Pixel photo and a RootLens photo enter the same pipeline. The difference is which cert-* processor verifies the certificate chain — the core extraction and signing logic is identical.

RootLens as an Application

RootLens is the first application built on Title Protocol. It uses the protocol to extract provenance information, certificate verification results, and perceptual hashes from camera content — then publishes the results as a shareable link. But Title Protocol itself is not limited to camera content or to RootLens.

End-to-End Encrypted Channel

No one — not the network, not the node operator, not RootLens — can see the raw content. Before sending content to a TEE node, the app establishes an end-to-end encrypted channel:

App
1. Look up TEE public key
from on-chain GlobalConfig
App
2. Key exchange
Ephemeral ECDH → shared secret (forward secrecy)
App
3. Derive directional keys
Separate keys for App→TEE and TEE→App
4. Encrypted content →
TEE
5. Process inside TEE
Decrypt, verify C2PA, run processors, sign results
← 6. Encrypted results
App
7. Decrypt locally

The result is that the content travels encrypted at every stage. The TEE node operator, the network, and RootLens never see the raw content. Only the extracted facts leave the TEE — sealed with the TEE's signature.

Processor Selection

Every C2PA manifest contains a signer_org field — the name of the organization whose certificate signed the content (e.g., "Google" for a Pixel photo, "RootLens" for an app-signed photo). The app reads this field and tells the TEE which processors to run:

signer_orgprocessor_ids
“Google”core-c2pa, cert-google, image-pdq
“Sony”core-c2pa, cert-sony, image-pdq
“Leica”core-c2pa, cert-leica, image-pdq
“RootLens”core-c2pa, cert-rootlens, image-pdq
(any, video)image-pdq → video-vpdq
Important
Each cert-* processor verifies the C2PA certificate chain against the corresponding manufacturer's Root CA public key, not RootLens's CA. When a Google Pixel photo is verified, the TEE checks the certificate chain against Google's Root CA — hardcoded inside a WASM binary whose hash is registered on-chain.

What the TEE Produces

For each processor, the TEE produces a signed_json — a JSON object containing the verification result, signed with the TEE's private key (currently Ed25519; the protocol is designed to migrate to post-quantum algorithms as they mature):

{ "protocol": "Title-v1", "tee_pubkey": "<public key, Base64>", "tee_signature": "<signature, Base64>", "tee_signature_algorithm": "Ed25519", // current algorithm "payload": { "content_hash": "<SHA-256 of original content>", // processor-specific fields... }, "attributes": { ... } }

The signature covers JCS({ payload, attributes }) with a domain tag title-protocol-v1. JCS (JSON Canonicalization Scheme) ensures that the JSON is serialized in exactly one way — otherwise, logically identical data could produce different bytes and break the signature. The signature is trustworthy because the private key is locked inside TEE hardware (it cannot be extracted), and the TEE will only sign data produced by the approved verification code (whose hash is pinned on-chain). Both the key isolation and the code integrity are necessary for the guarantee.

WASM Trust

The verification logic (including Root CA public keys) is compiled into WASM binaries that run inside the TEE. The SHA-256 hash of each WASM binary is registered in the on-chain GlobalConfig under trusted_wasm_modules.

When a browser verifies a cNFT, it checks that the wasm_hash in the payload matches a hash registered on-chain. This ensures the TEE ran a known, unmodified verification binary — not one with a backdoor or weakened Root CA.

cNFT Minting

After verification, the TEE mints cNFTs on Solana. Each content item produces:

  • 1 Core cNFT (core-c2pa): the C2PA provenance graph
  • 1 Cert Extension cNFT (cert-*): certificate chain verification result
  • 1 Perceptual Hash Extension cNFT (image-pdq or video-vpdq): visual fingerprint

All cNFTs are minted into the official collections defined in GlobalConfig. The json_uri of each cNFT points to the off-chain signed_json.

See the cNFT Structure page for the detailed payload format of each cNFT type.

← PreviousHow Content Is SignedNext →cNFT Structure