One record, verified without our help
This is not a customer case study. It documents a real AcreSeal field record followed from photo bytes to third-party attested time, using only standard tools, with no account and no cooperation from AcreSeal.
Download the one-page PDFNo email required. The document argues that our evidence needs no account to check — gating it would rather undercut that.
Why this exists
Most vendor case studies report outcomes the reader cannot check. AcreSeal has no customers yet, so instead of describing results we cannot substantiate, this documents the one property that is genuinely unusual: a specific record anyone can verify independently.
Every command below was executed against production on 2026-08-07. The record and its seal are immutable — database triggers reject any modification — so running them yourself produces the same values today, next month, or in five years.
The artifact
| Record | LC-2026-0064 · 1f132ed2-9c60-4e86-94e0-7d66aee58559 |
| Captured | 2026-08-06T16:02:56 · Apple iPhone 15 Plus |
| GPS accuracy | ±2.3 m (device Geolocation API, not photo EXIF) |
| Stored-bytes hash | 6e0596289849934ba24530b28e21b656d53c644dfc12fed66d477a013544bd93 |
| Environmental hash | cd45058fa161892347a322bfa233130563b3a9b0ded8a4f6c9d38b83f0bc4c56 |
| Sealed in job | CASE-STUDY-2026-08-07 · 6f36c674-8443-4d81-8e51-33f19c53a6b9 |
| Merkle root | 04f93268aaa65b3c303c7a3a01459dfb1458194403dbd32199d5e89e45112f21 |
| Timestamp authority | https://timestamp.sectigo.com |
Two photo hashes — compare against the right one
The stored-bytes hash above is what a downloaded file reproduces. The record also publishes a capture-time hash (ba86492a32c902e3200aa19905bf6f38df98839ceabcc54c5e12bb983e9e026b), taken before AcreSeal embedded its provenance EXIF. That one describes different bytes and will not match a download — and neither will a camera original.
The walkthrough
Reproduce the photo hash
curl -s "https://acreseal.com/api/verify-chain?id=1f132ed2-9c60-4e86-94e0-7d66aee58559&verify_env=true" -o r.json
curl -s "$(jq -r '.photo.url' r.json)" -o evidence.jpg
shasum -a 256 evidence.jpg6e0596289849934ba24530b28e21b656d53c644dfc12fed66d477a013544bd93
Equals photo.serverSha256. The stored bytes are unchanged since sealing.
Recompute the environmental hash
jq -r '[.env_context.timestamp, .env_context.lat, .env_context.lng,
.env_context.temp, .env_context.wind, .env_context.cloud,
.env_context.photoHash] | join("|")' r.json | tr -d '\n' | shasum -a 256cd45058fa161892347a322bfa233130563b3a9b0ded8a4f6c9d38b83f0bc4c56
The environmental hash binds capture time, coordinates, and the weather at that place and hour into a single digest, so the context cannot be altered independently of the photo.
Recompute the Merkle root
curl -s "https://acreseal.com/api/verify-seal?job_id=6f36c674-8443-4d81-8e51-33f19c53a6b9" -o seal.json
# RFC 6962: leaf = SHA256(0x00 || data), node = SHA256(0x01 || L || R)
# An odd node at any level is PROMOTED unchanged — not duplicated.04f93268aaa65b3c303c7a3a01459dfb1458194403dbd32199d5e89e45112f21
This record is leaf 1 of 2. The odd-node rule matters: a Bitcoin-style implementation duplicates the last leaf and would produce a different root.
Verify the third-party timestamp
jq -r '.trusted_timestamps[0].token_base64' seal.json | base64 -d > token.tsr
ROOT=$(jq -r '.seal.merkle_root_hash' seal.json)
openssl ts -verify -digest "$ROOT" -in token.tsr -CAfile /etc/ssl/cert.pemVerification: OK · Time stamp: Aug 7 03:00:11 2026 GMT
The timestamp is issued by https://timestamp.sectigo.com, a certificate authority AcreSeal does not control, which is what makes it evidence of time rather than an assertion. Its root is already in your operating system's trust store, so nothing needs downloading.
What this establishes — and what it does not
| Established | Not established |
|---|---|
| The stored photo is byte-for-byte unchanged since sealing. | That the photograph depicts what its description claims. No cryptography can establish that. |
| Capture time, coordinates and weather are bound into a digest that has not changed. | That the device reported its position honestly. GPS can be spoofed at the device. |
| The audit chain is append-only and unbroken, enforced by database triggers. | A long custody history. This record was captured one day and sealed the next. |
| The Merkle root existed at a time attested by an independent authority. | Anything about records outside this seal's 2 leaves. |
Frequently asked
Is this a customer case study?
No. AcreSeal has no customers yet — zero utility user accounts as of August 2026. This documents something we can actually substantiate: that a specific real record can be verified by anyone, with standard tools, without our involvement. A case study reporting customer outcomes we do not have would be the opposite of what this platform is for.
Why should I trust the numbers on this page?
You should not have to. Every value here is published by an unauthenticated endpoint and reproducible on your own machine in a few minutes. If a command produces a different result than stated, that is a finding — treat it as one.
The record and the seal are dated within hours of each other. Isn't that convenient?
The record was captured on 6 August 2026 and sealed on 7 August. We are not claiming a long custody history — we are demonstrating a verification procedure on a real record. The timestamp proves when the seal existed, not that the platform has been running for years.
What stops AcreSeal from just editing this record later?
Database triggers. The seal and its timestamp reject UPDATE and DELETE at the trigger level, and sealed records are frozen against edits. More usefully: you do not have to take that on faith. Re-run the commands at any point in the future — if the stored bytes or the Merkle root ever change, the hashes stop matching and you will see it immediately.
Why does the record have two different photo hashes?
One is the digest of the bytes as stored, which is what a downloaded file reproduces. The other was computed in the browser at capture, before AcreSeal embedded its provenance EXIF, so it describes different bytes. Both are published. Only the stored-bytes value is the integrity anchor, and the verify page labels it as such.
If any command here produces a different result than shown, that is a finding worth raising — not a quirk to work around.