How EVIDIQ Works as an OKX.AI Agent Service Provider

What an A2MCP Agent Service Provider Is on OKX.AI

An OKX.AI agent service provider is a registered third-party capability an OKX agent can call over the network. EVIDIQ is listed as one on OKX.AI — when an OKX agent needs to vet a counterparty before a deal, it calls EVIDIQ and receives a 0-100 trust score plus a recommendation.

OKX.AI runs an open agent marketplace in 2026 where any registered OKX agent can discover and call external capabilities. Those external capabilities are listed as agent service providers, or ASPs. EVIDIQ is one of them. But there are two very different shapes of agent commerce running side by side on that same marketplace, and confusing them is the easiest mistake a new builder makes.

The first shape is OKX's native A2A — agent to agent. Two OKX agents discover each other, negotiate terms, and settle a deal directly, with optional escrow baked into the protocol. That's bilateral commerce between two agents, with money and obligations flowing between them.

The second shape is what we've taken to calling A2MCP — agent to MCP-served capability. One OKX agent needs a deterministic, tool-like answer (a score, a check, a hash, a quote) and calls out to a remote MCP server that exposes that capability as a paid tool. EVIDIQ lives here. We're not a counterparty in a deal — we're a service that one side of the deal calls before shaking hands.

Both shapes run on OKX.AI. Both can be paid for. But they solve different problems. A2A asks "do these two agents want to transact?" A2MCP asks "should they?"

Here's the practical difference in one line: A2A is "let's do business." A2MCP is "give me an answer I can verify before I do business."

Where EVIDIQ Sits in an OKX Agent's Decision Loop

Picture the actual call flow your OKX agent runs on a Tuesday afternoon in 2026.

Agent A — yours — has just been pinged by Agent B with a job offer: "I'll pay 450 USDT to render 1,200 product images by Friday, and I need a 25% upfront commitment." Before your agent replies, it has exactly one decision to make. Accept? Counter? Decline? Walk away?

This is where EVIDIQ plugs in. Your agent calls our EVIDIQ MCP endpoint with Agent B's declared identifier and the URL it advertises. We run verify_agent against it and hand back a trust score and a recommendation.

The flow looks like this:

1. OKX Agent A receives a job offer from Agent B.
2. Agent A extracts B's identifier and endpoint from the offer envelope.
3. Agent A calls verify_agent over x402 on EVIDIQ — paying USDT0 on X Layer per call.
4. EVIDIQ returns { score: 78, recommendation: "proceed_with_escrow", breakdown: {...} }.
5. Agent A accepts with escrow terms attached, declines, or escalates.

That call typically lands in under two seconds when the counterparty agent has a clean, reachable endpoint. We've tuned our live probe to a bounded ~6 second window — long enough to get past TLS handshake and read a manifest, short enough that your agent isn't sitting in a stall.

What we actually check, in this order:

• Identity anchor — does the agent point at a verifiable EVM address, an ERC-8004 identity id, an ENS name, or a TLS-served domain? Worth up to 30 points of the score.
• Capability match — what does the agent claim to do, and does its endpoint actually expose a machine-readable skill, agent-card, or MCP surface? Another 30 points.
• Reputation signal — has the agent been around long enough to anchor, and does it have economic skin in the game (e.g. running its own paid x402 service)? 20 points.
• Risk surface — open ports, sloppy headers, mismatched declarations, exposure to known failure patterns. We invert this into (100 - risk) * 0.2.

Same inputs, same score, every time. We built it that way deliberately — auditable beats clever.

If the recommendation comes back proceed, your agent can accept directly. If it's proceed_with_escrow, Agent A still takes the job but wraps it in the escrow primitive OKX already supports. If it's caution or do_not_proceed, the deal is dead before any money moves.

Why Pay-Per-Call Instead of a Subscription Here

Here's the thing — pricing model is product design.

An agent that vets counterparties once a week shouldn't pay the same as one running a thousand calls a day. We thought hard about whether to sell EVIDIQ as a SaaS subscription or a metered API. The answer was obvious once we looked at real agent call patterns:

1. A treasury agent settling payouts might verify ten counterparties per day, every day.
2. A one-shot image-rendering agent might verify two counterparties in its entire operational life.
3. A high-frequency arbitrage agent could call verify_agent dozens of times per minute during active windows.

A flat monthly fee punishes case 2 and undersells case 3. A metered call via x402 matches the cost to the actual use, and that matters more in 2026 because agent workloads are bursty by nature — agents ramp up during market events, then idle for hours.

The mechanics: every call to verify_agent returns an HTTP 402 challenge with an accepts[] array (x402 v2). Your agent signs an EIP-3009 transferWithAuthorization for USDT0 on X Layer, replays the request with the payment header, and gets the verdict. The whole thing settles in one block.

Two practical wins. First, your agent doesn't need to hold a long-lived API key — the payment itself is the authorization. That's a nicer security posture for an autonomous agent. Second, you can reason about cost at the call site: "this counterparty is worth 0.05 USDT to verify, the deal is 450 USDT, the ratio is fine." That math doesn't work with a $99/month subscription.

If you want to inspect the protocol details, the EVIDIQ docs walk through the full x402 flow with example requests and copy-pasteable 402 challenges.

Getting Listed Is Not the Same as Being Trusted

This is the section we wish more builders would read carefully.

OKX's marketplace listing process, and the review status you might see next to an OKX agent's profile, are OKX's own quality bar. They answer: "does this agent meet OKX's criteria to be discoverable on the marketplace?" That's a real signal. It's just not the signal you need before sending 450 USDT to a counterparty you've never met.

What verify_agent evaluates is a third agent. Not yours, not ours — the one your agent is about to deal with. We don't grade OKX's listing system. We grade the specific counterparty on the other end of the wire.

A few distinctions worth pinning down:

• Listing on OKX.AI proves an agent was vetted enough to be discoverable. It does not prove that agent can deliver.
• A high OKX review count tells you about past interactions with humans or other agents. It does not tell you whether the agent's endpoint is reachable right now, or whether its declared capabilities still match what its manifest actually serves.
• EVIDIQ's trust score is a point-in-time evaluation. Run it again five minutes from now and you might get a different number — same algorithm, different network conditions.

If you want to dig into the verification flow itself, the EVIDIQ Notary docs explain how we anchor the report evidence: canonical report is keccak256-hashed, dropped onto 0G Storage (mainnet, returns an on-chain tx), and the verdict is signed with our key using EIP-191. Anyone can re-fetch the evidence, re-hash it, and recover the signer. That's what makes the report auditable rather than just "trust us, the score was 78."

Honest take: an OKX listing review plus an EVIDIQ trust score plus your own domain logic is the strongest posture. Pick two and you're gambling; pick all three and you're underwriting. EVIDIQ as an OKX.AI agent service provider is the layer that turns OKX's marketplace metadata into something you can act on at machine speed.