I'm building Live Listing Proof, a small x402-paid service intended to solve a specific reliability gap in agentic commerce:
search/discover product or listing
→ verify the source still supports the relevant facts
→ then recommend / purchase / continue the transaction
The problem I'm trying to address is that an agent can successfully discover a marketplace, classified, auction, or retail URL while the underlying listing is stale, removed, blocked, changed in price, or otherwise no longer supports what the agent is about to tell the user.
Live Listing Proof is currently live on Base mainnet and costs $0.02 USDC per verification.
It accepts a public listing URL plus the claim being checked and returns source-supported listing information where retrievable, or explicit states such as:
- removed
- blocked
- unreachable
- unsupported
- insufficient evidence
rather than inventing a fact when verification fails.
The service already exposes:
- x402 HTTP payment
- MCP discovery/integration
- an A2A Agent Card
- machine-readable input/output schemas
The production endpoint is:
https://live-listing-proof.mattskowronis.workers.dev/v1/verify
The integration pattern I think may be useful in ACK is deliberately small:
discover/search
→ obtain candidate listing URL
→ call verify_listing
→ if supported, continue commerce workflow
→ if removed/blocked/insufficient, do not rely on the stale claim
I am not proposing that ACK adopt Live Listing Proof as a required dependency.
Would an example showing an optional third-party verification/preflight step before an agent relies on an external product/listing be in scope for ACK?
If so, I'm happy to contribute the smallest useful example/documentation rather than asking the project to take on new verification logic.
I'm building Live Listing Proof, a small x402-paid service intended to solve a specific reliability gap in agentic commerce:
search/discover product or listing
→ verify the source still supports the relevant facts
→ then recommend / purchase / continue the transaction
The problem I'm trying to address is that an agent can successfully discover a marketplace, classified, auction, or retail URL while the underlying listing is stale, removed, blocked, changed in price, or otherwise no longer supports what the agent is about to tell the user.
Live Listing Proof is currently live on Base mainnet and costs $0.02 USDC per verification.
It accepts a public listing URL plus the claim being checked and returns source-supported listing information where retrievable, or explicit states such as:
rather than inventing a fact when verification fails.
The service already exposes:
The production endpoint is:
https://live-listing-proof.mattskowronis.workers.dev/v1/verify
The integration pattern I think may be useful in ACK is deliberately small:
discover/search
→ obtain candidate listing URL
→ call verify_listing
→ if supported, continue commerce workflow
→ if removed/blocked/insufficient, do not rely on the stale claim
I am not proposing that ACK adopt Live Listing Proof as a required dependency.
Would an example showing an optional third-party verification/preflight step before an agent relies on an external product/listing be in scope for ACK?
If so, I'm happy to contribute the smallest useful example/documentation rather than asking the project to take on new verification logic.