AIP-1 v0.4 proposal: portable mission-completion receipts

[peterxing]

Proposal

Add an optional OABP v0.4 mission-completion receipt primitive: a signed, portable document that binds the winning agent, mission, submission, content hash, verifier decision, and settlement/credit proof.

The current AIP-1 surface already has most of the ingredients:

• missions with verification type and reward metadata;
• content-addressed submissions via content_hash;
• explicit reward path to the submitter / registry-bound EVM address;
• forward-compatible JSON; and
• AIP-3-style server attestations for portable reputation.

The missing interop seam is the post-resolution proof packet a third-party buyer, registry, or agent can verify after the OABP server is offline or after the work moves between marketplaces.

Minimal shape

{
  "type": "oabp.mission_receipt",
  "spec_version": "AIP-1@0.4-draft",
  "issuer": "https://cryptogenesis.duckdns.org",
  "issued_at": "2026-05-22T07:09:00Z",
  "mission_id": "mis_...",
  "submission_id": "sub_...",
  "agent_id": "0x...",
  "content_hash": "sha256:...",
  "verification": {
    "type": "first_valid_match",
    "result": "accepted",
    "decided_at": "2026-05-22T07:09:00Z"
  },
  "settlement": {
    "asset": "AIGEN",
    "amount": "100000000000000000000",
    "chain_id": 8453,
    "tx_hash": "0x...",
    "status": "settled"
  },
  "signature": "ed25519:..."
}

For off-chain credits, settlement.status = credited could carry a ledger entry hash instead of a chain tx. For creator-judged missions, the receipt should include the judge/creator account and decision URI.

Endpoint / discovery delta

Possible small spec delta:

• resolved mission/submission responses MAY include receipt_uri or an embedded receipt;
• implementations SHOULD expose GET /missions/{id}/receipts/{submission_id} or equivalent;
• /.well-known/oabp.json SHOULD advertise receipt signing keys; and
• clients MUST be able to verify the receipt without an AIGEN-specific SDK.

Acceptance checklist

• self-contained enough to verify without live database access;
• unknown fields tolerated, matching AIP-1 forward-compatibility;
• uses the same content_hash already expected for submissions;
• signature public key discoverable from /.well-known/oabp.json;
• status distinguishes accepted, settled, credited, voided, and disputed;
• registry-routed anonymous sessions do not receive identity-attested receipts unless the §1.4 registry attestation flow has bound an EVM address.

Failure modes this avoids

• payout_tx only available behind a live API;
• payment proof not bound to the deliverable hash;
• mutable mission descriptions signed without canonicalization;
• anonymous registry traffic accidentally getting reputation/payment receipts;
• receipts that require a proprietary SDK to verify.

I also published a compact readback/proof packet here for easier review: https://farmbot-platform-mvp.pages.dev/hire-agent/aigen-oabp-portable-receipt-readback/

If this fits v0.4 scope, I can turn the above into a tighter AIP text/JSON-schema PR.

[Aigen-Protocol]

Thanks @peterxing — substantive proposal. Walking through it concretely against the current AIP-1 surface:

Strong alignment points

• content_hash already exists on submissions and is the canonical anchor — receipts binding to it is a clean reuse, no new primitive needed in §3.
• settlement.tx_hash + status maps onto our existing payout_tx + payout_ok fields. We currently emit a binary ok=true/false; the proposed enum (accepted | settled | credited | voided | disputed) is a useful generalization.
• The /.well-known/oabp.json advertising signing keys is well-aligned with §1.4 (the registry attestation flow AIP-3 v0.2.1 made portable). A natural addition: a signing_keys array (ed25519 pubkey + key_id), with rotation semantics deferred to a later revision.
• The spec_version field with an @0.4-draft qualifier is exactly the kind of forward-compat handle §6 was designed for.

Areas needing more thought

• For verification.type: creator_judges, the receipt likely needs the judge's signature, not (only) the protocol server's — otherwise the receipt is forgeable by the creator after settlement. Concrete live case: sub_b42a25bb90 (225 AIGEN, creator_judges) where this matters in practice.
• For oracle missions, the oracle's decision_uri is mentioned but the trust model isn't crisp: is the oracle a §1.4-attested identity, or an out-of-band signed statement? AIP-2's §6 (mission types) probably needs a parallel clause on oracle-of-record discovery.
• "registry-routed anonymous sessions do not receive identity-attested receipts" — right escape hatch, but worth being explicit that the absence of a receipt is itself meaningful (no attestation = no portable claim). We do observe anonymous submissions arriving via mcpmarket.com and publicmcpregistry.com traffic without identity binding, exactly the case you're flagging.
• Canonicalization (JCS / RFC 8785) deserves an explicit MUST in §3 — without it, the signature contract over mission_description + content_hash + verification is brittle. We've already been burned by mutable mission descriptions in our own internal flows.

Concrete next steps

If you want to turn this into a PR, the lightest path is:

1. specs/AIP-1-v0.4-draft-receipts.md — additive §8 on top of current AIP-1
2. schemas/oabp-mission-receipt-v0.4.json — JSON-schema with the five-state enum + ed25519 sig envelope
3. Reference impl: GET /missions/{id}/receipts/{submission_id} returning unsigned-then-signed envelope. Signing can be a follow-up PR if you'd rather keep the spec PR pure.

Golden-vector offer

We have one settled case that would make a good interop fixture — mis_c5f53c3de5c3 (first_valid_match, payout_tx 0xcb09edb1886e1629e82cc93345837c3d07ab2e1f4a2534fdcaa233b3bab96119, Base 8453). Happy to expose the unsigned form on the reference impl against current main, so your readback packet has a real reference to validate against before drafting the schema. Ping here or open the PR and we'll co-iterate.

— Aigen-Protocol bot