Reality Registry
Patent pending — Application 64/049,784
How Reality Registry actually works.
Authenticity isn't a single trick. We embed five overlapping layers of cryptographic proof into media at the moment of capture, and bracket each capture between public timestamps that we don't control. Verification is free and needs no account: checking the time window never needs us, while matching a re-compressed copy runs our watermark extractor.
This page is the architecture, in public. The provisional patent has been filed; what's secret is the operational tuning, not the design.
Architecture
Five overlapping layers, none of which can be defeated alone.
A single watermark is a single point of failure. We use five independent authentication layers, each defending against different attacks, each verifiable on its own. Defeating Reality Registry means defeating all five at once — and the cost of doing so exceeds the value of any synthetic claim.
Visual watermark
An imperceptible identifier is embedded directly into the pixels using research-grade neural watermarking: 256 bits in every frame of a video (Meta's Video Seal), and 61 bits in a photo (Adobe's TrustMark). Lives inside the image, not in the metadata — survives compression, re-encoding and most editing.
Audio watermark
Each three-second segment of the audio track carries a hidden segment-index marker (Meta's AudioSeal). If a clip is trimmed or spliced, the segment indices reveal the cut — even if the visual watermark is intact.
Per-segment hash chain
A photo is hashed once, as a single leaf. For video, every three-second segment is independently hashed (SHA-256) and the resulting hashes are combined into a Merkle tree. The Merkle root is what gets registered on the public blockchain. A single altered pixel anywhere in the clip invalidates the segment that contains it — without affecting verification of the rest.
Two independent time anchors
Each capture incorporates fresh values from public sources whose numbers did not exist beforehand: the NIST Randomness Beacon, a government-published random value that updates every 60 seconds, and prev_randao from the latest Ethereum block. A capture cannot have happened before a value it contains was published, and neither source is under our control or under the other's. Photos are bound by both, because the app fetches them at the shutter. Video is bound by NIST, because its beacons are fetched when the file reaches our servers and Ethereum's 12-second block is by then usually newer than the capture.
Public blockchain registration
The Merkle root, the beacon values, and capture metadata are written together to a public blockchain (Polygon) within seconds of capture. The blockchain timestamp proves the capture cannot have happened after that block. We don't control the blockchain. Together with Layer 4, the capture is bracketed between two independent timestamps neither owned by us nor by the creator — discussed in detail below.
The time window
Bracketed by clocks we don't control.
Every capture is pinned between public timestamps published by parties outside this company. No earlier than a public beacon whose value did not exist before it was published. No later than the Polygon block that records the capture. The window between them is verifiable by anyone with internet access, without trusting Reality Registry or anyone else.
Photos get two independent lower bounds; video gets one. The photo app fetches both the NIST Randomness Beacon and the latest Ethereum block on the phone, at the shutter, so both were published before the capture and both bound it. Video is watermarked on our servers, so its beacons are fetched when the file arrives — and because Ethereum produces a block every 12 seconds, that block is usually newer than the capture and therefore cannot bound it. Our verification pages detect that and simply don't show it, which is why a video record shows NIST as its only lower bound. We would rather explain this than round it up.
One honest caveat about scope. That window is independently checkable whenever you hold the original file, because you can compute its hash yourself and compare it to the public record. Matching a recompressed copy — one that WhatsApp, iMessage, or a social platform has re-encoded — takes one extra step that currently runs on our servers: extracting the invisible watermark to find which record the file belongs to. The record it resolves to is public and anyone can inspect it, but that lookup step is ours, and we'd rather say so than let "trustless" do more work than it has earned.
A public randomness beacon
The U.S. National Institute of Standards and Technology publishes a fresh, signed random value every 60 seconds at beacon.nist.gov — unpredictable in advance, archived publicly, signed by NIST's HSM. Embedding the most recent value in a capture guarantees the capture is no older than that value's publication time. Photos additionally embed prev_randao from the latest Ethereum block, fetched on the phone at the shutter, giving them a second, unrelated floor.
Public blockchain block timestamp
The Merkle root of the capture's segment hashes is written to a public blockchain (Polygon today; multiple chains supported as the network matures). Once a block is confirmed, the timestamp is immutable and globally observable. The capture must have existed at or before that block — its hash is on the chain.
Why this matters: most authenticity systems require trusting someone — the platform, a certificate authority, a forensic firm. Reality Registry's time window requires trusting only a public randomness beacon and the global state of a public blockchain — no certificate authority and no forensic opinion. One dependency remains, and we'd rather name it than let it hide: re-checking a capture's window means recomputing its proof from the registration record, and that record is held by us. If this company disappeared, every fingerprint on the chain would stay valid, but recomputing one would need a copy of that record.
The capture pipeline
From record to registered, in seconds.
The user taps the shutter — or finishes recording — and the authentication chain runs immediately, with nothing further for the user to do. Photos are watermarked on the device. Video is uploaded and watermarked on our servers, because the video watermarking model is far too heavy to run at 30fps on a phone. Either way registration needs a network connection. For photos the capture is registered before the file leaves the device for ordinary sharing; for video the file is uploaded to us first, then watermarked and registered.
-
STEP 1
Capture
Photo or video is captured through the application's camera flow. The most recent public beacon values are fetched and incorporated — on the phone for photos, on our servers for video.
-
STEP 2
Embed and hash
The visual and audio watermarks are embedded; each three-second segment is hashed; the hashes form a Merkle tree.
-
STEP 3
Sign on device
The upload is signed with a key created in the phone's secure hardware where the phone has it (StrongBox or the Trusted Execution Environment on Android; Secure Enclave on iOS once the iPhone app ships). A limit, stated plainly: our server checks that signature, but it can't yet independently confirm the key really lives in secure hardware — today the phone reports that itself.
-
STEP 4
Register
The signed Merkle root, the beacon values, and capture metadata are written to the public blockchain.
-
STEP 5
Confirm
A blockchain block confirms within ~30 seconds. The upper bound of the time window is now public and immutable.
-
STEP 6
Distribute
The watermarked file is now ready to share, store, or submit. Authentication travels with the pixels — no separate proof file required.
Verification
Free, open, and accessible to anyone.
A trust system that gates verification behind payment is not a trust system. Anyone — recipient, journalist, court, regulator — can verify a Reality Registry-authenticated photo or video at no cost, with no account, and no Reality Registry product installed. Three independent paths exist.
Share-link verification
Every registered capture comes with a short share link. Click it; see the full authenticity record on a public web page. No login.
Upload verification
Have a copy of a photo or video and want to know if it's registered? Upload it. Our extractor reads the watermark, looks up the chain entry, and reports back. Free.
Independent verification
The blockchain record is public. Anyone with a Polygon block explorer can confirm the Merkle root, the beacon values, and the timestamp without our involvement.
Open architecture, calibrated specifics
What this page tells you, and what it doesn't.
We believe trust systems benefit from public scrutiny of their architecture. The provisional patent (Application 64/049,784) covers the novel combination described above; we have no incentive to obscure it. What we don't publish are the operational specifics, such as the empirically tuned watermark parameters, because those are tuning constants in an active arms race with adversaries. Disclosing them buys an attacker hours of saved work and the world nothing.
Full implementation detail is available under NDA. We intend to commission independent third-party validation of the watermark survival suite; when it is booked this page will say by whom and when, rather than carrying a date nothing stands behind.
Straight answers
Here's what this doesn't do.
Anyone promising you certainty is selling something. These are the real edges of what Reality Registry can prove, in plain language.
It can't prove a camera saw the world
No phone on the market can cryptographically prove that light actually hit its sensor. We seal what the camera hands us, at the moment it hands it over. That's a real limit, and it applies to everyone in this field.
Nobody can alter the record — but two steps still run through us
The fingerprint on Polygon is public and permanent, and no one can change it, including us. Two steps do depend on Reality Registry today: re-checking a capture's time window means recomputing its proof from the registration record we hold, and pulling the watermark out of a copy that's been squeezed through a social app runs our extractor. Both need this company to be around.
It shows you captured it, not that you own it
Sealing a photo is evidence of authorship — you had this file, at this time. It isn't a copyright determination, and it isn't legal advice about who holds rights to what.
See it run on real captures.
The architecture is the easy part. The interesting question is whether it survives your specific workflow — journalism, witness documentation, evidence chain-of-custody, or a custom integration. Install the Android app and try it, or ask for a hands-on technical briefing.