With the EverStamp app you make captures with the date, time and place in the image. Every capture is signed on your phone and goes into a file; when you close the file, an independent service adds a qualified timestamp to it. This page explains that chain and says exactly where it stops.
The bar is the part anyone can read, on screen or on paper. The rest travels with the image and the file, and only a check can see it. Change a single pixel and that check fails.
You capture with the app’s camera, and each capture goes straight into a file. That file shows the chain as a row of four dots, in the app’s own words. While it is open, it is still collecting captures. Once it is sealed, all four are green.
Each link does one thing, and each link says what it does not do.
The moment the camera hands the capture back, the image is hashed and signed with a key from the secure hardware in your phone. With a video, that happens piece by piece while you record. According to Apple’s or Google’s attestation, that key was created in the secure hardware of a real device for our app, and cannot leave it. The same step carries the device clock, the location if you have it on, and a counter that only goes up.
What this link does not do: establish what the capture shows. A photo of a screen is still a photo. What the app does carry with a photo is a signal that says something about it: the movement of the phone in the second around the capture.
Every capture points at the one before it, and together they form a tree. The tree also holds the number of captures, so a clipped tail shows up. When the file closes, the root of that tree, one hash that sums up every capture, goes to a qualified timestamping service on the European trust list. It stamps with its own audited clock.
What this link does not do: accept a time you supply. The protocol has no field for asking for a time. That is why the stamp on a file made today can never carry yesterday’s date.
A 108-byte fingerprint of every file goes into a public log, which is itself timestamped in turn. That is how you can tell afterwards that EverStamp registered a file, rather than it being invented somewhere else with a real timestamp wrapped around it.
What is not in it: your captures, or anything that identifies you or your customer. The log holds numbers. Captures reach us in three cases: a share link, where the key stays in the link; a delivery answering a company’s request; and every file, if your organisation switched on storage at EverStamp. In the last two we hold the key for that company as well; technically we can therefore open them too, and we do that only at that company’s written request, or when a court or authority orders or demands it under the law.
They get a PDF and an archive. Dragging either onto the page is enough; the sums run in the browser and the file does not come to us. Only if the file carries a registry receipt that the page cannot check itself, as with a file from before version 1.1, does the question whether our registry knows the entry go to us; a newer file usually carries the registry’s signature itself, once the registry receipt is in it. Anyone who would rather check it themselves can use ordinary OpenSSL and the open tooling for Content Credentials.
What this link does not do: pass judgement on your case. The page says what was recorded and when, and where that stops. What it is worth is for the recipient to weigh.
A file travels as an archive, a report or a link. Whichever one arrives, it leads to the same check.
Naming them is the point. A claim you cannot look up is a claim you have to take on faith, and every one of these has a public specification anyone can read.
| What | Which standard | What it does here |
|---|---|---|
| Provenance in the image | C2PA, Content Credentials | The photo carries C2PA provenance data: which app and which device, signed by EverStamp. Who took it and the device time remain stated values. It is the vocabulary in which data provenance is normally discussed. |
| The timestamp | RFC 3161, from a qualified service on the EU Trusted List | The service signs a hash with its own audited clock. The protocol has no field in which a client can ask for a time: the time of the stamp is set by the service, not by the phone and not by us. |
| The series | SHA-256 and a Merkle tree | Every capture is hashed, each points at the one before it, and the tree has one root: one hash that sums up every capture. The count sits inside the tree, so a clipped tail shows up. One stamp on the root therefore covers every capture underneath it. |
| The device | App Attest on iOS, hardware key attestation on Android | The signing key lives in secure hardware and cannot be exported. Apple or Google attests that the key was created there, for our app. That attestation does not establish whether the device was jailbroken or rooted: a hacked phone can sometimes pass it. |
| The lower edge | drand, a public randomness beacon | A value nobody can know in advance, fetched at the last sync and carried into the file. A capture cannot have been signed before the value it contains existed; with our app on a device that is not jailbroken or rooted, the capture was then also made after that moment. |
| Who may stamp | eIDAS, Regulation (EU) 910/2014, Article 41 | A qualified service is supervised and listed. The time it indicates, and the integrity of the data bound to it, are presumed accurate. That is a European rule; outside the European Union it depends on the law of the country. |
Two things are deliberately absent from this list. There is no blockchain: a public log that is itself timestamped by the same qualified service is cheaper, faster and checkable with tools everyone already has. And there is no proprietary format of ours holding the whole thing up, because a format only we can read would put us back at the centre, which is the thing we are trying to avoid. The green verdict still needs our registry; that is set out under the checks below.
Many timestamp cameras put a time on your photo that comes from your phone’s clock, and you can change that clock yourself. What we record is a window with two hard edges around it, and how narrow that window is sits in your file as a number.
The app, the report and the verification page also say for every file what is and is not established, so nobody feels caught out later.
The verification page shows the checks that apply to the file in front of it: a PDF report gets fewer than the archive from the app, and a light file or one without a checklist fewer again. What we add is that you can redo the sums yourself: your browser does every check but one with public standards. The verdict needs the last one, and that confirmation comes from us: a file from version 1.1 of the app carries the registry’s signature, which your browser checks against our published key; for an older file the page asks our registry whether it knows the file.
The confirmation from the registry is the only check that tells a file EverStamp registered apart from something invented elsewhere with a real timestamp wrapped around it; without it the verdict is never green. A file from version 1.1 of the app usually carries the registry’s signature once the app has put the registry receipt in it; that can only happen after the registry has timestamped the file’s hour. The page checks that signature itself, and then asks us nothing. A file without a registry receipt does not turn green. If the file carries a registry receipt that the page cannot check itself, as with an older file, the page asks our registry one thing: do you know this entry? If the registry cannot be reached then, the page says so, and that check stays open instead of quietly passing. We keep the IP address, the browser and the time, for thirty days, and not which file it is.
They apply to every piece of material ever put in front of anyone, from a paper receipt to a witness statement. We put them here because a recipient will think of them anyway.
Recording the crack and not the leaking roof. A checklist makes that visible: it says which steps are still open.
Keeping quiet about a file that does not suit you. Leaving something out of a file does show: the number of captures is in the stamp, and a struck capture stays visible with its reason.
And picking the most convenient one afterwards. Each was genuinely made at its own moment, so none of them is false; each does carry its own date.
A qualified timestamping service is supervised and listed on the European trust list. Under eIDAS Article 41 the date and time of the stamp, and the integrity of the stamped data, are presumed accurate, not the moment of capture or what the capture shows; Article 13 puts liability for the stamp on that service. Note what the presumption covers and what it does not: it is about the time and the integrity, not about the other questions in your dispute. That is a European rule; outside the European Union it depends on the law of the country.
Then you have nothing, and we cannot help you. On the ordinary route your captures never reach us, so there is nothing for us to send back. Our 108 bytes in the log only confirm that a file existed, not what was in it. That is the flip side of captures staying on your own device, and it is exactly why Plus has a backup to your own cloud. The exceptions are a file you delivered in answer to a company’s request, and any file made while your organisation had storage at EverStamp switched on. Those sit with us, and that company can open them.
No. The app only records with its own camera, so every capture in a file sits in the signed series. The photo library is used only to pick your company logo in Settings.
You can, while the file is open, and the image goes. What stays is the fact that something was struck through, with the reason alongside. A file that quietly loses something is worth less than one that shows its own corrections, and technically, removing it would break all the other checks anyway.
No. We use a public log that is itself timestamped by the same qualified service. That is cheaper, faster and checkable with tools everyone already has.
Yes. For the customer and the recipient it is the same file, the same page and the same report. On Android the key attestation comes from the secure hardware in the device, with Google as the issuer, and the app keeps the counter itself.