Setting Up a Dispute Evidence Folder: Screenshots, Message Logs and Timestamps That Arbiters Accept

Most dispute packets I have reviewed fail for the same three reasons. The screenshot is cropped. The chat log has no timestamps. There is no transaction hash.

Market staff (and anyone reconstructing the case later) treat a partial capture as concealment. A frame that hides the URL bar, the order ID, or the clock is the digital equivalent of a document with the letterhead torn off. This is a research-only walkthrough of how to assemble a dispute evidence folder that survives arbiter scrutiny and, more importantly, survives your own later audit. It is not access advice and it does not describe how to reach any market.

If you are documenting a case for academic or journalistic work, treat every file as if it will be exhibited. Assume copies outlive the venue that asked for them.

What actually gets thrown out

Arbiters are inconsistent. Some will accept a blurry phone photo of a tracking page. Others will bounce a clean capture because the system clock is off by four minutes. You cannot control that. You can control whether the packet is internally consistent.

The failure modes that keep showing up are boring, and they keep working:

• Cropped or edited screenshots. If the shop identity, order number, amount, or timestamp is missing, the capture is hiding something. Real proof is a full confirmation in one frame, not a tight crop of the part that helps you.
• Reused or template images. The same shipment photo appearing across listings is a known pattern. Reverse image search exists. Run it on anything a counterparty sends you, and assume they will run it on you.
• Payment claims without a transaction hash. A cryptocurrency transfer without a public hash is unverifiable. A real Bitcoin transaction has a hash anyone can check on an explorer. No hash means no proof.
• Single-source chat dumps from brand-new accounts. If the only corroboration is a week-old username, treat it as one person talking to themselves. Cross-check against independent, older identities when they exist. Often they do not.

Those checks are the same ones used to flag fake vendor “proof” in fraud circles. They transfer cleanly to escrow fights. Staff who ignore them are not being kind. They are being lazy, or aligned with volume.

A folder that does not collapse under review

Keep originals immutable. Working copies live in a separate tree. Hash everything on intake, before you open the files in an editor.

A layout that has held up in reconstructions:

• 00_case.txt: one page. Order ID, dates in UTC, claimed amounts, the decision you want, and a file index.
• 01_order/: full-page captures of the order state at each change (created, paid, shipped, disputed).
• 02_messages/: native exports first, screenshots second.
• 03_chain/: transaction hashes, explorer printouts, and the raw txid in a plain text file.
• 04_shipping/: tracking captures and any photos, inspected for metadata before they leave the machine.
• 05_hashes.txt: SHA-256 of every file, generated once, never edited.

Put UTC in the filename. Something like 2026-03-14T184422Z_order_shipped.png. Do not trust filesystem mtime. Copies, zips, and forum uploads rewrite those. The filename is the only clock you fully control.

I hash with a local SHA-256 tool and paste the list into 05_hashes.txt the same hour I take the captures. If you hash a week later, you are hashing a story you already had time to tidy. That is not how chain of custody works.

Screenshots: the full frame or nothing

Partial screenshots are red flags. That is not a style preference. Full confirmation means identity, amount, date, and order number visible together.

Capture the entire window. URL bar, tab title, system clock, and the order body. If the UI truncates the order number, scroll and take a second frame that overlaps the first on a visible landmark (a unique product string, a total, a status badge). Overlap is how you show the two frames are the same page, not two unrelated crops glued together.

Do not annotate the original. Duplicate it. Draw boxes on the copy. Anyone who knows what they are doing will ask for the unmarked file. If you only have the marked one, you already lost that argument.

Watch for the quiet ways a capture lies:

• Browser zoom that clips the header
• Dark theme extensions that hide contrast on timestamps
• Overlay clocks from screenshot tools that disagree with the page clock
• Blurs that also cover the order ID you needed

If you must redact a shipping address or a handle that is not in dispute, redact on the copy and keep a sealed original. State in 00_case.txt exactly what was covered and why. Vague “privacy redaction” over the only timestamp on the page is how packets get treated as fabricated.

Phone photos of a monitor add extra EXIF, extra compression, and extra doubt. Use the OS screenshot shortcut. If a phone is all you have, disable location for the camera first. Then still prefer a desktop capture the next time the page is available.

Message logs: native export beats a gallery of bubbles

Screenshots of chat are the weakest form of a log. They lose sequence. They lose identifiers. They are trivial to fabricate one bubble at a time.

Prefer a native export (JSON, HTML, or mbox, depending on the client). If the venue only offers an in-browser ticket thread, capture the full thread in one scrolling session and save the page HTML in addition to images. HTML plus images is harder to dismiss than images alone. Still not as good as an export. Take what the system will actually give you.

Metadata around messages is often more decisive than the text. Common fields that show up in logs and in server-side records include who sent and who received (with unique identifiers), the time the message was sent, the client or user-agent, and, on email-like paths, the handling server. Even on end-to-end encrypted channels, routing metadata still reaches the servers that move the traffic.

