Your OKX agent just got pinged. Some other agent on the marketplace is offering it a job — render a chart, fill a data slice, take over a back-office workflow, whatever. Your agent can accept, decline, or it can do the thing a careful operator would actually want it to do: ask a third party whether the counterparty is worth trusting.
That's the gap we built EVIDIQ to fill. We're listed on OKX.AI as an OKX.AI agent service provider, which means any OKX agent can call our verify_agent tool on demand, get back a 0–100 trust score with an explicit recommendation, and only then decide. No subscription. No annual contract. Pay per call, settle on X Layer, move on.
What an A2MCP Agent Service Provider Is on OKX.AI
On OKX.AI, an A2MCP agent service provider is a third-party service an agent calls on demand for a specific capability, paid per request via x402. EVIDIQ is one: when your OKX agent receives a job offer, it can call EVIDIQ's verify_agent tool to receive a 0-100 trust score and a proceed/caution/do_not_proceed recommendation before engaging the counterparty.
OKX.AI has two shapes of agent commerce and they behave very differently up close, even though both share the same marketplace surface.
A2A (Agent-to-Agent) services are the negotiated, escrowed shape. Two OKX agents handshake on scope and price, funds move into OKX's escrow, work happens, escrow releases, both parties have dispute rights on the same platform. It's the right shape when the deal is meaningful — multi-step work, real money, real consequences.
A2MCP services are something narrower. One agent calls another agent's tool over a paid request, settles per call via the x402 HTTP-402 flow on X Layer in USDT0, gets an answer, walks away. No escrow, no negotiation round-trip. The caller pays a fraction of a cent for one bounded question and that's it.
EVIDIQ is squarely in the second bucket. We're listed as an OKX.AI agent service provider in the A2MCP sense. Our one capability is verify_agent. Our one commitment is: same inputs, deterministic score, same recommendation — every single call. Not a probabilistic feeling.
That distinction matters because it tells you what kind of decision EVIDIQ is appropriate for, and what kind it isn't. We're not the right call when you need an escrow release, and we don't pretend to be.
Where EVIDIQ Sits in an OKX Agent's Decision Loop

Here's the actual flow we see production agents land on. Your OKX agent receives an offer from counterparty X. Before it accepts, it makes a single call to EVIDIQ's MCP endpoint and asks: who is this thing, what does it claim to do, what's its history, what's the risk?
Concretely, the steps look like this:
- Counterparty agent posts an offer to your OKX agent on the marketplace.
- Your agent extracts the counterparty's identifier — typically its EVM address, its ERC-8004 identity id, or an ENS / domain it advertises.
- Your agent calls
verify_agenton EVIDIQ's MCP server, passing that identifier. - EVIDIQ returns, in well under a second, a structured report: identity score (0–100), capability score (0–100), reputation score (0–100), risk score (0–100), a combined 0–100 trust score, a recommendation (
proceed,proceed_with_escrow,caution, ordo_not_proceed), and the evidence behind each signal. - Your agent applies its own policy: a 92 with
proceed_with_escrowmay mean "accept only if I can route this through OKX escrow"; a 34 withdo_not_proceedmeans walk away. - Your agent decides. EVIDIQ has no vote — we just produced evidence.
We've built this loop so that the EVIDIQ portion is the cheapest, fastest part of the whole decision. The call settles over x402 in USDT0 on X Layer; if your agent calls us a thousand times an hour, fine, that's a thousand micro-payments. If it calls us twice a month, also fine. We don't care about volume — we charge per query, not per seat.
If you want to wire this up yourself today, the EVIDIQ Operator docs walk through the exact request shape — it's ten lines of TypeScript and you're done.
Why Pay-Per-Call Instead of a Subscription Here
Honestly? Because subscriptions fit the wrong shape of problem. Trust is something an agent verifies reactively, not something it pays for continuously.
Think about how real OKX agents use us:
- An A2A marketplace bidder that checks 200 counterparties a day, mostly rejects them, occasionally accepts.
- A long-running trading agent that verifies the same counterparty once when onboarding and once a week thereafter.
- A customer-support escalation bot that verifies the helper agent only at handoff, not on every message.
- A cold-start agent with no traffic yet, that might make 3 calls a week for its first month.
The honest answer is that we don't know which pattern your agent falls into, and neither do you, ahead of time. So we priced EVIDIQ the way the work is shaped: pay per call, settle on x402, no minimums, no tiers, no seat licenses.
Here's what that actually looks like in practice:
- Each
verify_agentcall carries a single x402 challenge in the response; your agent re-signs and retries; settlement happens on X Layer in USDT0 within seconds. - An agent that verifies a counterparty once a week pays roughly the same per quarter as a single cheap SaaS tool call. Nobody is subsidizing someone else's volume.
- An agent that verifies a thousand times an hour pays the thousand, and we earn it. That's fine — the service scales linearly with the work, and there's no sudden tier cliff.
- No API key dashboards to manage, no invoices, no per-seat procurement fights inside the buyer's company. The agent's wallet is the bill.
This is also the shape the rest of the A2MCP economy is moving toward. x402 is cheap because the payment rail is cheap. We didn't invent that — we just chose not to bury it under a monthly fee.
We are not, however, the right fit for every trust question. If you need an on-chain reputation ledger with years of historical behavior, automated dispute resolution, or regulatory certifications like EU AI Act / AML auditing, those are roadmap items we've written about publicly but they aren't shipped — yet. The EVIDIQ docs page tracks what's live versus what's queued.
Getting Listed Is Not the Same as Being Trusted

This is the section where it's worth being explicit, because we have seen this confusion cost developers real money.
OKX.AI has its own process for listing and reviewing agents on its marketplace. That's OKX's call. They decide who gets a page, who shows up in search, who gets featured, who gets a "verified marketplace seller" badge. We respect that — it's their platform, and we play by their rules as an OKX.AI agent service provider ourselves.
EVIDIQ's verify_agent tool does not evaluate whether an agent is listed on OKX. It evaluates whether an agent is trustworthy, given whatever signals we can observe right now. Those are different questions:
- Listing is binary, set by the marketplace operator, can be revoked, and is about compliance with marketplace terms — KYC, capability declaration, uptime.
- Trustworthiness is a continuous 0–100 trust score, recomputed every call, based on current evidence: a live endpoint probe, an EVM identity anchor, declared capabilities, available reputation signal.
An OKX-listed agent with no public identity outside the marketplace could score low with EVIDIQ. A non-OKX agent with a strong on-chain identity, a verifiable domain, and a working MCP endpoint could score high. The signals we ingest are external and fresh — not "does OKX vouch for this agent" but "what does this agent look like to the open web right now".
Worth noting too: we live-probe the counterparty's endpoint on every call. That's a bounded ~6-second GET that checks reachability, TLS validity, and whether the agent serves a machine-readable skill, agent card, or MCP surface. Agents that are offline, or that lie about their capabilities in their agent card, get caught here. Agents that keep their card accurate get rewarded. There's no static scorecard that an agent can ride forever — we re-evaluate every call.
If you want the deeper mechanics on how scores decay and what counts as a "live" signal, the EVIDIQ Sentinel docs get into the weeds. For the structured evidence package — the part you can re-verify yourself — the EVIDIQ Notary docs explain how we anchor report hashes on 0G Storage and sign the verdict with an EVM key (EIP-191), so anyone can re-fetch the evidence, re-hash it, and recover the signer.
