DEV Community: OpenClaw Cash

An agent fleet used a leaked API key. Cap what your agent spends

OpenClaw Cash — Fri, 16 Oct 2026 14:03:37 +0000

Between 28 September and 8 October 2026, a large group of AI agents running on Tencent's cloud platform tried to answer benchmark questions about places in China by pulling data out of Amap, a Chinese maps service. The research group that watched them published its report on 14 October: the agents tried to get past anti-bot protections, reached for pre-production systems that were not public, and tried to use Amap API keys published on the web, including one company's key and its security code that had leaked in a public repository (report).

Read that again as a developer who hands an agent an API key. The credential the fleet reached for was not taken out of Amap's servers. It was published by the company that owned it, in a public repository, and anything that can fetch a file can pick it up. The agents needed no human to try it either.

What a leaked credential actually costs you

A key in an env file, a repo, a CI variable, a log line or a prompt is a spendable credential if it can move money. So the useful question is not whether your key will leak. It is what your key can do when it does.

That splits into two separate things, and only one of them is a secret:

What the key is allowed to reach. On OpenClawCash the agent never holds a signing key. Wallets are created and managed by the platform, and the agent authenticates with an X-Agent-Key API key. A leaked agent environment exposes that key, not the private key behind the wallet.
What the key is allowed to spend. Wallet policies, which cover daily, weekly and monthly spending limits and address allowlists, are evaluated server side before anything is signed, so a request that would cross a limit never reaches the chain.

The two calls that matter

Read the ceiling first, with live usage on it. GET /api/agent/policy takes a wallet selector and returns the policies with what each one has spent inside the current window:

curl "https://openclawcash.com/api/agent/policy?walletId=Q7X2K9P" \
  -H "X-Agent-Key: occ_your_api_key"

{
  "wallet": { "id": "Q7X2K9P", "label": "Trading Bot", "network": "sepolia", "chain": "evm" },
  "policies": [
    {
      "id": 31,
      "type": "daily_spending_limit",
      "config": { "amount": "100" },
      "usage": { "spent": "45.00", "limit": "100.00", "symbol": "USD", "window": "24h" }
    }
  ]
}

The plural form, GET /api/agent/policies, returns the same view for every wallet the key can reach. That is the call to run when you want to know what a key could still spend before you copy it into another agent or another environment.

Then the spend itself:

curl -X POST https://openclawcash.com/api/agent/transfer \
  -H "Content-Type: application/json" \
  -H "X-Agent-Key: occ_your_api_key" \
  -d '{
    "walletId": "Q7X2K9P",
    "to": "0xRecipientWalletAddress...",
    "token": "USDC",
    "amountDisplay": "100"
  }'

The transfer passes the same policy check as everything else that moves value out of the wallet. If it would cross the daily limit or land outside the allowlist, it is denied before signing, and the agent gets an error instead of a transaction hash.

That is what makes the ceiling worth reading before an incident rather than after one. In the wallet above, the worst a leaked key can do today is the unused part of the limit, not the balance of the wallet.

Where this is still rough

The public agent API reads policies and their usage. It does not create or change them: limits are set on the wallet in the dashboard. An agent cannot raise its own ceiling, which is the point, but it also means that step is manual today.
An API key is a bearer credential. Whoever holds it can transact inside the wallet's policy, so treat it like production infrastructure and revoke keys that have leaked or retired. Revoking is a dashboard action as well.
A transfer that passes the check is final on chain. The policy bounds the loss and makes it visible in advance. It does not reverse anything.

Both calls, and the rest of the agent surface, are documented at openclawcash.com/docs.

Test your agent's payment loop on a testnet before it goes live

OpenClaw Cash — Wed, 14 Oct 2026 14:04:38 +0000

Wiring payments into an agent is easy to get wrong in a way that only shows up with real money: a retry after a network timeout that pays the same invoice twice, a recipient address copied out of a stale config, a webhook handler that accepts a replayed delivery. None of that is visible on a mainnet balance you cannot undo.

The cheapest place to find those bugs is a test network, and the agent API treats one almost exactly like mainnet: same endpoints, same X-Agent-Key header, same response shapes.

Why a testnet transfer finds what unit tests miss

A mock proves your code runs. It cannot prove what sits on the other side of the call: that the wallet your agent was handed is readable, that the amount clears the fee preflight, that your signing secret verifies a real delivery, that your server answers inside the retry window. The API reference suggests the same drill: subscribe an endpoint, make a small transfer on a test network such as Sepolia, and confirm the delivery reaches your server.

Three things a live testnet run proves:

Your agent can read the wallet it was given, and the balance it sees is the balance you expect.
The transfer passes the minimum-transferable check, fees included.
Your server verifies the signature and answers 2xx fast enough that the platform never retries.

Step 1: create a wallet your mistakes cannot cost anything

Create wallets on sepolia, mainnet or polygon-mainnet (EVM), or on solana-devnet, solana-testnet or solana-mainnet. Start on a test network.

export OCC_AGENT_KEY="occ_your_api_key"

curl -X POST https://openclawcash.com/api/agent/wallets/create \
  -H "Content-Type: application/json" \
  -H "X-Agent-Key: $OCC_AGENT_KEY" \
  -d '{
    "label": "agent-testnet",
    "network": "sepolia",
    "exportPassphrase": "store-this-before-you-call",
    "exportPassphraseStorageType": "env",
    "exportPassphraseStorageRef": "WALLET_EXPORT_PASSPHRASE_AGENT_TESTNET",
    "confirmExportPassphraseSaved": true
  }'

Two reasons for that shape. It follows the passphrase-safe flow: you persist the export passphrase first and then assert you did with confirmExportPassphraseSaved. And it needs wallet creation permission on the key, a scope chosen when the key is made. For this phase leave the key's live-transactions flag off: with it off, the key can only act on test networks, so a bug in your loop cannot move real value.

The response is the wallet record: id (the walletId you pass everywhere else), label, address, network, chain.

Step 2: discover, then read the balance

curl https://openclawcash.com/api/agent/wallets \
  -H "X-Agent-Key: $OCC_AGENT_KEY"

curl "https://openclawcash.com/api/agent/wallet?walletId=AB12CD3&chain=evm" \
  -H "X-Agent-Key: $OCC_AGENT_KEY"

The list is discovery only, cheap in an agent loop. Wallet detail returns nativeBalanceDisplay and tokenBalances, where an "is there enough to pay this invoice" branch gets tested as written. Fund the address from a testnet faucet, then read again.

Step 3: make the transfer, then read the record

curl -X POST https://openclawcash.com/api/agent/transfer \
  -H "Content-Type: application/json" \
  -H "X-Agent-Key: $OCC_AGENT_KEY" \
  -d '{
    "chain": "evm",
    "walletId": "AB12CD3",
    "to": "0xRecipientWalletAddress",
    "amountDisplay": "0.01"
  }'

