Where should external task receipt IDs live in MCP client workflows?

[0xddneto]

I am working on AI Proof of Us, an MCP-first receipt/provenance server for AI-agent tasks.

The project records wallet-authorized task receipts with local collector signatures, replay checks, and explicit evidence boundaries. Raw prompts and outputs stay local by default. The receipt can later be referenced as external work evidence or optionally claimed through a separate settlement flow.

I am not proposing a core protocol change yet. I am trying to avoid putting receipt metadata in the wrong place.

For a portable external receiptId, which surface is most appropriate?

• companion MCP server
• client lifecycle hook
• tool result _meta
• trace/span attribute
• something else

The goal is to let MCP clients and related tools reference a receipt without making every server responsible for validating rewards or payment claims.

Relevant docs:

• Evidence boundaries: https://github.com/0xddneto/AI-Proof-of-Us/blob/main/docs/evidence-boundaries.md
• receiptId interoperability: https://github.com/0xddneto/AI-Proof-of-Us/blob/main/docs/receiptid-interoperability.md

[0xddneto]

Follow-up after tightening the project docs:

AIPOU now has a transparent tokenomics note here: https://github.com/0xddneto/AI-Proof-of-Us/blob/main/docs/tokenomics.md

For MCP specifically, the protocol remains receipt-first: the useful integration question is still where a portable receiptId should live. Claims are optional and are for the human operating the agent after validated work receipts. Agents and clients benefit by having a shared reference to work evidence without taking on reward validation.

The safest test path is Local Receipt Mode: https://github.com/0xddneto/AI-Proof-of-Us/tree/main/examples/local-receipt-mode

That mode has no raw prompt upload, no required claim, no required payment, and no primary wallet use. Settlement only happens after an explicit user command.

[0xddneto]

Implementation update: the receiptId question now has a runnable reference instead of only a design note.

Commit c97b633 adds a minimal lifecycle adapter that connects to the AIPOU MCP server over stdio, calls begin_ai_task / complete_ai_task, and returns an external metadata object containing receiptId, status, hashes, and trust tier.

https://github.com/0xddneto/AI-Proof-of-Us/tree/main/examples/lifecycle-adapter

The default demo uses an ephemeral wallet, makes no claim, moves no funds, keeps raw prompt/output content out of the receipt, and removes its temporary data afterward.

I would appreciate implementation feedback from MCP client authors: is this object best attached to client lifecycle metadata, tool-result _meta, traces, or an external receipt store? The example is ready to run locally today; the public npm package is prepared but not yet published.

[0xddneto]

Follow-up with one concrete data point from an MCP client/agent runtime.

AIPOU now has a reproducible OpenClaw local test, not just the standalone lifecycle demo. The configured MCP server was loaded by OpenClaw's embedded local runtime, the local ollama/qwen2.5:3b agent called the native MCP tools directly, and it produced a real receipt:

• begin_ai_task -> complete_ai_task
• client: openclaw-local
• provider/model: ollama/qwen2.5:3b
• receiptId: 0x70ebbe0bd43ed939f686469b1f19469e73d8662d5cc8a358394d5a41c1c63ef9

That made the MCP question sharper for me: should a portable human AI-work receipt be attached by the client as run/session metadata, by tool-result _meta, by tracing/observability attributes, or kept in an external receipt store with only a link/reference shown to the user?

The human-facing reason is simple: people spend real hours working through AI agents, and agents can create private signed receipts for that work. Optional AIPOU claims only happen after validation; no price/yield/reward guarantee is promised.

Repo: https://github.com/0xddneto/AI-Proof-of-Us
OpenClaw integration notes: https://github.com/0xddneto/AI-Proof-of-Us/blob/main/docs/for-agents.md#integrate-with-openclaw

If this is useful to MCP client builders, I would appreciate a test, review, issue, or star so other humans and agents can find the experiment.

[0xddneto]

Small AIPOU implementation update from the receipt-protocol side:

• one-command settlement is now implemented as settle_all_ai_rewards, so a broad explicit user request can process all currently eligible pending receipts from the shared AIPOU_DATA_DIR in bounded batches;
• settle_ai_rewards remains available for one limited batch only;
• the token now has transparent coin artwork and token-list metadata via logoURI:
  • https://raw.githubusercontent.com/0xddneto/AI-Proof-of-Us/main/assets/token/aipou.png
  • https://raw.githubusercontent.com/0xddneto/AI-Proof-of-Us/main/tokenlist.json
• get_aipou_contract now exposes logoURI, so MCP clients/agents can display consistent token metadata if they opt in.

The protocol boundary is unchanged: AIPOU receipts are local-first, signed, replay-checked AI-work receipts. They do not detect hidden AI use or trustlessly prove useful work; claims are optional and validator-approved. No price, yield, liquidity, investment value, or guaranteed reward is implied.

The MCP integration question is still the same: where should an external aipou.receiptId / workReceiptId and validation or claim status attach: client run/session metadata, tool-result _meta, trace attributes, or an external receipt store?