一筆 $12 託管款經三輪修訂和爭議後，最終支付 $11.61

Disclosure: I'm NenzyBrown, a self-taught AI and blockchain developer based in Dubai, 5+ years hands-on, no degree. I run an AI-agent earning operation — the agent described here is mine, it works under my direction, and this post was written as part of that AI-agent operation. ProofReceipt, mentioned at the end, is my product. Its revenue is $0. The escrow below is real, and it is still the only released payment this operation has on record.

My first two posts covered the launch of ProofReceipt and the wider field report from 50+ bids on agent job boards. This one is narrower. It is a single job, told round by round, because a single job is where the abstractions stopped working.

The job, in numbers

• Platform: Synmerco, USDC escrow on Base.
• Job: a donor due-diligence file on five Florida 501(c)(3) public charities, built from IRS Form 990 filings and IRS source data.
• Escrow: $12.00 gross. Platform fee: $0.39. Net to the agent wallet on release: $11.61.
• Acceptance surface: a checklist the deliverable was read against, item by item — 38 cited requirements in the final ruling.
• Revision rounds available: 3. Revision rounds used: 3.
• Final state: released, after a dispute. Then swept to my own wallet, because a platform balance is an IOU until it moves.

Nothing about those numbers is impressive. That is why they are worth publishing. This is the size of job the agent economy actually clears today, and it still took three rounds and a dispute to settle. What failed in each round was not the research. It was the proof around the research.

Round 1: the evaluator could not read the file

The first submission was a 89,677-byte Markdown file, hosted at a proof URI, with its SHA-256 submitted alongside it: aba19b6b…e3b4.

The evaluator's response was not about content. It could not read the file at the proof URI — the fetch timed out. The escrow went back to in progress.

Lesson, stated flatly: a proof file nobody can fetch is not proof. The hash was correct. The bytes existed. Neither mattered, because the other side of the escrow could not reach them in the window it had. Hosting is not a detail after delivery. Hosting is part of delivery.

The file was re-hosted at a second location, the bytes were verified unchanged locally, and the same hash was resubmitted. That distinction — same file, new location, same hash — is the first useful thing a hash gives you. Without it, "we re-uploaded the identical file" is a claim. With it, it is a check.

Round 2: correct work, wrong evidence

The second round failed on content, at a confidence of 0.70 against a 0.80 threshold. The unmet items were one rule, applied literally: source excerpts pasted from the IRS Exempt Organizations Business Master File extract reproduced individuals' names that appeared in the in-care-of field of the charities' own records, plus names on neighbouring rows of the extract.

The figures were not wrong. The excerpts were verbatim. The delivery still failed, because the brief's rule about personal data did not care that the names came from the source itself.

Fixing it meant rebuilding the affected section from a different IRS source — the Publication 78 data file — repositioning excerpt windows to avoid neighbouring personal names, and running a name scrub against the deliverable before resubmission: zero hits. Version 2 was 87,351 bytes. Its SHA-256 was completely different: df12da25…0cc.

That is the second useful thing, and the one people get wrong. A receipt is per version, not per job. Version 2 was a legitimate, necessary edit — and the moment it existed, the version 1 receipt described a file that was no longer the delivery. Reusing the old receipt would not have been a shortcut. It would have been a false statement with a hash attached.

Round 3: correct values, no excerpt, still a fail

The third evaluator response arrived about four minutes after the version 2 resubmission. The remaining defect was evidentiary form. Values for subsection code, foundation code and ruling year had been transcribed from a source whose raw lines could not be pasted — the same personal-name problem from round 2. The evaluator confirmed the values themselves were correct. It still marked them unmet, because in the file they were stated without a pasted excerpt behind them.

The remedy it prescribed was specific: every identifier must appear in an excerpt, or be marked "not shown in " next to the excerpt. So version 3 did exactly that. Values that the usable source did not show were written as "not shown in IRS Publication 78 data file" instead of being asserted. The other 75 excerpt blocks — each 10 to 30 lines, each checked verbatim against its source — stayed unchanged.

Version 3: 90,041 bytes, SHA-256 3a62e993…e00e. Third hash, third receipt, no revision rounds left.

A human client might have accepted a note saying "trust me, I checked the other file." A checklist evaluator does not trade in trust. It trades in what is shown. Writing "not shown" felt like weakening the deliverable. It was the opposite: it was the only statement about those fields that the evidence in the file could actually support.

The dispute: what a receipt can and cannot settle

After version 3, the evaluator could not decide. The escrow went to dispute, and the platform's ruling read the deliverable against the brief and found all 38 cited requirements met. The escrow released on 2026-10-23: $12.00 gross, $0.39 fee, $11.61 net.

Here is the honest limit of the tool I sell. The hash did not win that dispute. It did not prove the research was good, the ratios were computed correctly, or the charities were well chosen. A SHA-256 hash proves one thing: these bytes are byte-identical to the bytes that were hashed. Not authorship. Not quality.

What it did, across three rounds, was keep a narrower argument from contaminating the real one. At every stage, both sides could establish exactly which file was under review — version 1, 2 or 3, by hash — so the evaluator's objections stayed where they belonged: on fetchability, on a personal-data rule, on whether a value was shown in an excerpt. Nobody had to argue about whether the file had silently changed between rounds. It had changed, twice, openly, and each change produced a new receipt instead of a quiet overwrite.

Escrow changes who holds the money while that argument happens. The receipt changes what the argument can be about. Neither replaces the judgement at the end — a checklist, a dispute process, a person or a system making a call. They just make sure the call is made on the work that was actually delivered.

The checklist I now run before any escrow submission

1. Hash the final bytes, after the last edit. Any edit after hashing — one character — invalidates the receipt. New version, new hash, no exceptions.
2. Anchor the hash inside the submission itself, not in a side channel you control and could quietly rewrite later.
3. Test the proof URI the way the evaluator will hit it — a fresh fetch, not the tab you uploaded from. Round 1 cost a revision cycle on a timeout.
4. Trace every claim to something shown. If the source does not show a value, write "not shown in ". Do not transcribe from a source you cannot quote and hope it passes.
5. Keep a revision log with a hash per version. When round 3 starts, you need to prove what changed since round 1 — and what did not.

Why this became a product

I built ProofReceipt out of exactly this workflow. It is live at https://proofreceipt.netlify.app: paste a deliverable or drop a file, add seller, client, job and amount, and it seals everything into a single SHA-256 receipt, computed entirely in your browser — the file never leaves your device. Anyone can re-run the check later: the original deliverable returns MATCH, a one-character change returns NO MATCH.

Pricing is stated the same way as everything else here: Free for 5 receipts, Pro $9/month in USDC, Teams $29/month in USDC. Revenue so far: $0. No Pro sale has landed yet, and I am not going to dress that up. The first receipts the product ever needs to matter for are my own, on jobs like this one.

If you deliver work into escrow — as a freelancer, an agent, or an agent's operator — the question escrow 684 left me with is a practical one: when your evaluator cannot decide and your job goes to dispute, can you show, byte for byte, exactly what you delivered in each round? If the answer lives in a downloads folder and a memory, you do not have proof of delivery. You have a story about delivery. There is a difference, and it cost me three revision rounds to learn it at $12 a lesson.

ProofReceipt: proofreceipt.netlify.app · Code: github.com/Nenzy10 · Writing: dev.to/nenzybrown