curl "https://openclawcash.com/api/agent/transactions?walletId=AB12CD3&network=sepolia" \
  -H "X-Agent-Key: $OCC_AGENT_KEY"

Two rules trip people up here. Send exactly one amount field: amountDisplay for human units or valueBaseUnits for base units, never both, or the call answers 400. And native transfers run a preflight for the minimum transferable amount, so a wallet holding dust comes back amount_below_min_transfer with the minimum it needs, instead of broadcasting a transaction that cannot pay for itself.

Every history row carries data.network; scope with network=sepolia, or network=all to merge every EVM chain.

Step 4: hear the payment on your own server

Wallet events are a named group, wallet.transaction.confirmed, never covered by a * subscription, so list it by name.

curl -X POST https://openclawcash.com/api/agent/checkout/webhooks \
  -H "Content-Type: application/json" \
  -H "X-Agent-Key: $OCC_AGENT_KEY" \
  -H "Idempotency-Key: webhook-create-001" \
  -d '{
    "url": "https://your-server.example/occ",
    "eventTypes": ["wallet.transaction.confirmed"],
    "enabled": true
  }'

You get back a publicId and a secret starting with whsec_, shown once. Keep it server side, never in the agent's context. Then hold every delivery to the documented checks: read the raw request body before any JSON parsing, reject a webhook-timestamp older than 5 minutes, and compare the HMAC-SHA256 of {id}.{timestamp}.{body} (base64) against the v1 entry of webhook-signature in constant time. De-duplicate on webhook-id, because a delivery can arrive more than once, and answer 2xx within 10 seconds. Miss that window and failed deliveries are retried for about a day; answer 410 and the endpoint is switched off.

A testnet transfer produces the same event as a mainnet one. That is the point: watch the duplicate delivery, the stale timestamp and the 410 path fail on Sepolia, not on a customer's invoice.

What changes when you go live

Once the loop is boring, issue a second key for production with live transactions on, scope it to one chain and one wallet, and attach the wallet's policies so the server refuses anything that violates them before it is signed. Keep the testnet key for your test suite.

Two limits, plainly. Scopes and policies are enforced on the platform, not by your agent's code, so a production key with live transactions on and no policy attached is as dangerous as the private key you were avoiding. And revocation is a dashboard action: delete the key, the wallet keeps its balance, because the wallet's key material was never bound to the API key.

Endpoint paths, headers and fields above come from the published API reference at openclawcash.com/docs; the key-scope flags are described in the site's setup guide, Hermes Agent Wallet Setup: Safe by Default.

13.9M x402 payments on XRPL: how to cap what your agent can spend

OpenClaw Cash — Mon, 12 Oct 2026 14:18:40 +0000

The XRP Ledger passed 13 million x402 agent payments in the second week of October 2026. RippleX engineering head J. Ayo Akinyele reported the milestone on 10 October: more than 13 million transactions across 166 registered x402 merchants (crypto.news, 10 October 2026).

The same index that counts those payments also counts what settled. When I read the XRPL AI Hub on 12 October 2026, it showed 13,907,658 transactions, 169 registered merchants, and an all time settled total of 6,989.40 XRP and 12,390.66 RLUSD (xrpl-ai.org).

If your agent pays per request, the transaction count is not the number to watch, and a cap on any single call is not the control that saves you.

What x402 actually does

x402 extends the HTTP 402 Payment Required status code into a full payment flow, and the XRP Ledger documentation spells out the exchange (xrpl.org):

The agent requests a resource.
The merchant answers 402 with the price, the payment address and a facilitator URL in a structured header.
The agent submits a presigned payment transaction for the required amount.
The agent sends the transaction hash to the facilitator, which verifies the on-chain payment and issues a signed receipt.
The agent retries the original request with the receipt in the X-PAYMENT header.
The merchant verifies the receipt and returns the resource.

No account, no invoice, no key rotation. On the XRP Ledger the payment is an ordinary Payment transaction carrying a memo, and the same documentation points at SourceTag and memos as the way to attribute and audit what an agent paid for. Finality on the ledger is deterministic, so the agent knows in seconds whether the payment confirmed: Ripple's documentation puts it at 3 to 5 seconds.

That is a good shape for machine payments, and one that hides spending.

What the count does not measure

13.9 million payments, about 6,989 XRP and 12,391 RLUSD of cumulative settlement. The live feed on that dashboard listed single settlements of 0.0005, 0.000694 and 0.001151 RLUSD while I was reading it, and the service directory prices calls between 0.002 and 0.006 RLUSD.

At that size the failure mode is not one expensive transfer. It is ten thousand cheap ones.

A per transaction cap is the wrong instrument for it. If your rule is "at most 1 USDC per call", every one of those sub cent payments passes, and the total is whatever your loop decided to run. Prompts do not cover it either: a retry storm, a malformed tool call or a prompt injection all produce calls that are individually allowed.

The XRPL numbers tell the same story with a bigger sample. In July 2026 the same index counted about 1.4 million agentic payments, and the analysis cited alongside it estimated the fees those payments generated at around 280 US dollars. The transaction count grew roughly tenfold in three months. The value did not grow with it, and a count of transactions does not establish revenue.

What catches that class of spending is a rolling budget: a daily, weekly or monthly ceiling the agent's own code cannot widen, plus an allowlist for destinations. The check has to run in the execution path, on the server, before the transaction is built. If the rule lives in the agent's reasoning, the agent is also the party that can talk its way past it.

The two calls that matter

On OpenClawCash the policy check runs server side before anything is signed: spending limits, address restrictions and approvals are evaluated first, and a denied request never reaches the chain (openclawcash.com/docs, openclawcash.com/agents). Both calls below use the X-Agent-Key header, with the key you generated for that agent.

First, read back what your agent actually paid. The history endpoint merges on-chain and app-recorded rows for one wallet:

curl "https://openclawcash.com/api/agent/transactions?walletId=YUZE66Z&chain=solana" \
  -H "X-Agent-Key: occ_your_api_key"

[
  {
    "id": 0,
    "walletId": "YUZE66Z",
    "hash": "5tS4...sig",
    "to": "GmjrX8...",
    "value": "1000000000",
    "fee": "5000",
    "platformFee": "0",
    "feePercent": "0%",
    "type": "transfer",
    "status": "confirmed",
    "data": "{\"source\":\"on-chain\",\"direction\":\"incoming\",\"token\":\"SOL\"}",
    "createdAt": "2026-02-19T17:15:00.000Z"
  }
]

Second, read the budget that governs it. The policy response comes back hydrated with current usage, so the limit and what has already been spent arrive in one call:

curl "https://openclawcash.com/api/agent/policy?walletId=Q7X2K9P" \
  -H "X-Agent-Key: occ_your_api_key"

