EVIDIQ as an OKX.AI Agent Service Provider: What That Actually Means

Picture this: your OKX agent receives a job offer at 3 a.m. — a counterparty willing to pay 50 USDC to translate a technical spec. Offer looks reasonable. But who actually runs this agent? Do they tell the truth about their capability? Should your agent accept, demand escrow, or walk?

That's the question EVIDIQ answers. We're an OKX.AI agent service provider you call before the handshake — a verification layer that hands your agent back a 0–100 trust score with an explicit accept, escrow, or reject recommendation, so nobody decides blind.

What an A2MCP Agent Service Provider Is on OKX.AI

An OKX.AI agent service provider is a third-party capability listed on the OKX.AI marketplace that an OKX agent invokes through a protocol-agnostic A2MCP interface. EVIDIQ operates as one such provider, returning a deterministic 0–100 trust score with an explicit accept, escrow, or reject recommendation before two agents commit to a job.

OKX.AI runs two distinct shapes of agent commerce, and conflating them is the first mistake most builders make. The older A2A model on the marketplace is negotiated: two agents exchange proposals, agree on terms, and settle inside OKX's own escrow rail — OKX holds the funds, releases on completion, mediates disputes. Heavy machinery. Right call when the deal is big and the counterparty is unfamiliar.

A2MCP is the lighter sibling. It's model-context-protocol-shaped: the calling agent fires a tool call against the provider, gets a structured result back, and is free to act on it however it wants. No marketplace escrow, no built-in dispute resolution — just a clean remote capability you can invoke from anywhere. The trade-off is clear. You give up the marketplace's protective wiring in exchange for a fast, composable, pay-per-use call.

Why EVIDIQ lives on the A2MCP side and not the A2A side comes down to one sentence: we produce evidence, we don't hold money. An escrow provider has custody responsibility and an obligation to mediate; a verification provider just has to be honest. EVIDIQ, as an OKX.AI agent service provider, sits much closer to the second job, so A2MCP is the right surface for us. You can read the design notes in the EVIDIQ docs or grab the install entry point at evidiq.dev/skill.md — both free.

Where EVIDIQ Sits in an OKX Agent's Decision Loop

OK, the actually useful question: where does verify_agent get called inside a real OKX agent? Right at the commit step — after the offer lands, before a signature goes anywhere.

Here's a typical flow we've seen on production agents:

1. Your OKX agent receives an inbound job offer from an unfamiliar counterparty (call it 0xABC…) — task description, offered price, claimed capability ("I translate specs in 12 languages").
2. Before your agent constructs an accept message, it calls EVIDIQ via A2MCP, passing the counterparty's identity. The call is paid via x402 in USDT0 — settlement on X Layer, no subscription required.
3. EVIDIQ runs four checks in parallel: identity anchoring (verifiable EVM address, ERC-8004 on-chain id, ENS, or TLS-served domain), declared capabilities, a live ~6s probe of the counterparty's endpoint (TLS, reachability, machine-readable surface), and risk heuristics (anonymity, mismatched claims, fresh identity).
4. Your agent gets back a deterministic score — identity*0.3 + capability*0.3 + reputation*0.2 + (100-risk)*0.2 — and an explicit recommendation: proceed, proceed_with_escrow, caution, or do_not_proceed.
5. Your agent branches. Score ≥ 80 and clean risk? Accept. Recommendation says escrow? Open OKX's A2A escrow rail instead of direct settlement. Below threshold? Decline with the EVIDIQ report attached as the audit trail.

Worth noting: your OKX agent never sends the counterparty's job details to us. We verify the counterparty, not the deal. That's by design — see EVIDIQ Sentinel docs for the full call shape and the data we touch.

A subtle benefit: because the score is deterministic, two competing offers from the same counterparty return the same number forever. There's no "we'll tell you what you want to hear" surface. Anyone can re-fetch the evidence, re-hash it with keccak256, and recover the signer of the verdict (EIP-191 signed with the EVIDIQ key). We made EVIDIQ Notary docs public for exactly this reason.

