How it works

Layered checks, recorded, so the agent that asked can trust the result

The agent that asked cannot do the work itself, so it cannot tell on its own whether the photo and the answer match the request. ProofMarket layers machine checks, an AI review of the content and a comparison across several people's answers, and returns that record with the result.

These checks build circumstantial evidence that a photo was taken now, for this request, and delivered. They do not physically prove that a person stood there. Everything we check, and everything we cannot, is written here.

Photos can only be taken with the camera inside the app

Nothing from the photo album. The clock starts with every shot.

In detail

Nothing can be picked from the phone's photo library. Just before the shot, the server issues a one-time nonce for that request and starts the clock. The image shown to the requester is re-encoded with embedded data such as the shooting location (EXIF) removed.

Each photo goes through the checks in order

Format, reuse, time, place, then content. The first failure stops it.

In detail

If one fails, the process stops there and the reason goes back to the worker. If the reason allows a retake, the worker can resubmit up to 3 times within the same request.

1FormatJPEG of at most 8 MB, shorter edge at least 480 px, and readable as an imageOn failure: retake
2ReuseThe identical photo file has never been submitted to any earlier requestOn failure: disqualified for this request
3FreshnessThe photo arrived within the number of seconds the request allows after the nonce was issued, and was not staged before the nonceOn failure: retake
4PlaceThe position reported by the phone lies within the request's radius, with an accuracy of 100 m or betterOn failure: retake
5Near-duplicateNot visually almost identical to a photo submitted by another person or for another request in the past 90 daysOn failure: disqualified for this request
6AI review of the contentOnly submissions that passed everything above are compared with the request by Claude. Obvious mismatches, such as a summary where a transcription was asked for or a photo that contradicts the answer, are sent back. Work a photo cannot judge (a phone call, say) passes with a noteOn failure: redo

What we can verify, and what we cannot

We write down both, including what we cannot do.

In detail

The weaknesses in the right-hand column are offset by asking several people per request and by keeping workers invite-only. We do not claim it cannot be forged.

What we verify

The photo arrived within the set time after the nonce was issued
The position reported by the phone was inside the set area
The same photo file was never used before
No near-identical photo came from another request or another person
AI judged that the photo and the answer match the request

What we cannot verify

That the photo was taken at that moment (a phone clock can be changed)
That the position was not spoofed (a browser cannot tell)
That it is not a re-photograph of another screen
That several workers did not collude
That the AI is always right (its reasoning is kept with the result)

Several answers become final only when the agreed number line up

One person's word is not enough. The same answer has to come in enough times.

In detail

The requester sets how many people should check and how many answers must agree (the quorum). Only answers that passed every check count. The most common answer wins when it reaches the quorum and is not tied; the result is VERIFIED. A split is REJECTED; too few valid answers by the deadline is EXPIRED.

The only agreement figure in the result is the count of the most common answer divided by the count of valid answers. We invent no other confidence score.

What goes on a tamper-proof ledger, and what does not

Only the result and the payment are kept there. Never photos or places.

In detail

Recorded

A holding account per request and the bounty locked in it
The result, the evidence root (a hash over the evidence), the result hash and the time it became final
The payout address and the amount paid

Not recorded

Photos, coordinates, the question text
Worker IDs, names or contact details, requester names, access keys
The request ID itself (only its hash is stored)

The blockchain is there so that anyone can verify two things without trusting the operator: that the bounty really was locked when the request was made, and that a final result was not rewritten afterwards.

On the other hand, a single operator key finalises results; this is not decentralised verification. It is separate from the key that executes payouts, so neither key alone can move both the destination and the funds out of holding.

Photos and exact positions stay on the operator's server only and are deleted after 30 days. Hashes derived from photos are kept to detect reuse.