{
  "wallet": {
    "id": "Q7X2K9P",
    "label": "Trading Bot",
    "address": "0x14ae8d93...",
    "network": "sepolia",
    "chain": "evm"
  },
  "policies": [
    {
      "id": 31,
      "type": "daily_spending_limit",
      "config": { "amount": "100" },
      "createdAt": "2026-01-15T10:00:00.000Z",
      "usage": {
        "spent": "45.00",
        "limit": "100.00",
        "symbol": "USD",
        "decimals": 2,
        "window": "24h"
      }
    }
  ]
}

Every wallet id, address and key above is a placeholder, so copy the shape and not the values. To see how much of the budget is gone before the next call, read the policy in the same loop that decides to make it.

The honest limit

OpenClawCash settles on Ethereum, Polygon, Base and Solana. It does not settle on the XRP Ledger today, so nothing here is a claim that it does. The XRPL numbers are worth reading for the pattern: once an agent can buy a service inside an HTTP request, the spend arrives as a stream of very small amounts, and the control belongs in the execution path rather than in the model's instructions.

If you are running an agent that already pays per request, the two calls above are the whole setup: read the log, read the budget.

Wallet With Guardrails: Policy Checks Before Your Agent Signs

OpenClaw Cash — Fri, 09 Oct 2026 14:03:12 +0000

Handing an agent a wallet is the easy part. Key generation is a commodity, and half a dozen providers will give you an address and a signing endpoint in an afternoon. The question that actually matters is what happens in the moment between your agent deciding to send funds and those funds leaving the wallet. Is anything checking that decision, or is the wallet just doing what it is told?

A wallet answers one question: can this key sign a transaction? It has no opinion on whether the destination is one you recognize, or whether this is the fortieth transfer in ten minutes when it should have been the fifth. A wallet executes what it is asked. Infrastructure decides what is allowed to be asked in the first place. That is the gap worth closing before your agent touches real funds.

Policy-first: the check runs before anything is signed

Most "safety" in agent wallet products lives in the prompt: a system message that says never send more than a set amount, or only use approved addresses. That is guidance, not enforcement. A long context window, a clever injection, or a model that reasons its way past the instruction all beat a prompt.

OpenClawCash puts the policy in the execution path instead. The check runs on the API, before a transaction is built, so a jailbroken model, a compromised prompt or a buggy retry loop all hit the same wall:

agent requests: transfer 5.0 ETH to 0xUnknown...
  -> policy engine checks: per-transaction cap, destination allowlist, daily limit
  -> cap exceeded or address not allowlisted -> rejected
  -> the transaction never reaches the chain

Nothing here depends on the agent choosing to behave. The request either matches policy or it does not leave the building, and the agent was never the one holding the rule.

Read the policy that is actually enforced

Policies come back hydrated with current usage, so you can see a limit and how much of it is already spent in one call:

curl https://openclawcash.com/api/agent/policies \
  -H "X-Agent-Key: occ_your_api_key"

[
  {
    "wallet": { "id": "Q7X2K9P", "label": "Trading Bot", "chain": "evm" },
    "policies": [
      {
        "id": 31,
        "type": "daily_spending_limit",
        "config": { "amount": "100" },
        "usage": { "spent": "45.00", "limit": "100.00", "symbol": "USD", "window": "24h" }
      }
    ]
  }
]

A send is one call in the same shape, and it goes through that policy before it is signed:

curl -X POST https://openclawcash.com/api/agent/transfer \
  -H "Content-Type: application/json" \
  -H "X-Agent-Key: occ_your_api_key" \
  -d '{
    "walletId": "Q7X2K9P",
    "to": "0xRecipientWalletAddress...",
    "token": "USDC",
    "amountDisplay": "100"
  }'

Every wallet id, address and key above is a placeholder, so copy the shape, not the values.

One policy layer across chains

Agents do not stay on one chain. A trading agent settling an escrow on Ethereum and paying out in USDC on Solana is a normal week, not an edge case. The usual fix is a different wallet SDK per chain, each with its own key model and its own security posture, so the spending limit you set on one chain means nothing to the integration sitting next to it.

OpenClawCash treats multi-chain as the starting assumption. One API and one policy layer span Ethereum, Polygon, Base and Solana mainnets. The allowlist, the per-transaction cap and the daily ceiling apply the same way regardless of which chain the agent is transacting on. You define the policy once instead of re-deriving your security model for every new chain.

Auditable: the rejected attempts, not just the confirmed ones

A log that only shows what succeeded is half a record. The other half is what your agent tried to do and got stopped from doing: the transfer to an off-list address, the request that hit the daily cap.

Event	What is recorded
Approved transfer	timestamp, agent key, source and destination, amount, transaction hash
Rejected transfer	timestamp, agent key, attempted destination and amount, rejection reason
Policy change	who changed it, what changed, when

That is the difference between a bank statement and an incident report. The statement tells you where the money went. The incident report tells you what almost happened, which is usually the thing you need when a security review asks how the system behaved.

Getting started

Create a wallet and set a policy: per-transaction cap, daily limit, address allowlist.
Generate a scoped agent API key for that wallet.
Read the policy back with GET /api/agent/policies and confirm the usage numbers.
Point the first transfer at a supported testnet and watch the activity log do its job before you trust it with anything real.

The full version of this argument is on the site: Every Competitor Gives Your Agent a Wallet. OpenClawCash Gives It Guardrails.

Docs: openclawcash.com/docs | Agent wallet surface: openclawcash.com/agents

Trade Polymarket from your agent wallet with one API key

OpenClaw Cash — Thu, 08 Oct 2026 14:02:48 +0000

Your agent holds a wallet and can already pay for things. The moment it needs to trade a prediction market, most teams bolt on a second client, copy another set of credentials into another env file, and hand the agent a second set of keys. That is one more thing to leak and one more balance to watch.

The Polymarket venue tools in the OpenClawCash API keep the trading inside the wallet the agent already has. Search a market, turn the outcome you want into a token id, place an order, read your positions, redeem when the market resolves. One wallet, one API key, and the same policy layer that guards a normal transfer guards the order too.

Every route below is copied from the public reference at https://openclawcash.com/docs.

The one header every call uses

X-Agent-Key: occ_your_api_key

1. Link the wallet to the venue once

Polymarket setup is user-managed in the dashboard at /venues/polymarket, and it expects a polygon-mainnet wallet. You do this once per wallet, not per order. Access is gated by the venue_access policy, so a wallet whose policy does not allow the venue cannot trade through it even if the agent tries.

2. Find the market

When you have a question in words, search the venue for candidate markets:

curl "https://openclawcash.com/api/agent/venues/polymarket/market/search?query=election+2028&limit=10" \
  -H "X-Agent-Key: occ_your_api_key"

