Proving a gallery's history

Every meaningful action in your studio is written to an append-only log: views, downloads, shares, favorites, re-edits, licence purchases, uploads, vault moves, and account security events like password changes and 2FA toggles.

The log is built so it can be checked rather than merely believed. This article explains exactly what it establishes, exactly what it does not, and how to use it if you ever need to.

The chain

Each event stores a SHA-256 hash computed over the previous event's hash plus its own contents. That welds the events into a sequence. Edit one field in one row and that row's hash stops matching, and because every later row was built on the old value, everything after it stops matching too.

Verify on a gallery's Analytics page re-walks every row and recomputes every hash. It is deliberately a button rather than something that runs on load: re-hashing thousands of rows is real work, the answer almost never changes, and a green tick that appears by itself teaches people to stop reading it.

The timestamp

A chain proves the rows are consistent with each other. On its own it cannot prove when they were written, because every input to it belongs to us: the contents, the timestamps, the code.

That matters, because in a real dispute nobody argues about your hashes. They argue that the log is your own database and you could have put anything in it. Chaining what you typed does not answer that.

So the head of the chain, which is one hash covering every event behind it, is sent to an independent RFC 3161 timestamp authority. It returns a token signed with its own key, attesting that this exact hash existed at that instant. This happens nightly, and you can trigger it yourself with Timestamp now the moment you need to pin the record.

One token covers everything appended before it. That is the whole reason the chain is worth building.

The evidence bundle

Download next to "Evidence bundle" gives you a single JSON file containing every field the hashes commit to, in order, plus the timestamp tokens.

Hand that file to whoever is arguing with you. They open encore.photo/verify, drop the file in, and their own browser re-hashes the entire chain and matches the tokens against it. No Encore account, no upload, no request to our servers. If Encore disappeared tomorrow the bundle would still verify.

For the authority's signature itself, the bundle ships the token and the exact openssl command that checks it against that authority's published certificate. We do not perform that check in our own code, because doing it badly would be worse than not doing it, and because a check we run is a check they would have to trust.

What a pass proves

• The events are in the order they were appended, and none has been edited, inserted, removed, or reordered since.
• The events covered by a token already existed, in that order, at the moment the authority issued it.

What it does not prove

• That the events are true. A hash commits to what was written down. It says nothing about whether what was written down was accurate. Any platform telling you otherwise is overselling.
• That the log is complete. It catches changes to the record. It cannot prove an event was written in the first place.
• Anything about rows written before a chain seal. Those are retained and counted separately, never folded into the verified total.

Chain seals

If you see a count of "sealed" rows next to a verify result, those are events from before a change in how events are hashed. They are kept, unchanged and readable, and a rollup hash pins them so they cannot be altered from that point on. They simply no longer claim to prove themselves, because they cannot.

Sealing is the honest option. The alternative would be to re-sign thousands of old rows today and present them as having been signed months ago, which is precisely the act this whole feature exists to make detectable.

Practical advice

• Hit Timestamp now when something happens you might later need to prove. It costs nothing and takes about a second.
• Download the bundle at the same time and keep your own copy. Evidence you hold is worth more than evidence you can request.
• The bundle contains client email addresses and IP addresses, because those sit inside the hashed data and removing them would make it unverifiable. Send it to a lawyer, not to a group thread.