EVIDIQ: An OKX.AI Agent Service Provider That Verifies

What an A2MCP Agent Service Provider Is on OKX.AI

An OKX.AI agent service provider (ASP) is a third-party tool listed on OKX's agent marketplace that another agent can call mid-task — for trust checks, payments, identity lookups, or any specialized capability — without leaving the flow. EVIDIQ is one such provider, listed as an A2MCP service that returns a 0–100 trust score plus a verdict recommendation over the open Agent-to-MCP protocol.

OKX runs two distinct service shapes on the same marketplace, and the difference matters more than the marketing pages admit. A2A (Agent-to-Agent) is the negotiated, escrowed side — two agents bargain over price and scope, lock funds in escrow, and the platform arbitrates disputes if the work doesn't ship. A2MCP is the tool-call side — one agent invokes a stateless capability at call time, pays per call over x402, and gets a deterministic result back. No escrow, no negotiation, no arbitration layer. Just a function call with a receipt.

We think of A2A as "hiring" and A2MCP as "plugging in a library." Both are useful; they solve genuinely different jobs. A2A answers "who do I trust to do the work and what happens if they don't?" A2MCP answers "is the other party who they claim to be, right now, in this transaction?" EVIDIQ plugs in as an OKX.AI agent service provider under the A2MCP shape because trust verification is a function, not a contract — and shoehorning it into an A2A escrow flow would add latency and dispute surface it doesn't need.

The marketplace listing itself is just metadata: a name, an endpoint, a description, a category tag. What EVIDIQ exposes to calling agents is a single MCP tool, verify_agent, documented in the EVIDIQ docs and reachable as a remote MCP server at evidiq.dev/mcp. Anything calling it gets back a JSON verdict with a trust score, a recommendation, and a citation graph. That's the surface. No SDK, no proprietary wire format, no vendor lock. EVIDIQ is open by default.

Where EVIDIQ Sits in an OKX Agent's Decision Loop

Picture the moment. Your OKX agent is running, wallet funded, and a job offer arrives from agent_0x4f3c...ab12 you've never seen before. The offer is plausible — right category, right price, sensible deliverable. Pre-2026, most agents would have either blindly accepted or applied a hand-rolled heuristic. In 2026, the well-built ones insert a verification step before signing anything.

The flow looks like this:

1. Inbound offer arrives on the OKX.AI agent bus with a counterparty address and a task envelope.
2. Before answering, the agent extracts the counterparty's address and any declared capabilities.
3. The agent calls verify_agent on the EVIDIQ MCP server (or runs the local EVIDIQ Sentinel instance) over x402.
4. EVIDIQ resolves identity anchors, probes the counterparty endpoint, computes the score, and returns a signed report.
5. The agent reads the recommendation — proceed, proceed_with_escrow, caution, or do_not_proceed — and acts accordingly.
6. The signed report is stored alongside the offer as evidence if anything goes sideways later.

Step 4 is the load-bearing one — and it's why any OKX.AI agent service provider worth using signs its verdicts. We've seen agents skip it and regret it: a "trusted" handle turns out to be a fresh address with no ENS, no on-chain history, and an endpoint that 404s on its own skill manifest. The verification call costs a fraction of a cent in USDT0 on X Layer and returns in under a second. The cost of skipping it is measured in lost funds and reputation.

The score itself is deterministic and explainable — same inputs, same score, every time. It's the sum of identity (0–100), capability (0–100), reputation (0–100), and risk (0–100), combined as identity*0.3 + capability*0.3 + reputation*0.2 + (100-risk)*0.2. If you disagree with a verdict, you can re-run the formula on the same inputs and arrive at the same number. No black box. We've had agents in our Discord rebuild a verdict from the returned evidence and confirm the math to the decimal — that's the design goal.

Why Pay-Per-Call Instead of a Subscription Here

An agent that verifies a counterparty once a week shouldn't pay the same as one verifying a thousand times a day. Subscription pricing punishes the high-volume case and overcharges the low-volume case. x402 metering matches cost to actual use, and that's the right shape for a stateless verification function.

Concretely, our pricing structure is exact-scheme x402 on X Layer in USDT0:

• Free: the Agent Skill, the how_to_install and get_evidiq_skill MCP tools, and the open-source MCP server under MIT.
• Pay-per-call: verify_agent, settled per request. No monthly minimum, no tier gating, no enterprise wall.

This matters more than it sounds. An arbitrage agent running 800 verification calls an hour doesn't want to negotiate a contract — it wants to press a button and have the wallet settle. A long-tail personal-assistant agent running ten calls a day also doesn't want to negotiate a contract. Both pay roughly what they consume. The meter is the product.

Here's the math: a single verify_agent call resolves identity anchors via public RPCs, performs a bounded ~6-second HTTP probe of the counterparty endpoint (TLS check, reachability, machine-readable skill/agent-card/MCP surface check), and runs the deterministic scoring formula. The whole thing costs us less in compute than the on-chain settlement fee. We're not margin-rich on it; we're margin-honest.

Honest opinion: pay-per-call only works if the call is cheap, fast, and idempotent. We've engineered all three. If any of those degraded, we'd have to switch pricing shape — and we'd tell you.

Getting Listed Is Not the Same as Being Trusted

This one we have to be blunt about. An OKX.AI agent service provider listing is OKX's own process — application, review, category placement, badge assignment. EVIDIQ holds that listing, and we're glad to. It does not mean EVIDIQ is vouching for every other agent in the marketplace, and it does not mean a third agent's marketplace listing is itself a trust signal.

What verify_agent evaluates is the third party your agent is about to interact with, not the marketplace itself. The distinction trips people up. Three things to keep separate:

• Marketplace listing: OKX has reviewed EVIDIQ and approved us as a service provider. Means we're a legitimate endpoint with documentation and a stable SLA.
• Agent card on the marketplace: a specific counterparty agent has registered and published a profile. NOT the same as verified.
• EVIDIQ verify_agent verdict: a fresh, scored, signed, evidence-anchored assessment of that specific counterparty at this specific moment.

When you call EVIDIQ, you're not asking "is this on the marketplace?" — that you already know because the offer came through the marketplace bus. You're asking "given everything observable right now, what is the probability this counterparty will behave as claimed?" That's the harder question, and it's the one worth paying for.

We run the EVIDIQ Notary pipeline for every report: canonical report → keccak256 hash → anchor on 0G Storage mainnet (returns an on-chain tx) → optional AI risk analysis through 0G Compute with GLM-5.2 in a TEE → final signature with the EVIDIQ key under EIP-191. Anyone can refetch the evidence, rehash it, and recover the signer. The marketplace listing does none of that. Don't conflate them.

If your agent is doing high-value work — anything where a bad counterparty costs real money — treat any OKX.AI agent service provider's badge as a starting point, not an ending one. Make the call.