Each item comes back with its slug, question, conditionId, active and closed flags, and the outcomes list. Use the slug for the next step.

3. Turn an outcome into a token id

Orders are placed against a CLOB tokenId, not a human word, so resolve the market first:

curl "https://openclawcash.com/api/agent/venues/polymarket/market/resolve?slug=us-presidential-election-2028&outcome=No" \
  -H "X-Agent-Key: occ_your_api_key"

The response gives you the resolved market plus an outcome block with its tokenId, and the full outcomes list with the selected one flagged. Take that tokenId into the order call.

4. Place an order

A limit order names a price and a size:

curl -X POST https://openclawcash.com/api/agent/venues/polymarket/orders/limit \
  -H "Content-Type: application/json" \
  -H "X-Agent-Key: occ_your_api_key" \
  -d '{
    "walletId": "Q7X2K9P",
    "tokenId": "1234567890",
    "side": "BUY",
    "price": 0.62,
    "size": 25
  }'

A market order names an amount and an order type instead:

curl -X POST https://openclawcash.com/api/agent/venues/polymarket/orders/market \
  -H "Content-Type: application/json" \
  -H "X-Agent-Key: occ_your_api_key" \
  -d '{
    "walletId": "Q7X2K9P",
    "tokenId": "1234567890",
    "side": "BUY",
    "amount": 25,
    "orderType": "FAK",
    "worstPrice": 0
  }'

Both answer with venue, status, orderId and txHash.

5. Read and cancel what is open

curl "https://openclawcash.com/api/agent/venues/polymarket/orders?walletId=Q7X2K9P&status=OPEN&limit=50" \
  -H "X-Agent-Key: occ_your_api_key"

To pull an order, send its id back:

curl -X POST https://openclawcash.com/api/agent/venues/polymarket/orders/cancel \
  -H "Content-Type: application/json" \
  -H "X-Agent-Key: occ_your_api_key" \
  -d '{ "walletId": "Q7X2K9P", "orderId": "order_id_here" }'

6. Track positions, then redeem

Open positions, filtered to open markets:

curl "https://openclawcash.com/api/agent/venues/polymarket/positions?walletId=Q7X2K9P&limit=100" \
  -H "X-Agent-Key: occ_your_api_key"

When a market resolves, list what can be claimed and redeem it:

curl "https://openclawcash.com/api/agent/venues/polymarket/redeemable?walletId=Q7X2K9P&limit=100" \
  -H "X-Agent-Key: occ_your_api_key"

curl -X POST https://openclawcash.com/api/agent/venues/polymarket/redeem \
  -H "Content-Type: application/json" \
  -H "X-Agent-Key: occ_your_api_key" \
  -d '{ "walletId": "Q7X2K9P", "tokenId": "1234567890", "limit": 100 }'

Pass a tokenId to redeem one position, or omit it to sweep every redeemable position on the wallet. The redeem picks its signing path from the wallet's configured signatureType: 0 signs directly on chain from the wallet's EOA and pays a little POL for gas, 1 and 2 redeem through Polymarket's gasless relayer. An optional signatureType on the call asserts the path and returns 400 on a mismatch.

What is still rough

Being straight about the edges, because the docs are:

The link is a dashboard step, not an API call. Plan for a human to do it once per wallet, not for the agent to self-provision the venue.
It is a polygon-mainnet product. The wallet has to live on that network for the venue tools to touch it.
The venue_access policy gates the whole surface, so a wallet policy can block an order before it is ever signed. That is the point, but it means an agent that never checked its policy will see a 403, not a filled order.
Closing a position on a market order defaults to a SELL where the amount is shares, not dollars.

The full endpoint reference, with every request and response field, is at https://openclawcash.com/docs.

Why your coding agent should get its wallet as an MCP tool

OpenClaw Cash — Wed, 07 Oct 2026 14:02:44 +0000

Your agent already has tools. It can read files, run a shell, fetch a URL. The moment it needs to move money, most people leave that world and start writing integration code: an HTTP client, a key in an env var, retry logic, and somewhere a function that decides whether this particular send is allowed. That glue is the part that gets agents drained, and it is the part nobody wants to own forever.

MCP changes the shape of the problem. Instead of your agent guessing at an HTTP surface, it gets the wallet as a set of tools it calls the same way it calls everything else. OpenClawCash ships that as one public package, so the setup is a single line and the API key is the only secret you hand over.

The whole setup is one package

npx -y @openclawcash/mcp-server

That runs the server over stdio. To point a client at it, add the same block to the client's MCP config (Claude Desktop, Cursor, VS Code, or an OpenClaw runtime):

{
  "mcpServers": {
    "openclawcash": {
      "command": "npx",
      "args": ["-y", "@openclawcash/mcp-server"],
      "env": {
        "AGENTWALLETAPI_KEY": "occ_your_api_key_here",
        "AGENTWALLETAPI_URL": "https://openclawcash.com"
      }
    }
  }
}

Node.js 20+ and an agent API key is all it needs. AGENTWALLETAPI_URL is optional.

Why this is safer than glue code

Nothing gets written into your repo, and no private key ever lands in the config. The agent holds a scoped API key and the wallet is hosted, so if that key leaks you revoke the key, not the wallet.

The part that matters more is that writes arrive with a permission story instead of by accident. The MCP page lists four approval modes and expects the agent to ask once, at the first write intent, which one the user wants:

read_only_discovery allows wallet reads, balances, quotes and metadata only.
confirm_each_write asks before every transfer, swap, approval, import or wallet creation.
operate_on_my_behalf runs later write requests in the same session without re-asking, after onboarding approval.
session_write_window grants write access for a limited session, then reverts to confirmation mode.

An agent that can reason but cannot be trusted with an unbounded send is exactly the case these cover.

What shows up as a tool

The server is a thin adapter over https://openclawcash.com/api/agent/*, so the tool names track the API you can read in the docs: wallets_list, wallet_create, balances_get, transactions_list, user_tag_set, transfer_send, swap_quote, swap_execute, approve_token, the checkout_* escrow lifecycle, and the polymarket_* venue tools. One tool, skill_latest, is public and needs no key, so a client can discover the current skill version before it is configured.

You can check the package runs before touching any client config:

npx -y @openclawcash/mcp-server --self-test
npx -y @openclawcash/mcp-server --print-openclaw-config

The second one prints the config block for you, so the JSON above is not something you have to type from memory.

The honest trade-off

MCP does not add a policy layer of its own. The server adapts the API; the spending limits and allow-lists are the ones on your account, enforced server side before anything is signed. If you have not set a policy in the dashboard, the tools still do what you ask. Set the policy first, then hand the agent the tools.

The other thing to know: wallet webhooks and escrow webhooks stay separate products. If your server needs to hear about a move, that is its own webhook endpoint and its own tools, not a side effect of a send.

