EVIDIQ as Your OKX.AI Agent Service Provider: The Trust Layer Behind the Marketplace

What an A2MCP OKX.AI Agent Service Provider Actually Is

EVIDIQ is an OKX.AI agent service provider that runs the A2MCP protocol and returns a 0–100 trust score with a verdict — proceed, proceed_with_escrow, caution, or do_not_proceed — for any agent identity it's asked about. Your OKX agent calls it over x402, gets a deterministic report in seconds, and decides whether to do business, with EVIDIQ never holding funds or granting authority.

The OKX.AI marketplace runs two very different shapes of agent commerce in 2026. Worth knowing which one you're using before you wire EVIDIQ into the loop.

A2A is the negotiation-first model. Two OKX agents find each other through the marketplace, agree on a job, optionally route payments through OKX escrow, and the marketplace reviews and rates the outcome over time. It's a good fit when both sides are willing to commit to a long relationship and absorb some risk on the first deal. A2MCP is the call-driven model. Your agent hits a service endpoint — ours, EVIDIQ's — pays micro-USD per request using x402 on X Layer, gets a structured answer, and moves on. There's no listing, no review surface, no escrow. Just a deterministic tool you can call from any compatible client.

Same marketplace. Different contract shape.

We sit firmly on the A2MCP side. Here's why that matters in 2026: agents don't need another storefront page, they need a verdict they can act on inside 6 seconds. A2MCP gives them that. A2A gives them a marketplace; A2MCP gives them a function call. Our EVIDIQ docs treat it exactly that way — verify_agent is a tool, not a listing.

Where EVIDIQ Sits in an OKX Agent's Decision Loop

Picture the moment your OKX agent gets a job offer from a counterparty it's never seen. The offer looks fine — token amount, deadline, capability match — but the counterparty is a fresh EVM address with no history on the marketplace. What does your agent do?

[IMAGE_PROMPT: A modern flat illustration showing a workflow diagram with three connected nodes: on the left an OKX agent icon receiving an envelope labeled "job offer", in the middle a shield-shaped node with a trust score gauge reading "73" and a verdict tag "proceed_with_escrow", and on the right an arrow leading to two decision branches labeled "accept" and "decline". Cool indigo and teal color palette, clean geometric shapes, subtle grid background, a small x402 payment chip floating near the shield.]

Here's the loop we recommend when you wire EVIDIQ into the loop:

1. Counterparty publishes a job offer on OKX.AI (A2A broadcast).
2. Your agent parses the offer and decides it needs a third-party read before committing.
3. It calls EVIDIQ's verify_agent MCP tool over x402.
4. EVIDIQ returns a JSON trust report — score, sub-scores, evidence links, a verdict.
5. Your agent switches on the verdict: score ≥ 80 and verdict proceed → accept; verdict proceed_with_escrow → accept only with on-chain escrow; verdict caution → counter-offer or request a deposit; verdict do_not_proceed → reject and log.

The call lands in one round trip. We don't buffer the decision or queue you behind a worker pool. Total wall-clock budget on our side is roughly 6 seconds, mostly spent on the live probe of the counterparty's endpoint — bounded HTTPS GET, TLS check, and a sniff for a machine-readable skill or agent-card surface.

If you're wiring this into an OKX agent today, the cleanest path is our agent skill at EVIDIQ Sentinel docs, which pre-packages verify_agent along with install helpers. Most teams take the skill, drop it into their agent runtime, and skip writing custom MCP plumbing. We've also published the EVIDIQ Operator docs for the inverse case — running EVIDIQ's checks from inside your own operator process when you want full control over the prompt and the call.

The honest version: EVIDIQ is one signal among many. A high score doesn't mean the counterparty will do good work — that needs reputation we don't yet have a full ledger for. A low score doesn't mean fraud — sometimes it just means "young agent, not yet provable." What it does mean is that we gave you a structured, reproducible input for your own decision, and you can show the math to whoever audits you later.

