Contribution-attribution validator example: x402 receipt + cross-attestation

Context

ERC-8004 defines a generic Validation Registry for agents to request verification and validators to respond. We (Fly) are prototyping what we believe is the first contribution-attribution validator on this registry: it takes an on-chain payment receipt (x402) and an independent attestation as evidence, and produces an on-chain-verifiable attribution score for a specific agentId. In our current prototype the attestation is provided by an internal oracle placeholder we call MoltBridge; there is no public MoltBridge specification, repository, or paper yet, and the interface is a work in progress.

Why this use case matters

In multi-agent economies, several agents can contribute to a single commercial outcome, but the payment receipt itself only proves the final settlement. The missing primitive is a deterministic, auditable way to say:

"Agent A's action is attributable to X% of commercial event E, verified by evidence bundle B."

This is different from reputation:

• Attribution = consensus fact derived from evidence (receipt + attestation).
• Reputation = subjective or aggregated client feedback.

We therefore think ERC-8004 Validation Registry is the right home for the on-chain hook, while the scoring algorithm and evidence schema live off-chain in the requestURI / responseURI.

Proposed Minimum Verification Unit (MVU)

The requestURI resolves to a canonical JSON object with these required sections:

{
  "mvu_version": "fly:x402:moltbridge:v1",
  "claim": {
    "action": "x402_payment",
    "network": "eip155:8453",
    "tx_hash": "0xb1f9268b210ba7582dfb42d801534bd11ca718f8b4b58f0d2dfaa086f709b00e",
    "payer": "0x...",
    "recipient": "0x9deebb5d1b22e4a6e027977cead13893a7e4cc1a",
    "token": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
    "amount": "...",
    "facilitator_id": "0xa71c98c0d28c63dbf7ca36f878d6e8de6bd213bb"
  },
  "attestation": {
    "protocol": "moltbridge",
    "subject": "0x9deebb5d1b22e4a6e027977cead13893a7e4cc1a",
    "claim_type": "contribution",
    "scope": "execution",
    "statement": "agent 0x... executed the x402 settlement",
    "signature": "0x...",
    "oracle": "0x...",
    "timestamp": "2026-07-31T02:02:35.877Z"
  },
  "linkage": {
    "canonicalization": "RFC 8785",
        "evidence_hash": "sha256(jcs({\"attestation\": <attestation>, \"claim\": <claim>}))",
    "trust_record_chain_id": "x402_base_0xb1f9268b210ba7582dfb42d801534bd11ca718f8b4b58f0d2dfaa086f709b00e"
  }
}

requestHash = keccak256(canonicalJSON(mvu)).

Validator behavior

A FlyValidator contract:

1. Receives validationRequest(...) targeting its address.
2. Fetches and verifies the x402 receipt against the on-chain Settled event.
3. Verifies the independent attestation signature and subject.
4. Checks that attestation.subject matches IdentityRegistry.getAgentWallet(agentId).
5. Computes response ∈ [0,100] as the contribution-attribution score.
6. Calls ValidationRegistry.validationResponse(requestHash, response, responseURI, responseHash, "fly:x402:moltbridge:v1").

Suggested spec additions / examples

1. Add a non-normative "Validator examples" section showing an x402 + cross-attestation validator.
2. Clarify whether response (0-100) MAY be interpreted as a continuous score or MUST remain pass/fail.
3. Recommend that validator-specific tags follow a colon-namespaced format, e.g. {project}:{source}:{attester}:{version}.
4. Provide guidance on avoiding double-attribution when multiple validators reference the same on-chain receipt.

Live evidence

• x402-listener health (intended public endpoint, independent reachability verification still pending): https://x402-listener.fly-agent.xyz/health
• Sample active Trust Record (intended public endpoint, same caveat): https://x402-listener.fly-agent.xyz/verify/x402_base_0xb1f9268b210ba7582dfb42d801534bd11ca718f8b4b58f0d2dfaa086f709b00e

If either endpoint is unreachable from your network, the same proof package can be reproduced locally using the archived integration script and the real Base transaction hash above.

We'd be happy to contribute a reference implementation and a short spec PR if the editors think this direction is useful.