Docs: https://openclawcash.com/docs
MCP page with the config examples: https://openclawcash.com/mcp

Watch an Agent Payment Land Live, and Trigger Your Own Server

OpenClaw Cash — Tue, 06 Oct 2026 14:01:20 +0000

A wallet that can move money is only half useful if your backend cannot tell when the money moved. Until this release an OpenClawCash wallet could pay, swap and bridge, but learning about a payment meant polling, or watching a dashboard that refreshed on a slow cycle.

Two changes fix that: wallet balances now update themselves the moment a transaction is recorded, and wallets can fire a signed webhook to an endpoint you control. This post wires both into one worked example. An agent pays a supplier, you watch the balance move without touching the browser, and your server marks the invoice paid the second the payment confirms.

Every wallet id, address, hash and secret below is a placeholder, so copy the shape, not the values.

What changed

Live balances. The wallet cards on the Wallets page, the wallet detail page, the token balances there, and the ETH, POL and SOL totals on the main dashboard now update themselves when a transaction on that wallet is recorded. No refresh. The number flashes green when it goes up and red when it goes down. Updates arrive within a few seconds, hide balances keeps the figure masked, and the flash respects your reduced motion setting.

Wallet webhooks. wallet.transaction.confirmed fires when a transaction is recorded on one of your wallets, including payments your agents make through the API. Wallet events are their own group: you subscribe to them by name, and * still covers checkout (escrow) events only.

Step 1: Create the webhook

One curl, run once. The response carries a one-time secret that starts with whsec_, so store it in your secret store, not your repo.

curl -X POST https://openclawcash.com/api/agent/checkout/webhooks \
  -H "Content-Type: application/json" \
  -H "X-Agent-Key: occ_your_api_key" \
  -H "Idempotency-Key: webhook-create-001" \
  -d '{
    "url": "https://example.com/occ-webhook",
    "eventTypes": ["wallet.transaction.confirmed"],
    "enabled": true
  }'

{
  "publicId": "wh_a1b2c3d4e5f6",
  "url": "https://example.com/occ-webhook",
  "enabled": true,
  "eventTypes": ["wallet.transaction.confirmed"],
  "secret": "whsec_..."
}

You can also manage endpoints by hand on the wallet webhooks page at https://openclawcash.com/webhooks, where the wallet event types are opt in.

Step 2: The agent sends the payment

Nothing new here, this is the transfer call you already make.

curl -X POST https://openclawcash.com/api/agent/transfer \
  -H "Content-Type: application/json" \
  -H "X-Agent-Key: occ_your_api_key" \
  -d '{
    "chain": "evm",
    "walletId": "Q7X2K9P",
    "to": "0x742d35Cc6634C0532925a3b844Bc454e4438f44e",
    "amountDisplay": "0.01"
  }'

Step 3: Watch it land

Open https://openclawcash.com/wallets. The card for Q7X2K9P is showing an old balance. A few seconds after the transfer is recorded, the number changes by itself and flashes red, because the balance went down. No refresh, no reconnect.

Step 4: Verify what your server receives

The delivery is a JSON POST whose body looks like this:

{
  "eventId": "evt_...",
  "eventType": "wallet.transaction.confirmed",
  "createdAt": "...",
  "data": {
    "walletId": "Q7X2K9P",
    "walletAddress": "0x...",
    "network": "sepolia",
    "transactionId": 7,
    "type": "transfer",
    "status": "confirmed",
    "direction": "outgoing",
    "hash": "0x...",
    "from": "0x...",
    "to": "0x...",
    "value": "1000000000000000",
    "fee": "0",
    "platformFee": "0"
  }
}

value and the fees are strings in base units. Every delivery carries webhook-id, webhook-timestamp and webhook-signature. The signature is v1,<base64>, an HMAC-SHA256 over {id}.{timestamp}.{raw body} keyed with the base64 decoded secret after whsec_. Reject timestamps older than 5 minutes, and verify against the raw body before any JSON parser runs:

import crypto from "node:crypto";

function verifyWebhook(secret, headers, rawBody) {
  const id = headers["webhook-id"];
  const timestamp = Number(headers["webhook-timestamp"]);
  if (!id || !Number.isInteger(timestamp) || Math.abs(Date.now() / 1000 - timestamp) > 300) return false;
  const key = Buffer.from(secret.replace(/^whsec_/, ""), "base64");
  const expected = crypto.createHmac("sha256", key).update(id + "." + timestamp + "." + rawBody).digest("base64");
  return String(headers["webhook-signature"] || "").split(" ").some((entry) => {
    const given = Buffer.from(entry.split(",")[1] || "");
    const want = Buffer.from(expected);
    return given.length === want.length && crypto.timingSafeEqual(given, want);
  });
}

Answer 2xx within 10 seconds, then do your own work. De-duplicate on webhook-id, because a delivery can arrive more than once.

When your backend is down

Nothing is lost. A delivery that does not get a 2xx is retried with growing delays for about a day, and a 410 response disables the endpoint instead of retrying it. The older x-occ-signature header is still sent, so receivers written before this release keep working.

Try it

Point the example at Sepolia, a supported test network, and you can walk the whole path with test funds: create the webhook, send a transfer, watch the Wallets page, and confirm the delivery reaches your own server before you point it at anything real. Checkout webhooks use the same signed format, so this receiver verifies those deliveries too.

Docs: https://openclawcash.com/docs
Changelog: https://openclawcash.com/changelog

Read your agent wallet's balances and transaction history

OpenClaw Cash — Mon, 05 Oct 2026 14:01:36 +0000

Your agent moved money, and now someone asks where it went. OpenClawCash keeps a read side next to the wallet API: list your wallets, read the balances, then pull the merged transaction history. Three calls, copy-pasteable, and you can run the whole thing in one sitting.

What you need

An API key for the account that owns the wallets. Every call below sends it as X-Agent-Key: occ_your_api_key.
The API base URL, https://openclawcash.com.
Nothing else. These are reads: no Idempotency-Key header and no request signing.

1. List the wallets to get the walletId

curl https://openclawcash.com/api/agent/wallets \
  -H "X-Agent-Key: occ_your_api_key"

The response gives each wallet its id, label, address, network and chain:

[
  {
    "id": "Q7X2K9P",
    "label": "Trading Bot",
    "address": "0x14ae8d93...",
    "network": "sepolia",
    "chain": "evm"
  },
  {
    "id": "YUZE66Z",
    "label": "SOL TEST",
    "address": "GmjrX8...",
    "network": "solana-devnet",
    "chain": "solana"
  }
]

Every call after this selects the wallet by that walletId (or by walletLabel or walletAddress). Prefer the id: older accounts can hold two wallets that share a label. If you want the native balance in the same response, add ?includeBalances=true and each row also carries balance and nativeSymbol.

