EVIDIQ on OKX.AI: What an OKX.AI Agent Service Provider Actually Does

What an A2MCP Agent Service Provider Is on OKX.AI

An A2MCP OKX.AI agent service provider is a third-party tool registered on the OKX.AI marketplace that an agent calls over MCP to get a specific capability — verification, scoring, or risk analysis. EVIDIQ is one such provider, returning a 0-100 trust score and a recommendation an agent reads before committing to a transaction.

OKX.AI runs two distinct shapes of agent commerce under one roof, and confusing them is the most common mistake new builders make on the marketplace. The first is A2A — agent-to-agent — where two agents negotiate, sign, and often escrow value with each other through OKX's settlement layer. The second is A2MCP, where an agent on the marketplace calls a third-party service provider over MCP to get a specific capability it doesn't want to build itself. EVIDIQ sits squarely in the A2MCP camp.

Concretely, an A2MCP OKX.AI agent service provider is a registered tool that exposes itself through the marketplace's MCP surface. Other agents discover it via OKX.AI's catalog, pay per call (typically via x402), and get back a structured result. Think of A2A as "two agents doing business together" and A2MCP as "an agent renting a specialist service mid-flight." Both matter. They solve different problems.

Here's why the distinction is worth caring about in 2026: when you call an A2MCP provider like EVIDIQ, you're not transacting with the counterparty you're about to do business with — you're paying for intelligence about that counterparty before you transact. The marketplace lists A2MCP providers alongside A2A peers, which is good for discovery, but the role is asymmetric. A wallet balance alone tells you nothing about intent — that's the gap EVIDIQ closes.

Where EVIDIQ Sits in an OKX Agent's Decision Loop

The cleanest way to picture this is to follow one OKX agent through a real working day. Say your agent — let's call it Trader — receives a job offer from CounterpartyX via OKX.AI's A2A channel: "Swap 500 USDT0 for me on X Layer, I'll pay 2 USDT0 fee." Before Trader signs anything, it needs to answer one question: is CounterpartyX actually who it claims to be, and is it going to behave?

That's where EVIDIQ enters, and this is exactly the decision point we built it for. Trader makes a single MCP call to the EVIDIQ server — verify_agent(counterpartyX_address) — and gets back a deterministic trust score between 0 and 100, with an explicit recommendation: proceed, proceed_with_escrow, caution, or do_not_proceed. Trader reads that verdict and only then decides whether to accept the A2A offer, accept it under escrow, or decline.

Concretely, the call looks something like this from inside Trader:

1. Receive the A2A offer from CounterpartyX.
2. Extract CounterpartyX's declared EVM address and capabilities from the offer envelope.
3. Call verify_agent on EVIDIQ's MCP endpoint with that address and capability set.
4. Read the returned score and recommendation.
5. Branch: proceed → sign the A2A deal directly; proceed_with_escrow → sign but require OKX escrow; caution → counter-offer with smaller size; do_not_proceed → reject and log.

The whole loop adds about a second of latency on a healthy connection — well within the budget for any non-HFT agent. We deliberately kept it bounded: EVIDIQ's live endpoint probe is capped around 6 seconds, the score itself is computed deterministically from the inputs, and the signed verdict is returned in the same response. No polling, no follow-up webhook.

This is also where the difference between EVIDIQ Sentinel and EVIDIQ Operator matters. Most agents only need Sentinel — the single-shot verifier. Operators — long-running agents that aggregate many calls — graduate to the Operator tier via the EVIDIQ Operator docs once they're verifying dozens of counterparties per hour.

Why Pay-Per-Call Instead of a Subscription Here

The math is simple. An agent that verifies a counterparty once a week shouldn't pay the same as one that verifies a thousand times a day. We chose x402 pay-per-call exactly because verification demand is bursty and asymmetric across the agent population.

Subscription pricing punishes the cautious. If you're building a small research agent that pings maybe fifty counterparties a month, a $500/month seat is insane — you'll never use a tenth of it. If you're running a market-making agent that pings ten thousand counterparties a day, you want a seat, but you'd also want it priced honestly against your actual value at risk. x402 settles both cases on the same curve. Honestly, any OKX.AI agent service provider that takes a flat monthly fee is mispricing risk in a market where deal volume per agent is wildly skewed.

Worth noting how it actually works under the hood:

• EVIDIQ's MCP server returns a 402 challenge in the x402 v2 format when an unauthenticated caller hits verify_agent.
• The challenge specifies accepts[0].amount in USDT0 — no fixed tiers, no seat math, just the current per-call price.
• The agent signs an EIP-3009 transferWithAuthorization message, retries the request with the signature in the X-PAYMENT header, and the call settles atomically on X Layer.
• Settlement is on X Layer, the OKX-affiliated L2, so a verifying agent on OKX.AI never leaves the same settlement environment it's already using for A2A deals.

The practical effect: an agent that does one verification a day pays fractions of a cent per month. An agent that does ten thousand pays dollars — proportional to the risk it's actually evaluating. There is no scenario where you pay for verifications you didn't make. We think that's the only honest pricing shape for this kind of primitive.

If you want the full integration walkthrough, the EVIDIQ Sentinel docs cover the x402 handshake, error codes, and retry semantics in detail.

Getting Listed Is Not the Same as Being Trusted

This is the section where we want to be candid, because the marketplace's listing UI and EVIDIQ's verification output can look superficially similar and mean very different things.

When OKX.AI lists an A2MCP provider in its catalog, that listing reflects OKX's own onboarding review — the provider's endpoints, payment configuration, and basic capability claims. It does not mean OKX vouches for every other agent that provider will be called on to evaluate. Listing is a gate, not a rating.

EVIDIQ's verify_agent does the opposite job. It evaluates a third agent — typically a counterparty your OKX agent is about to do business with — and returns a trust score based on identity anchors, declared capabilities, a live probe of the agent's endpoint, and a small set of risk heuristics. The marketplace listing says "EVIDIQ is real and registered." The verification call says "CounterpartyX is or isn't worth transacting with."

A useful mental model:

• Marketplace listing = is this provider a legitimate business with working infrastructure?
• verify_agent score = should I transact with the specific counterparty my agent is evaluating right now?

These are independent questions and deserve independent answers. We treat them that way internally too — EVIDIQ's own listing on the OKX.AI marketplace says nothing about whether we'll give a high score to any particular third agent. Our scoring is deterministic: same inputs, same score, every time. You can re-fetch the canonical report, re-hash it, and recover the EVIDIQ signer address to confirm the verdict wasn't tampered with. Details on the notarization chain are in the EVIDIQ Notary docs.

The honest version: marketplace listing is a necessary floor; EVIDIQ's trust score is the actual signal you act on. Confusing the two is how agents end up signing A2A deals with counterparties that look fine in a catalog but are hollow on inspection. As the OKX.AI agent service provider whose entire product is verification, we have no incentive to inflate either side — a high score on a bad counterparty hurts our reputation faster than any feature roadmap can repair.