Pattern evidence is cheap to reconstruct. Who messaged whom, and how often, is enough to sketch a habit. A gap in a previously regular ticket thread is itself a fact. Record the quiet stretch. Do not fill missing hours with a restated summary of what you “would have said.”

If you used PGP, keep the signed ciphertext, not just the decrypted plaintext. A signature over a timestamped body is stronger than a screenshot of that body. Unsigned plaintext in a text file is a claim. Claims are what the other side has too.

Do not edit logs to clean them up. Work on tainted digital evidence is blunt about the next part. A process can refuse tainted items so nobody relies on them. It does not erase the history that the item was altered. Once a timestamp has been painted over, the whole folder is suspect, including the files you did not touch.

Timestamps that line up

Pick UTC and stay there. Markets, blockchains, and mail headers already lean that way. Local time with an unspecified offset is how two honest logs look like a contradiction.

For every capture you want three clocks visible or recorded:

• The shop or ticket page clock, if it shows one
• Your OS clock in the screenshot chrome
• The blockchain time for the funding transaction

They will not match to the second. Block time is not wall time. Pages cache. NTP drift happens. What you need is a story that does not require a four hour jump. If your OS clock is wrong, fix it before you start documenting, not after. A corrected clock in the middle of a packet looks like tampering even when it is not.

Do not start the log at the first angry message. Include the quiet period before the dispute. Staff notice when a packet begins at the convenient moment. So do researchers reading a dump two years later.

Photos, EXIF, and the porch problem

Timestamps live in more places than the filename. Exchangeable image file format (EXIF) data on photos routinely stores date and time, device identifiers, camera settings, pixel dimensions, resolution, file size, and GPS. iOS, by default, embeds exact timestamps and GPS coordinates in pictures taken with the device camera.

That is a problem if your “evidence” is a photo of a parcel on a doorstep. You just geotagged a house into a folder that will be read by strangers with an incentive to dox someone. Device IDs and camera settings are less dramatic and still identifying when two images are compared.

It is difficult to strip most of that metadata without dedicated tools. Inspect every image with a metadata viewer before it enters 04_shipping/. ExifTool is the usual choice. If GPS is present, that file does not travel. Retake the shot with location off, or strip and re-hash. Do not upload first and “clean it later.” The first copy is the one that gets mirrored.

Screenshots from a desktop browser usually carry less location data than camera photos. They can still carry timestamps of last edit, software tags, and dimensions that do not match the claimed window. Check those too. People forget the working copy they opened in an editor.

The hash is the independent witness

Escrow arguments collapse into a single question. Did the money move. Screenshots of a wallet GUI are not an answer. The transaction hash is.

Write the txid in 03_chain/txid.txt. Save an explorer capture that shows inputs, outputs, amount, and confirmation time. If the venue uses an in-site wallet or a multisig address, capture that address from the order page in the same hour as the broadcast. Late screenshots of an address, and address reuse, are how people get accused of recycling an old payment.

No hash, no proof. That rule is older than any current shopfront. It still filters most of the noise. A researcher caveat: explorer sites log clients. Isolate that lookup the same way you isolate anything else. The hash is public. Your interest in it does not need to be.

What I submit, and what I hold back

Submit the minimum set that proves the timeline. Order created, funds seen on chain, status changes, the disputed messages, the current state. Staff with a queue will not read a 200 file dump. A fat archive is not seriousness. It is a way to bury the one frame that hurts you.

Hold back the sealed originals and the full hash list. If someone claims a PNG was edited, you produce the original and the hash computed on day one. If you only have the edited copy, you have nothing. That is the whole point of the two-tree layout.

Do not include live mirrors or anything that amounts to access instructions. Do not include unredacted personal data that is not in dispute. Do not include staff-dox speculation. Do not include anything you obtained by using someone else’s login. Tainted collection taints the packet. An arbiter who wants a reason to rule against you will take it. So will anyone who inherits the dump after a seizure.

Assume the folder outlives the market

Law enforcement mirrors and dead-site archives show the same sloppy evidence culture from the other direction. Venues advertise fair escrow, then staff vanish, or they rule on volume because the vendor has it. Buyers submit memes. Vendors submit last month’s stock shipping photo. Your folder will not fix a crooked staff account. It will make a crooked ruling obvious after the fact, which is the only leverage later readers have.

It will also keep you from handing a GPS-tagged porch photo to a ticket system that will be copied for years.

If the process requires you to upload the entire folder to the venue’s own servers, assume those copies persist after the venue dies. Keep a local archive that does not depend on their uptime. Hash it. Date it. Do not store it next to anything that deanonymizes you. Full frames, native logs, public hashes, UTC, and files you have not touched. Decoration is how packets get thrown out.