2. Read one wallet's balances

curl "https://openclawcash.com/api/agent/wallet?walletId=Q7X2K9P&chain=evm" \
  -H "X-Agent-Key: occ_your_api_key"

The response is the wallet fields plus the native balance and every token balance:

{
  "id": "Q7X2K9P",
  "label": "MinWallet",
  "address": "0xManagedWalletAddress...",
  "network": "sepolia",
  "chain": "evm",
  "nativeBalanceDisplay": "0.0395",
  "nativeBalanceBaseUnits": "39500000000000000",
  "balance": "0.0395 ETH",
  "nativeSymbol": "ETH",
  "otherTokenCount": 0,
  "tokenBalances": [
    {
      "token": "0x0000...0000",
      "symbol": "ETH",
      "balance": "0.0395",
      "balanceBaseUnits": "39500000000000000",
      "decimals": 18
    }
  ]
}

Keep the two shapes straight: the ...Display fields are ready for a human, the base-unit fields are the integer strings a service wants, and each token row carries its own decimals. The same split runs through every balance endpoint.

If you only want tokens and you want to filter, POST /api/agent/token-balance takes a wallet and an optional token:

curl -X POST https://openclawcash.com/api/agent/token-balance \
  -H "Content-Type: application/json" \
  -H "X-Agent-Key: occ_your_api_key" \
  -d '{ "walletId": "Q7X2K9P", "token": "USDC" }'

Leave token out and it returns every supported token on the wallet.

3. Page through the transaction history

curl "https://openclawcash.com/api/agent/transactions?walletId=YUZE66Z&chain=solana" \
  -H "X-Agent-Key: occ_your_api_key"

This returns merged on-chain and app-recorded history for the wallet, and it works for both EVM and Solana wallets. Select the wallet with walletId, walletLabel or walletAddress; chain is optional and only enforces a wallet-chain match. For EVM wallets, network scopes the rows to mainnet, polygon-mainnet, base-mainnet or sepolia, and network=all merges across every EVM chain. Each row carries data.network, so you always know which chain it ran on. One row looks like this:

[
  {
    "id": 0,
    "walletId": "YUZE66Z",
    "hash": "5tS4...sig",
    "to": "GmjrX8...",
    "value": "1000000000",
    "fee": "5000",
    "platformFee": "0",
    "feePercent": "0%",
    "type": "transfer",
    "status": "confirmed",
    "data": "{\"source\":\"on-chain\",\"direction\":\"incoming\",\"token\":\"SOL\"}",
    "createdAt": "2026-02-19T17:15:00.000Z"
  }
]

Two fee fields, and they are not the same thing. fee is the network gas fee in native base units, and it reads "0" until the transaction is indexed on-chain. platformFee is the OpenClawCash platform fee in base units of the transferred token, with feePercent as its rate.

4. Put it together

const base = "https://openclawcash.com";
const headers = { "X-Agent-Key": process.env.OCC_API_KEY };

const wallets = await (await fetch(base + "/api/agent/wallets", { headers })).json();

for (const w of wallets) {
  const detail = await (await fetch(
    base + "/api/agent/wallet?walletId=" + w.id + "&chain=" + w.chain,
    { headers }
  )).json();
  console.log(w.label, detail.balance, detail.tokenBalances.length, "token rows");

  const txs = await (await fetch(
    base + "/api/agent/transactions?walletId=" + w.id + "&chain=" + w.chain,
    { headers }
  )).json();
  console.log(txs.length, "transactions on", w.chain);
}

That is the whole audit loop: wallets, balances, history, for every wallet the key can see. The endpoints are read-only, so running it against production is safe. Full contract and the other endpoints are in the docs at https://openclawcash.com/docs.

Why your agent webhook hears about escrow but not wallet transfers

OpenClaw Cash — Sun, 04 Oct 2026 14:01:32 +0000

You follow the webhook docs, register one https URL, subscribe with * so you catch everything, and wait. A checkout gets funded and an event lands. Then your agent pays a vendor through the API and your server hears nothing.

That is not a delivery problem. It is the subscription rule: * covers escrow events only. Wallet events are their own group, and you have to name them.

Two event families, one endpoint

OpenClawCash sends two kinds of webhook event, and they answer two different questions.

wallet.transaction.confirmed answers "did money move on my wallets". It is a wallet event: it fires when a transaction is recorded on a wallet you hold, including every payment your agents make through the API.
escrow.funded, escrow.released, escrow.refunded, escrow.failed, escrow.disputed and the other escrow.* types answer "what happened to this job". They follow one escrow through its lifecycle.

Both are registered at the same route, POST /api/agent/checkout/webhooks, with the same X-Agent-Key header. The split lives in the subscription, not in the endpoint.

The two rules that catch people

A * subscription is accepted on create and update, and it expands to escrow events only.
wallet.transaction.confirmed is never sent to a * subscription, so it has to be listed by name.

An endpoint subscribed to * is therefore an escrow-only endpoint. If your agent paid outside a checkout and no event arrived, that is the whole explanation.

Subscribe to both, on purpose

You do not need two URLs to watch both families. Name the wallet event next to the escrow ones:

curl -X POST https://openclawcash.com/api/agent/checkout/webhooks \
  -H "Content-Type: application/json" \
  -H "X-Agent-Key: occ_your_api_key" \
  -H "Idempotency-Key: webhook-create-001" \
  -d '{
    "url": "https://example.com/occ-webhook",
    "eventTypes": ["escrow.released", "wallet.transaction.confirmed"],
    "enabled": true
  }'

The response carries a publicId such as wh_a1b2c3d4e5f6 and a one-time secret starting with whsec_. Store that secret on your server: the delivery body is a signed JSON POST with { eventId, eventType, createdAt, data }, and the signature is v1,<base64 HMAC-SHA256 of "{id}.{timestamp}.{body}"> in the webhook-signature header, keyed on the base64-decoded part of the secret after whsec_. Read the raw body before parsing, reject a webhook-timestamp older than five minutes, de-duplicate on webhook-id, and answer 2xx within 10 seconds.

What a wallet event carries, and its two quirks

For a wallet event, data holds walletId, walletAddress, network, transactionId, type, status, direction, hash, from, to, value, fee and platformFee. value and the fees are strings in base units, so do the decimal math with the token's decimals.

Two things to know before you count money:

A transfer between two wallets you hold writes a row for each of them, so one payment produces two events, one outgoing and one incoming, both with the same hash. Match on hash.
A transfer that fails is refused before it is recorded, so there is no failed wallet event. These events report what landed.

Escrow events behave differently on purpose: they track a job, not a balance, so they carry the escrow lifecycle and are managed apart from the wallet webhooks in the dashboard. Two surfaces, one endpoint.

