DEV Community

Baris Sozen
Baris Sozen

Posted on

OKX.AI launched with agent reputation, identity, and escrow on June 30. The custody model is the whole point - and the whole problem.

On June 30, 2026, OKX opened OKX.AI to developers after a closed beta with 50 early AI service providers. The pitch, per The Block and TechCrunch: agents get one persistent on-chain identity, an Agent Marketplace where builders list services, a Task Marketplace where agents post work and pay on delivery, and payment either through instant pay-per-call transfers or escrow-backed contracts. Every job - simple or complex - accumulates into the same reputation record. Disputes go to a decentralized network of evaluators rather than an OKX employee. Infrastructure and security backing comes from AWS, CertiK, and the Ethereum Foundation, with the Solana Foundation and StraitsX also listed as partners.

It is, feature for feature, the most complete "which agent can I trust" stack anyone has shipped for the agent economy so far. It is also entirely custodial: the identity lives on OKX, the escrow lives on OKX, and the evaluators who settle disputes are OKX's network.

In the same week, Coinbase pushed further into the adjacent lane. Coinbase for Agents, shipped as both an MCP server and a CLI, connects an agent directly to a Coinbase account so it can trade and pay within limits the owner sets. The protocol underneath, x402, has now processed more than 160 million agentic payments since Coinbase's own account of the past year - a genuinely large number, and proof the "agent needs to move money" problem is being taken seriously by the biggest names in the industry.

Read both launches together and a pattern emerges: reputation, identity, and settlement keep arriving as one bundled product, built by whoever owns the custody.

Two jobs that don't have to be one product

Look at what OKX.AI's identity-and-reputation layer is actually doing. It answers a question that has nothing to do with money: has this counterparty behaved well before, and does it have the skills it claims? That's a trust-scoring problem. It can be answered by a public, queryable record of past behavior - no custody required to compute or read a reputation score.

Then look at what the escrow half of OKX.AI does: it holds funds and lets an evaluator decide when they release. That's a settlement problem, and it's the one that actually needs somewhere for the money to sit.

OKX.AI ships both in the same platform, which makes sense commercially - it's one product, one API key, one trust boundary for the developer to reason about. But it also means the reputation data an agent needs to decide whether to trade is locked inside the same custodial walls as the money itself. If OKX's evaluator network is compromised, biased, or simply goes down, both halves fail together.

What a non-custodial version looks like

We've been building the counterpart to the first half only: a Verified Counterparty Directory. It answers the identical question - who has this agent transacted with before, how did those trades resolve, is the identity behind this address one we've seen behave well - without ever touching the second half. The Directory informs the decision to trade. It never holds the asset.

The settlement itself runs on a different primitive entirely: a hash-time-locked contract. Both legs of a trade lock to the same cryptographic condition, and the secret that claims one leg is, by construction, the proof that releases the other. No evaluator decides whether the trade completes - the chain checks whether the counterparty's asset verifiably arrived, a fact with no room for judgment calls. Reputation tells you who to trade with; the lock guarantees what happens once you do. Two separate concerns, two separate trust boundaries, neither one dependent on the other staying honest.

This is the same split we wrote about this week in a different guise. ERC-8183's Evaluator role and OKX.AI's dispute network are the identical pattern applied to different products: a trusted third party judges whether a deliverable is good enough before releasing funds. For hiring - where the work product is genuinely subjective - that's a defensible design; someone has to judge whether the essay was good. For a two-sided asset trade, there's nothing subjective to judge. Either the counterparty's ETH verifiably arrived at the agreed address or it didn't. An evaluator judging that fact is pure overhead with an attack surface attached.

The Coinbase contrast, briefly

The same distinction repeats one layer down at the tooling level. Coinbase for Agents is an MCP that connects your agent to a Coinbase account - convenient, and backed by a real number (160M+ x402 payments) that proves demand. Our MCP connects your agent to the chain itself. No account sits in the middle for a compromised agent or a leaked API key to drain; the worst case is a trade in flight that fails to complete and refunds automatically at timeout.

Where this runs today

The Verified Counterparty Directory and HTLC settlement are both part of the same MCP server - hashlock-tech/mcp (scoped) on npm, six tools covering sealed-bid RFQ price discovery and HTLC lock, withdraw, refund, and status. Chain status, stated plainly: Ethereum mainnet is live end to end. Sui contracts are deployed and CLI-tested, with gateway wiring in progress. Bitcoin is validated on signet, with mainnet pending. So today, "live" means Ethereum. The contracts are immutable and went through five layers of verification - Slither, Halmos, Echidna, Stryker, and a runtime invariant monitor. The formal design is written up on SSRN.

What this doesn't fix

Honesty section. A Directory is only as good as the trade history feeding it - a new counterparty has no record, custodial or not, and reputation systems can be gamed by anyone patient enough to build a clean history before the bad trade. Decoupling reputation from custody doesn't eliminate the cold-start problem; it just means the cold-start problem doesn't also come with a single company controlling both your trust score and your funds. And for genuinely subjective work - the deliverable a hire produces - an evaluator or Evaluator-style judge is still probably the right tool. We're not claiming to replace OKX.AI's Task Marketplace. We're claiming the asset-trade half of any agent economy shouldn't need a custodian just because the reputation half does.

Docs: hashlock.markets/docs - MCP server source: GitHub

If you're building agent-to-agent trust today: would you split reputation from custody if a non-custodial directory existed, or does the convenience of one platform, one API key, win regardless of the coupling? Comments open.

Top comments (0)