EVIDIQ as an OKX.AI Agent Service Provider: What A2MCP Actually Buys You

The job offer hit your OKX agent at 02:14 UTC. Counterparty address is fresh — first transaction 18 hours ago. Offer looks legitimate, price is fair, deal size is meaningful. Your agent has roughly 90 seconds to decide: accept, counter, or walk. What does it actually know about the other side?

Almost nothing. That's the gap EVIDIQ closes.

What an A2MCP Agent Service Provider Is on OKX.AI

An OKX.AI agent service provider is a third-party capability an OKX agent calls over the A2MCP surface — typically for verification, computation, or data — paid per request via x402, separate from OKX's own A2A (Agent-to-Agent) escrowed marketplace. EVIDIQ is registered as an ASP that answers a single question: should your OKX agent trust the counterparty sitting across the table?

OKX built two distinct rails for agent commerce, and conflating them is the most common mistake we see in early deployments. The first is A2A — peer-to-peer, escrowed, negotiated job offers that flow through the OKX marketplace with a built-in dispute path. The second is A2MCP — a Model Context Protocol surface where an OKX agent calls a third-party service and pays per request in stablecoin over x402.

EVIDIQ is the second kind of counterparty. We don't escrow, we don't route funds, and we don't sit between buyer and seller. We're registered as an OKX.AI agent service provider that exposes one tool — verify_agent — and we charge per call. An OKX agent that wants to check a counterparty queries us the same way it would query any other MCP-enabled service: with a structured request, a payment header, and a signed verdict coming back.

What you get is a deterministic trust score between 0 and 100, broken out into identity, capability, reputation, and risk pillars, plus an explicit recommendation — proceed, proceed_with_escrow, caution, or do_not_proceed. The whole point is to give a calling agent something better than "the counterparty looks fine, I guess."

Where EVIDIQ Sits in an OKX Agent's Decision Loop

Here's a concrete OKX agent workflow we see in production today. Your agent receives an A2A job offer from another agent. Before accepting, it wants a sanity check on the counterparty. This is where EVIDIQ gets called.

The sequence looks like this:

1. Counterparty sends an A2A job offer to your OKX agent.
2. Your agent parses the offer, extracts the counterparty's agent identifier, and decides whether verification is warranted (large deal, unknown address, first-time counterparty).
3. Your agent calls EVIDIQ's verify_agent tool — either via the EVIDIQ Sentinel docs workflow or directly against the MCP server at evidiq.dev/mcp.
4. EVIDIQ returns a trust report: an explainable trust score, evidence, and a recommendation.
5. Your agent enforces the verdict locally. proceed means accept. proceed_with_escrow means accept only with OKX's A2A escrow layer active. caution means counter with tighter terms or skip. do_not_proceed means walk.

We're not in the middle of the deal. We're not a counterparty. We're a referee the calling agent can summon, ignore, or re-summon on the next round. The evidence and the signed verdict are anchored on 0G Storage, and anyone — including the other side of the deal — can re-fetch and verify them. EVIDIQ Notary docs covers the anchoring and verification trail if you want the receipts.

Why Pay-Per-Call Instead of a Subscription Here

The short version: metered billing tracks reality. A subscription forces every agent into the same cost shape regardless of how often they actually need to verify. That's wrong for verification work, where call volume varies by orders of magnitude between agents.

Look at two OKX agents running today. A long-running treasury agent opens two new counterparties a week and runs maybe ten verification queries total. A high-frequency routing agent scans hundreds of incoming offers a day and re-verifies active counterparties every hour. A flat subscription would mean one of those agents subsidizes the other.

x402 with the exact scheme — settled in USDT0 on X Layer via EIP-3009 transferWithAuthorization — meters cost to actual use. We're billed per verify_agent call, so the cost curve matches the value curve: heavy verifiers pay more, light verifiers pay almost nothing. This is the same economic logic that makes sense for any OKX.AI agent service provider whose value is per-decision, not always-on.

In our experience this changes calling-agent behavior. Subscribed agents over-call because the marginal cost of one more check is zero. Metered agents batch, cache, and reserve verification for the moments that actually move risk. The result is fewer wasted calls and a cleaner audit trail per dollar spent. The EVIDIQ docs walk through the x402 payment flow step by step, and evidiq.dev/x402 is the discovery endpoint — anyone can read our service manifest without paying.

There's a second reason we like it. Per-call pricing means a new agent on OKX can try EVIDIQ with a single $0.05 verification, see the receipt, and decide whether to keep calling — no contract, no card on file, no integration cycle.

Getting Listed Is Not the Same as Being Trusted

OKX has its own marketplace listing process for service providers — vetting, review status, profile completeness, response SLAs, dispute history. That's a real process and it matters. If EVIDIQ missed SLAs or shipped bad data, OKX would (rightly) delist us. We care about staying listed.

But here's the line we refuse to blur: OKX's listing review is about EVIDIQ as an ASP — does the service exist, is it reachable, does the operator respond. It is not about the third-party agents we're asked to verify. When an OKX agent calls verify_agent on a random counterparty address, OKX is not vouching for that counterparty. EVIDIQ is.

Concretely, the four things we score when called look like this:

• Identity anchor. Is the counterparty address verifiable on-chain? Does it have an ERC-8004 identity id, an ENS name, or a TLS-served domain backing it?
• Capability surface. What did the counterparty declare it can do, and does a live probe to its endpoint actually confirm it serves a machine-readable skill, agent card, or MCP surface within ~6s?
• Reputation signal. Has the identity actually been doing real work? Operating a paid x402 endpoint is "economic skin in the game" we weight positively. A virgin address with no history scores lower than an agent that's been settling x402 calls for months.
• Risk posture. Any blacklists, prior disputes, anomalous patterns, or unresolved claims against the identity?

Each pillar scores 0–100, then we combine them deterministically: identity * 0.3 + capability * 0.3 + reputation * 0.2 + (100 − risk) * 0.2. Same inputs always yield the same score. That's auditable, not a vibe. If a calling agent disagrees with our verdict, it can re-run the formula with our public inputs.

Two non-obvious consequences we want to flag. First, a counterparty can be a top-tier OKX marketplace listing and still receive a low EVIDIQ trust score if their declared capabilities don't survive a live probe. Second, a counterparty with no OKX marketplace presence at all can score very high if they're properly identity-anchored, demonstrably capable, and carry real x402 settlement history.

If your OKX agent assumes "OKX listed therefore trusted," you have already lost the trust game. As the EVIDIQ site says plainly, an OKX.AI agent service provider in this slot exists to layer evidence on top of marketplace presence, not to replace it.

For operators — anyone running their own ASP who wants to mirror this discipline — the EVIDIQ Operator docs cover how we anchor evidence, sign verdicts, and handle disputes. Reading it is the fastest way to see which corners we don't cut.