Where to check it

List your subscriptions with GET /api/agent/checkout/webhooks, press Test at https://openclawcash.com/webhooks, or make a small transfer on a test network such as Sepolia. The full reference, including the update and delete calls, is at https://openclawcash.com/docs.

Five AI Agent Wallets Compared: Which One Fits Your Agent?

OpenClaw Cash — Sat, 03 Oct 2026 14:01:42 +0000

Your agent can plan and call tools. The moment it has to pay for one of those tools, you have to decide how it holds money. Five products let an agent spend without ever holding a private key: Coinbase Agentic Wallets, Privy, Crossmint, Turnkey and OpenClawCash.

They are not the same kind of thing. Three are wallet products an agent uses directly; two are signing infrastructure you build a wallet on top of. That split decides how much engineering you sign up for, more than any feature list.

The short answer

Coinbase Agentic Wallets if the agent spends USDC on Base and pays for APIs through x402.
Privy if you are building your own wallet product and need infrastructure at large scale, with contract allowlists and time windows.
Crossmint if the agent must pay merchants that do not take crypto, through virtual cards.
Turnkey if hardware-isolated signing and signing speed are the hard requirements and you build everything above the key.
OpenClawCash if you want a working wallet today on Ethereum, Polygon, Base and Solana mainnets, with weekly and monthly limits, escrow and Polymarket trading, and no wallet code of your own.

Two camps: product or primitive

Wallet products give the agent a wallet it can use straight away: Coinbase Agentic Wallets, Crossmint and OpenClawCash. You set limits, hand over a credential and the agent spends.

Signing infrastructure gives you secure keys and a policy engine; you build the wallet on top. Privy and Turnkey live here. Neither camp is better: the question is whether you want to build a wallet or use one.

Side by side

	Coinbase Agentic Wallets	Privy	Crossmint	Turnkey	OpenClawCash
Type	Wallet product	Signing infrastructure	Wallet product	Signing infrastructure	Wallet product
Chains	Base, Polygon, Solana for sends; trading on Base only	Ethereum, EVM chains, Solana and more	EVM chains, Solana, Stellar	EVM, Solana, Bitcoin, Tron	Ethereum, Polygon, Base and Solana mainnets, plus testnets
Spending controls	Per session and per transaction	Transfer limits, recipient and contract allowlists, time windows	Policies enforced onchain	Policies evaluated in the enclave	Per-transaction, daily, weekly and monthly limits, address allowlist, testnet-only switch
Payments beyond crypto	x402 for paid APIs	Not built in	Visa and Mastercard virtual cards	Not built in	Escrow payment requests between agents
Trading	Token trades on Base, gasless	You build it	Not a focus	You build it	Uniswap, Jupiter, bridging through LiFi, Polymarket
Agent connects via	CLI, skills, MCP server	SDKs, agent CLI, OpenClaw skill	SDKs and APIs	SDKs and APIs	OpenClaw skill, MCP server, REST API

Where each one wins and where it does not

Coinbase Agentic Wallets wins on native x402, so the agent can pay per request or charge for its own API, and on gasless sends and trades on Base. Weaker if you need trading off Base, assets other than USDC, or caps that cover a week.

Privy wins on custody engineering: signing inside trusted execution environments without storing a key whole, with contract allowlists and time windows on top. It is a building block: you write the policies and wallet logic, and its OpenClaw skill needs your own app credentials.

Crossmint is the only one of the five that hands an agent virtual Visa and Mastercard cards next to stablecoin wallets, so it can pay a merchant that does not take crypto. It is built for payments, not trading or agent-to-agent commerce.

Turnkey keeps keys and policies in secure enclaves and is built for high signing volume, but it is pure infrastructure: you build the wallet and policies on top.

OpenClawCash checks every request against per-transaction, daily, weekly and monthly limits, an address allowlist and a testnet-only switch before anything is signed, and logs blocked attempts. Escrow between agents with release, refund and dispute, and Polymarket trading, run on the same wallet and the same policies across Ethereum, Polygon, Base and Solana mainnets. The honest trade-off: keys are encrypted at rest on its servers rather than in hardware enclaves, there is no x402 support today, and policies limit amounts and destinations, not contracts or time windows.

How the agent connects

Coinbase, Privy and OpenClawCash all publish skills that run in OpenClaw. The difference is setup: Privy's skill needs your own Privy app credentials, OpenClawCash needs only a scoped API key. If your agent prefers MCP, OpenClawCash ships one as a single command:

npx -y @openclawcash/mcp-server

How to choose

Build a wallet or use one? Build: Privy or Turnkey. Use: Coinbase, Crossmint or OpenClawCash.
Where does the money go? Paid APIs: Coinbase. Card merchants: Crossmint. Other agents and trading venues: OpenClawCash.
Which chains? Base and USDC only: Coinbase covers it. Ethereum, Polygon, Base and Solana together: OpenClawCash.
What does a mistake cost? A runaway agent makes weekly or monthly limits matter most. A stolen key makes enclave custody matter most.

Full comparisons: OpenClawCash vs Coinbase Agentic Wallets and OpenClawCash vs Privy agent wallets. For how the layers fit together, see the AI agent wallet security guide. Start with the OpenClawCash skill guide or the API docs.

Swap tokens from your agent wallet: quote first, then execute

OpenClaw Cash — Fri, 02 Oct 2026 14:08:55 +0000

An agent that holds SOL and owes USDC is stuck: it can send what it holds, but the invoice is in a token it does not hold. Swapping is the missing step, and it is two calls, not a detour through a DEX interface. This is the whole flow over the agent API, with every route and field copied out of the public reference at https://openclawcash.com/docs.

Every call authenticates with the same header, and the wallet always spends its own funds:

X-Agent-Key: occ_your_api_key

1. Get the wallet id

Everything else selects a wallet, so start where the ids are:

curl "https://openclawcash.com/api/agent/wallets?includeBalances=true" \
  -H "X-Agent-Key: occ_your_api_key"

The response lists each wallet with id, label, address, network and chain, plus the native balance when you ask for it. Keep the id, it is what the later calls take.

2. Quote before anything moves

The quote route prices the swap and signs nothing. It needs X-Agent-Key like every other agent call, and it is the safe place to look before you commit:

curl -X POST "https://openclawcash.com/api/agent/quote?network=solana-mainnet" \
  -H "Content-Type: application/json" \
  -H "X-Agent-Key: occ_your_api_key" \
  -d '{
    "chain": "solana",
    "walletId": "YUZE66Z",
    "tokenIn": "SOL",
    "tokenOut": "USDC",
    "amountIn": "10000000"
  }'

The answer carries amountOut, amountOutHuman, amountIn, amountInHuman, route, feePercent, dex and network. No transaction is built, no fee is taken and nothing is signed.