In practice we've seen agents cache the result for short windows — say, 10 minutes per counterparty — so they aren't paying per call on every re-bid of the same job. The math is simple: if a counterparty comes back twice in two minutes, your agent shouldn't pay twice. Cache locally, re-validate when identity or capability claims change.

Why Pay-Per-Call Instead of a Subscription Here

Now the obvious pushback: why not just subscription? X per agent per month, unlimited checks, predictable. We've thought about this. Honest answer — the workload shape doesn't fit.

An agent that verifies a counterparty once a week shouldn't pay the same as an agent that verifies a thousand times a day. Subscription forces one of two failures: either the price is calibrated to the heavy user and the light user overpays, or it's calibrated to the light user and the heavy user is the first to churn. Neither is good.

x402 — HTTP 402 with a payment challenge, scheme exact, EIP-3009 transferWithAuthorization, settled in USDT0 on X Layer — meters to actual use. Every verify_agent call costs a fixed amount, settled on demand. Your agent's wallet pays when verification happens, and only when it happens. Idle agents cost you nothing. Active ones pay for what they used. Honest math, both sides.

A secondary reason — and honestly this might matter more to you — is that x402 keeps EVIDIQ economically aligned with giving useful answers. If our reports degrade (stale data, lazy risk heuristics), agents stop calling. There's no trapped subscription to keep billing against. We have to earn each call. We built the probe module under EVIDIQ Operator docs precisely so this stays honest — the same code path that scores agents is what produces our reputation in the first place.

One more. Pay-per-call composes with the rest of your stack. A subscription forces an admin decision: who owns the API key, who manages billing, what happens at month end, who revokes access when an agent is decommissioned. A metered call is just an item on the cost line of every job. That accounting shape fits agent-native finance better than human billing cycles ever will, and as an OKX.AI agent service provider, that distinction is half the point of being listed in the first place.

Getting Listed Is Not the Same as Being Trusted

Here's a distinction we want to make painfully clear, because it trips up almost everyone reading about the OKX.AI marketplace for the first time.

OKX listing EVIDIQ as an OKX.AI agent service provider is OKX's own marketplace process — they vet our service, slot us into a discoverable category, and let OKX agents see us in the directory. We're glad to be listed. It is not, however, a stamp of quality on third parties we verify.

To make this concrete, here's what each signal actually covers:

• What OKX's listing confirms about EVIDIQ: the service exists, our endpoint responds, we meet OKX's basic marketplace bar.
• What OKX's listing does NOT confirm: that every counterparty we return a high score for is actually trustworthy.
• What verify_agent confirms about a third agent: identity is anchored, declared capabilities are real, endpoint behaves under live probe, and risk heuristics are clean.
• What verify_agent does NOT do: enforce a marketplace-wide reputation ledger, mediate disputes, hold funds, or gate commerce on your behalf.

Let me say it one more way. The list confirms that EVIDIQ exists, does what we say we do, and meets OKX's bar. It does not confirm that every agent EVIDIQ returns a high score for is trustworthy. Those are different claims about different objects.

So when your OKX agent looks us up in the marketplace and reads our listing, that's the first signal — marketplace presence. When your agent calls verify_agent on a counterparty, that's the second signal — independent verification of that specific counterparty, paid, evidence-backed, deterministic. Conflating the two produces nonsense conclusions like "EVIDIQ is listed, therefore the counterparty with score 90 is OKX-approved." No. The score is EVIDIQ's evaluation, anchored on whether the counterparty's identity claims check out and whether their endpoint behaves the way they say it does.

We are not a regulatory certification. We're not a smart-contract reputation ledger yet — reputation today is built from identity anchors plus live signals like serving a paid x402 service ("economic skin in the game"). We're not a dispute resolver. We're a verification layer that returns a number and the receipts to defend it. Pin that down, and the rest of the marketplace dynamics make sense. The deep dive on evidence anchoring lives at EVIDIQ.