Trust Model
What you need to trust, what you don't, and why — honestly.
Where Does Trust Come From?
The root of trust in this system is TEE hardware. Not the blockchain. Not the cryptographic algorithm. The hardware.
The TEE signs each verification result with a private key that nobody can extract — not the node operator, not the RootLens developers. This is what makes the signature unforgeable. The cryptographic algorithm (currently Ed25519; designed to migrate to post-quantum algorithms as they mature) is the mechanism of verification, but the reason it works is that the key lives in hardware-enforced isolation.
The TEE signature is what makes the proof trustworthy. The blockchain (Solana) serves a different role: it ensures anyone can discover the proof and verify it has not been tampered with. Each plays a distinct part. In fact, if you had the signed_json in hand, the TEE signature verification itself can be done without consulting the blockchain.
What You Must Trust. What You Don't.
Verification does not require trusting RootLens or any server. But it does require trusting that TEE hardware is functioning as designed — that the TEE manufacturer (e.g., AWS for Nitro Enclaves, Apple for Secure Enclave) has not shipped compromised silicon, and that there are no exploitable vulnerabilities in the TEE. This is hardware trust, not zero trust.
However, the rules that define what counts as valid — which TEE nodes are trusted, which WASM hashes are approved, which cNFT collections are official — are set by the GlobalConfig on-chain record. This record is currently controlled by a single protocol authority key. This means you must trust that the authority has not registered a malicious TEE node or a compromised WASM binary.
This is a genuine limitation, and we state it honestly. The roadmap is to transition GlobalConfig governance to a multisig and eventually a DAO, distributing this trust across multiple independent parties. But today, this is a centralized trust point.
The mitigating factor: all Title Protocol and RootLens code is open source. The WASM binaries running inside the TEE are no exception — anyone can rebuild from source and compare against the on-chain hash. A malicious update would be publicly detectable.
Trust Layers
The system has several components, each with a different trust level. The key insight: most of them do not need to be trusted at all.
| Layer | Trust Level | Why | If Compromised |
|---|---|---|---|
| Device TEE | Hardware trust | The signing key cannot leave the chip | C2PA forgery possible, but Platform Attestation must also be broken |
| Title Protocol TEE | Hardware trust | Verification code and signing key are isolated in hardware | Fake results possible, but WASM code is open source and its hash is on-chain — tampering is publicly detectable |
| GlobalConfig authority | Governance trust (centralized today) | Defines which TEEs, WASM hashes, and collections are valid | Could register a malicious TEE or WASM. Mitigated by open-source auditability. Planned: multisig → DAO |
| Solana Blockchain | Consensus trust | Tampering requires overwhelming economic cost | Would mean all of Solana is compromised, not just RootLens |
| Solana RPC / DAS API | Trusted for on-chain reads | Reads blockchain data; a malicious provider could return fabricated state | A single compromised RPC is a real threat. Mitigation: use a known-good provider, or query multiple independent RPCs |
| signed_json storage | No trust needed | Self-proving — the TEE signature is verifiable by anyone | Tampering detected by signature check. Downtime = unavailable, not forgeable |
| Indexer / page routing | No trust needed | Lookup caches; all results are re-verified on-chain and via perceptual hash | Can only deny service, not forge proofs (see below) |
The Server Question
A natural question: if RootLens has a server, what does it mean that verification doesn't require trusting it? The server does two things:
- Page routing when you open
rootlens.io/p/abc123, the server resolves that short ID to acontent_hash. - Indexer cache maps
content_hashto on-chain cNFT IDs so the browser doesn't have to scan the entire blockchain.
Could the server return the wrong content_hash — pointing the browser to a different piece of content? Yes. Two layers defend against this:
- Perceptual hash recomputation the browser computes a visual fingerprint of the actually displayed image and compares it to the on-chain hash. Substitution with a visually dissimilar image is detected.
- Cryptographic content binding the TEE signature covers the
content_hash, which is a SHA-256 of the original file. This provides the primary integrity guarantee: even a perceptually similar but different file would have a differentcontent_hashand would not match the TEE-signed proof.
The server can cause a denial of service (you can't find the proof), but it cannot cause a false positive — both the cryptographic hash and the visual fingerprint would need to match simultaneously.
TEE Attestation
How do you know the Title Protocol TEE node is actually running inside genuine TEE hardware? Two layers of evidence:
- On-chain collection membership a cNFT can only be minted into the official collection by a TEE node whose public key is registered in GlobalConfig. If the cNFT exists in the collection, the authority verified the TEE's identity at the time of registration.
- Attestation data in off-chain records each
signed_jsonincludes the TEE's attestation information (e.g., an attestation document for AWS Nitro Enclaves). Because the protocol is open source, anyone can independently verify this attestation: rebuild the enclave image from source, derive the expected measurement, and compare it against the attestation document attached to the proof.
The first layer is sufficient for normal verification — if the cNFT is in the official collection, the TEE was trusted at mint time. The second layer provides a deeper, fully independent check that does not require trusting GlobalConfig at all.
Self-Proving Data via TEE Signature
The signed_json stored off-chain is self-proving. It contains the verification result plus a TEE signature (currently Ed25519). The signature is trustworthy not because of the algorithm, but because the private key is locked inside TEE hardware and cannot be extracted. 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.
This means the storage provider does not need to be trusted. Regardless of where the data is stored, the browser can verify its integrity by checking the signature. If the data has been tampered with, the verification fails.
GlobalConfig
GlobalConfig is an on-chain record on Solana that defines protocol-wide settings. The browser reads it directly from the blockchain — never from the RootLens server. It contains:
- Which cNFT collections are official (prevents fake collections)
- Which TEE nodes are trusted (their public keys)
- Which verification code (WASM) hashes are approved (prevents tampered code)
Because this data lives on-chain, the RootLens server cannot inject fake values. The browser reads the source of truth directly. However, whoever holds the GlobalConfig authority key can update these values — this is the governance trust point discussed above.