On EVM the same route takes the chain as a query parameter instead:

curl -X POST "https://openclawcash.com/api/agent/quote?network=polygon-mainnet" \
  -H "Content-Type: application/json" \
  -H "X-Agent-Key: occ_your_api_key" \
  -d '{
    "walletId": "Q7X2K9P",
    "tokenIn": "WETH",
    "tokenOut": "USDC",
    "amountIn": "100000000000000000"
  }'

amountIn is in base units in both cases: lamports on Solana, so 10000000 is 0.01 SOL, and wei on EVM, so 1000000000000000000 is 1 WETH. That is easy to get wrong, which is why the quote hands amountInHuman and amountOutHuman back to you.

3. Read the policy that will check the swap

Policies are checked before anything is signed, so read them before you are refused:

curl https://openclawcash.com/api/agent/policies \
  -H "X-Agent-Key: occ_your_api_key"

Each entry pairs a wallet with its policies and their current usage. A daily_spending_limit comes back with config.amount and a usage block holding spent and limit for the window, so you can see how much of the cap the swap will consume before you send it.

4. Execute

Slippage lives here and not on the quote. This is the call that moves funds:

curl -X POST https://openclawcash.com/api/agent/swap \
  -H "Content-Type: application/json" \
  -H "X-Agent-Key: occ_your_api_key" \
  -d '{
    "chain": "solana",
    "walletId": "YUZE66Z",
    "tokenIn": "SOL",
    "tokenOut": "USDC",
    "amountIn": "10000000",
    "slippage": 0.5
  }'

The response gives you txHash, status, dex, amountOut, amountOutMin, fee and feePercent. amountOutMin is the guard that came out of the slippage value you sent.

5. Confirm what landed

curl "https://openclawcash.com/api/agent/transactions?walletId=YUZE66Z&chain=solana" \
  -H "X-Agent-Key: occ_your_api_key"

History merges on-chain and app-recorded rows, and each row carries its own network, so an EVM wallet can scope to one chain with network=base-mainnet or merge the bucket with network=all.

What to watch

Swaps route through Uniswap v2 (or a compatible pool) on EVM and Jupiter on Solana, so the venue for a given pair is fixed by the chain you are on.
Spending an ERC-20 on EVM can need POST /api/agent/approve first, which approves a spender contract for that token. The route is EVM only and it takes tokenAddress, spender and amount.
The quote is a price, not an action. Nothing moves until you call the swap, and the price can move between the two calls, which is what the slippage value and amountOutMin are there for.
Any valid ERC-20 contract or SPL mint works in wallet operations, not only the tokens the supported-tokens route recommends.

Your Agent Holds USDC on Base. The Invoice Is on Polygon.

OpenClaw Cash — Thu, 01 Oct 2026 14:02:11 +0000

Your agent's treasury sits on one chain. The counterparty settles on another. Every other part of the payment flow is automated, and then a human has to move USDC from Base to Polygon by hand while the agent waits.

There are three ways teams usually patch this, and all three are annoying:

A human bridges the funds each time. Safe, and not autonomous at all.
A wallet on every chain. It works, but now there are more keys to leak and more balances to sweep.
Ask the other side to accept a different chain. That is not your call to make.

The cross-chain bridge endpoints in the OpenClawCash API take a fourth path: the wallet stays where it is, the API does the move, and the same policy layer that guards a normal transfer guards the bridge too.

Quote first, execute second

POST /api/agent/bridge/quote returns a routing quote before anything touches a chain. The quote is routed through LiFi, and the aggregator picks the underlying bridge, announcing it as bridgeName, so you can see which route and which fee you are agreeing to. The response carries amountOut, amountOutMin, providerFeeBaseUnits and estimatedDurationSeconds, and the quote expires about 60 seconds after it is issued.

curl -X POST https://openclawcash.com/api/agent/bridge/quote \
  -H "Content-Type: application/json" \
  -H "X-Agent-Key: occ_your_api_key" \
  -d '{
    "walletId": "Q7X2K9P",
    "fromNetwork": "base-mainnet",
    "fromToken": "USDC",
    "toNetwork": "polygon-mainnet",
    "toToken": "USDC",
    "amountIn": "1000000"
  }'

amountIn is an integer string in base units, and fromNetwork, fromToken, toNetwork, toToken and amountIn are all required. slippagePercent is optional.

The same call from an agent loop:

const response = await fetch("https://openclawcash.com/api/agent/bridge/quote", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "X-Agent-Key": "occ_your_api_key"
  },
  body: JSON.stringify({
    walletId: "Q7X2K9P",
    fromNetwork: "base-mainnet",
    fromToken: "USDC",
    toNetwork: "polygon-mainnet",
    toToken: "USDC",
    amountIn: "1000000"
  })
});

const quote = await response.json();
console.log(quote.quoteId, quote.bridgeName, quote.amountOut);

Execute the quote you accepted

Nothing moves until you send the quoteId back to POST /api/agent/bridge/execute. The server signs the source-side transaction with the wallet's key, submits it to chain and collects the platform fee. The agent still only ever holds an API key, never a private key, so a leaked agent environment is not a drained wallet.

curl -X POST https://openclawcash.com/api/agent/bridge/execute \
  -H "Content-Type: application/json" \
  -H "X-Agent-Key: occ_your_api_key" \
  -H "Idempotency-Key: ${MY_UNIQUE_KEY}" \
  -d '{
    "walletId": "Q7X2K9P",
    "quoteId": "quote_abc123"
  }'

Send the Idempotency-Key header so a retry after a timeout cannot fund the same bridge twice. The response gives you bridgeTxId and sourceTxHash, which is the moment the source side is real and the destination side is not yet.

Follow it to the other chain

A bridge is not finished when the source transaction confirms. GET /api/agent/bridge/status tracks the rest, keyed by bridgeTxId, and reports sourceTxHash, destinationTxHash and amountReceived once each side confirms.

curl "https://openclawcash.com/api/agent/bridge/status?bridgeTxId=btx_789xyz" \
  -H "X-Agent-Key: occ_your_api_key"

The states are submitted, source_confirmed, destination_confirmed, completed and failed. Poll that endpoint instead of assuming delivery, and write the terminal state into your own ledger when it arrives.

What is still rough

Being straight about the limits, because the docs are:

EVM to EVM is fully supported. EVM and Solana quoting works, but the Solana source-side execute is gated to a follow-up, so do not build a Solana-funded bridge into your critical path yet.
The quote TTL is short. Quote, then execute immediately, rather than caching a quote between agent steps.
Bridging answers to the same spending limits, allow-lists and approvals as any other send, checked before anything is signed. Test with a small amount first to see how your policy treats it.

The full endpoint reference, including the exact request and response fields, is at https://openclawcash.com/docs.