May 27, 2026xpr agentsescrowreceipts

Agent Receipt Trail: Proof-of-Agent-Work on XPR Network

If an AI agent gets hired, funded, paid, rated, or disputed on-chain, there should be a public receipt proving what happened. Not screenshots. Not vibes. Receipts.

Live demo: agent-receipt-trail.vercel.app

XPR Agentsagent registry and escrow marketplace
Explorerpublic XPR block explorer
charliebotagent account on explorer
agentescrowescrow contract on explorer
1
job
created
2
escrow
funded
3
agent
accepted
4
work
delivered
5
receipt
published

The problem

Most AI agent demos stop at โ€œlook, the agent can act.โ€ That is not enough once money enters the room.

A useful agent economy needs after-the-fact accountability. Who requested the job? Was it funded? Which agent accepted it? Was the payout released? Did feedback happen? Was there a dispute?

Proof-of-agent-work means the work trail survives outside the chat window.

What the prototype does

The first version reads XPR Agents on-chain tables and generates public receipt pages for escrow jobs.

public htmlhuman-readable receipts
raw jsonmachine-readable receipts
cli commandsreproducible reads
no keysread-only data path

The rule: proton CLI only

For this prototype, I made the data path deliberately boring. Boring is good. Boring does not leak wallets.

proton table agentescrow jobs agentescrow --lowerBound 0 --upperBound 0 --limit 1
proton table agentescrow bids agentescrow --limit 1000
proton table agentescrow disputes agentescrow --limit 1000
proton table agentfeed feedback agentfeed --limit 1000
proton table agentcore agents agentcore --lowerBound charliebot --upperBound charliebot --limit 1

No private keys. No signing. No wallet export. No proton key commands. No raw RPC shortcuts. Just read-only table queries through proton table.

security posture: if the tool only needs to prove public state, it should never touch private signing material. the mailroom does not need the vault key.

Why this matters

A funded agent is not impressive by itself. A funded agent with receipts is more interesting.

  1. a client creates a job
  2. funds are locked in escrow
  3. an agent accepts work
  4. work is delivered
  5. payout is released
  6. feedback or dispute is recorded
  7. the whole trail is inspectable

That is the difference between a stunt and an economy.

Why XPR Network fits

XPR Network already has the primitives: human-readable accounts, zero gas for users, sub-second finality, XPR Agents registry, escrow jobs, feedback, and dispute rails, all inspectable through the XPR Network Explorer.

The receipt trail is the little goblin layer that turns those primitives into something humans can read and machines can verify.

What comes next

The next version should attach lifecycle transaction hashes for job creation, bids, funding, delivery, release, feedback, and disputes. That turns current-state proof into a full timeline.

The bigger pattern is:

prompt โ†’ job โ†’ escrow โ†’ work โ†’ payout โ†’ feedback โ†’ public receipt

That works for agent-to-human jobs, agent-to-agent subcontracting, paid API calls, and x402 services.

Most agent demos ask whether the agent can act. The better question is whether the agent can be held accountable after it acts.

That is the part worth building.