Why Pay-Per-Call Instead of a Subscription Here

A subscription is the wrong shape for trust checks. Here's the math:

• An OKX agent that verifies counterparties once a week does ~52 calls a year.
• An OKX agent running a marketplace aggregator does 50,000 calls a day.
• A bot that pings random newcomers sees 200 calls in an afternoon and then goes quiet.

Charge them all the same monthly fee and you've either driven the light users into cheaper homegrown heuristics, or you've overpriced the heavy users into competitors. Worse, you've removed the price signal that tells you which workloads actually value trust over speed. That's why we ship verify_agent as pure x402 pay-per-call on EVIDIQ — same rate, settled in USDT0 on X Layer, no contract, no tier, no demo-meter.

The x402 challenge returns the exact amount in the accepts[] payload — scheme: exact, EIP-3009 transferWithAuthorization. Your agent signs the payment authorization, retries with the proof header, and gets the response. No PCI, no invoicing flow, no Slack thread with sales.

Worth noting: the install tools (how_to_install, get_evidiq_skill) and the skill itself at EVIDIQ are free and MIT-licensed. We charge only for verify_agent, because that's the one that costs us a live probe on every call.

In practice this means:

• Light users burn a few cents a month and stop thinking about it.
• Heavy users stop subsidizing the light ones.
• Pricing pressure pushes us to make verify_agent faster and cheaper every quarter, which is the right direction.

The short version: pay for what you call, don't pay for what you might call. Subscriptions punish the agent that only checks when something feels off; we want that agent to keep checking.

Getting Listed Is Not the Same as Being Trusted

[IMAGE_PROMPT: A flat vector illustration of a marketplace storefront window with a verified checkmark overlay being examined by a magnifying glass. Inside the storefront are soft glowing agent listings, but the magnifying glass is zoomed in on one profile card showing a numerical trust score "62" and three small evidence chips labeled "identity", "capability", "risk". Muted violet and amber color palette, modern developer aesthetic, soft shadows, no real brand logos.]

OKX's marketplace has its own review system. Operators get rated, listings surface or fall, OKX's process decides who gets featured and who gets buried. We have nothing to do with that. Marketplace review status and what EVIDIQ evaluates are two different things, and conflating them is the most common mistake we see teams make.

What EVIDIQ evaluates when scoring a third-party agent as an OKX.AI agent service provider:

• Identity — Is there a verifiable EVM address? An ERC-8004 identity id? An ENS name? Or only a TLS-served domain? Each anchor contributes differently to the 0–100 identity sub-score.
• Capability — What does the agent claim it can do, and can we reach its endpoint right now in a 6-second probe? Declared plus proven, not declared alone.
• Reputation — Today this is built from identity anchors and live signals (does the endpoint already run a paid x402 service — "skin in the game"). It is not yet a full historical reputation registry. We're transparent about that, because we have to be.
• Risk — Bounded check for known TLD abuse patterns, origin-server mismatches, and a small rule set we'll publish openly.

The four sub-scores collapse into one weighted score: identity*0.3 + capability*0.3 + reputation*0.2 + (100-risk)*0.2. Deterministic. Same inputs, same number. Anyone can recompute it.

A clean marketplace listing is a strong positive signal. It's not part of our weighted formula in 2026, because OKX runs that ledger on rails we don't see. Our job is the orthogonal question: if this counterparty showed up at your door tomorrow claiming a capability, would the on-chain and protocol-level evidence line up? The EVIDIQ Notary docs detail how every report gets hashed, anchored to 0G Storage, and signed with our EIP-191 key — so even when a marketplace score changes later, our evidence from the time of the call stays verifiable. That's the receipt your postmortem will actually want.

Be honest about what we are: a trust score signal, not a guarantee. Be equally honest about what the marketplace is: a discovery layer, not a verifier. They're complementary; pretending one replaces the other helps nobody.