The marketing line is “customers can't dispute what's on the record.” This page is what's actually behind that. It's written for technical evaluators, lawyers, and anyone doing due diligence on the dispute-evidence claim.
When a customer clicks Approve, POOF doesn't just flip a flag in a database. We capture a complete bundle of evidence and lock it together so it can be audited later. The bundle has two layers.
The proof's state at the exact moment of approval, captured as canonical JSON:
The snapshot is the answer to “what did the customer actually agree to print.” Garment color is part of it deliberately: the same artwork on a different colorway is a different thing to sign off on. The snapshot is stored as JSON with a fixed property order so its hash is deterministic.
The snapshot plus everything else that matters about the approval:
The envelope is canonical JSON over which a SHA-256 is computed. That hash is what gets cryptographically timestamped by an independent third party.
Six overlapping layers of protection. The first four are cryptographic and let you detect tampering; the last two are storage guarantees that prevent it. Each closes a different “could POOF have faked this” angle.
The snapshot's SHA-256 hash is stored on the approval row alongside the snapshot itself. Anyone re-verifying can recompute the hash from the stored bytes and compare. A mismatch means the snapshot column was edited after the row landed. This catches the simplest tamper attempt: changing what the customer approved without changing the hash.
The envelope's hash gets submitted to a Trusted Time Stamping Authority (TSA), an independent service whose entire business is signing statements of the form “this hash existed at this time.” The TSA returns a cryptographically signed token. We store that token verbatim, along with the TSA's certificate chain at the time of issue.
The signing key is the TSA's, not ours. This is the key point: nobody at POOF can forge a TSA timestamp because POOF doesn't have the TSA's private key. A tamper attempt that changes the envelope changes its hash, and the original TSA signature no longer verifies.
For European jurisdictions, choosing a TSA that's a Qualified Trust Service Provider on the EU Trusted List makes the timestamp a Qualified Electronic Time Stamp under eIDAS, which carries a legal presumption of accuracy.
Every approval row carries the recomputed envelope hash of the prior approval in the same organization. The org's entire approval history is a linked list of cryptographic references. Rewriting one row's envelope shifts its hash, which breaks the link recorded on the next row, and breaks the TSA signature on every row from that point forward.
The practical effect: “fix one row to look clean” is not viable, because every later row would need a forged TSA signature, which requires the TSA's private key.
The link a customer clicks in their approval email isn't an opaque random identifier. The URL carries an HMAC-SHA256 signature over a compact payload (token id, proof id, issuance time, expiration). A forgery attempt is rejected at signature verification time without ever touching the database.
Combined with the timestamp on the issuance event, this closes the “POOF generated this token after the fact” angle: the URL itself is cryptographic evidence that POOF issued it at the time recorded.
The cryptographic protections above let you detect tampering. The next layer prevents it. The approval ledger lives in append-only ledger tables: a database engine feature that rejects UPDATE and DELETE at the engine level, regardless of who's running them. The schema is enforced when the table is created and cannot be turned off without dropping the table entirely (which itself leaves a system-managed audit trail).
The practical implication is that nobody at POOF, even a database administrator with full credentials, can quietly change an approval row. An attempted UPDATE returns an error before the row is touched. Combined with the cryptographic chain above, you get both layers: tampering is rejected at the engine, and the engine rejecting it leaves an audit trail of its own.
The complete evidence package for each approval is also written to write-once storage, under an immutability policy the application itself has no permission to lift. Retention defaults to seven years from the approval date.
This closes the last angle: what if the database itself were lost or replaced? The archived package is byte-identical to the one a user downloads through the app, and its own SHA-256 is recorded when it is written, so an archived copy can be checked against a live one at any point.
Anyone with access to the proof can download a complete evidence ZIP for any approval, on demand. That covers the owning studio, POOF support acting on their behalf, and the assigned print shop, which can check an approval before committing a job to production. The ZIP is designed for two readers: a non-technical recipient (lawyer, arbitrator, support contact) and a technical expert who wants to re-verify the cryptography.
poof-evidence-{approvalId}.zip
├── summary.pdf Narrative for non-technical readers
├── manifest.json Machine-readable index
├── envelope.json Canonical bytes the TSA signed over
├── snapshot.json Proof state at approval time
├── verification-report.json POOF's own re-verification report
├── timestamps/
│ ├── 01.tsr Raw RFC 3161 timestamp token
│ ├── 01-chain.p7b TSA certificate chain at issue time
│ └── ... Refresh timestamps if any
└── verify.md Step-by-step verification with OpenSSLThe PDF summary is self-contained: a non-technical reader can understand who approved what and when without opening any of the JSON. The technical files give a security expert everything needed to re-verify the cryptography independently.
A lawyer, arbitrator, or security expert with OpenSSL can re-verify the package end-to-end without contacting POOF. The full instructions are bundled as verify.md inside every evidence ZIP. The short version, three commands:
# 1. Verify the snapshot's hash matches what's recorded
openssl dgst -sha256 -binary snapshot.json | xxd -p -c 256
# 2. Verify the envelope's hash matches what the TSA signed
openssl dgst -sha256 -binary envelope.json | xxd -p -c 256
# 3. Verify the RFC 3161 timestamp signature against the captured cert chain
openssl ts -verify \
-in timestamps/01.tsr \
-data envelope.json \
-CAfile timestamps/01-chain.p7bA successful verification on step 3 means: the TSA cryptographically signed a statement that the bytes in envelope.json existed at the recorded time. The TSA's signing certificate is bundled in the chain file, so the verification works offline. Any tamper in any of the bundled files breaks one of these three checks.
Being honest about the limits matters; overclaiming hurts your case more than it helps in a real dispute.
The mechanics above are universal; the legal weight of cryptographic timestamps varies by country and processor. If your situation involves a specific arbitrator, processor, or legal context, contact us and we'll walk through the specifics.
Email support