Swap protection,
priced per call.

Why, when, and how to start

• It answers before you sign. Token risk (16 rug and honeypot checks) and sandwich exposure are scored at the moment of the trade, from live mainnet data.
• Every claim can be checked. A verdict comes with its reasons and the checks behind it; a built transaction comes with the plan its bytes should match and every fee itemised. An unanswered check is reported as unknown, never as a pass.
• It compares routes for you. /optimize prices Jupiter, Raydium and Jito bundles after fees, tip and modelled sandwich loss, and shows the arithmetic. Often the answer is Jupiter.

Quickstart

1. Screen a token, free. No wallet, no payment:

curl -s -X POST https://api.zendiq.ai/v1/agent/analyse-token \
  -H "content-type: application/json" \
  -d '{"mint":"DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263"}'

PowerShell:

Invoke-RestMethod -Method Post https://api.zendiq.ai/v1/agent/analyse-token `
  -ContentType 'application/json' `
  -Body '{"mint":"DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263"}' | Select-Object -ExpandProperty tokenRisk

Python, standard library only:

import json, urllib.request

req = urllib.request.Request(
    "https://api.zendiq.ai/v1/agent/analyse-token",
    data=json.dumps({"mint": "DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263"}).encode(),
    headers={"content-type": "application/json"},
)
with urllib.request.urlopen(req, timeout=30) as resp:
    body = json.load(resp)

risk = body["tokenRisk"]
print(risk["symbol"], risk["score"], risk["level"], "signals", body["signals_resolved"])

You get tokenRisk (score and level), the signals behind it with coverage in signals_resolved, and an analysisId valid for 60 seconds.

2. Get a verdict, $0.01 in mainnet USDC. POST { inputMint, outputMint, amount } to /v1/agent/analyse. The first reply is 402 with the price; sign the USDC authorization it describes from a wallet holding mainnet USDC (no SOL needed) and resend the same request with a PAYMENT-SIGNATURE header (paying for a call). Any x402 client does this for you, as does npm run analyse in the reference repository. Read verdict and reasons.

3. Build the swap, $0.02 in mainnet USDC. POST the same fields plus taker (the wallet that will sign) and the analysisId from step 1 to /v1/agent/optimize. Check transaction against plan, sign it with the taker, and submit it the way submit.method says.

For machines

Everything below is also published in machine-readable form. The live manifest is the authoritative source — fetch it at runtime rather than hardcoding what you read on this page.

• GET /v1/agent — live service manifest. Free, unauthenticated. Declares every endpoint, price, rate limit, and the field-stability contract.
• /openapi.json — OpenAPI 3.1 description of all four endpoints.
• /llms.txt — site index in llmstxt.org format.
• /llms-full.txt — the complete API reference in one file.
• Reference client + MCP server — runnable examples and a Model Context Protocol server exposing three tools: zendiq_screen_token (free), zendiq_triage_swap ($0.01) and zendiq_optimize_swap ($0.02). Install it in Claude Code with claude mcp add --scope user zendiq -- npx -y @zendiq/mcp@latest, or run npx -y @zendiq/mcp@latest from any MCP client's user config (a project .mcp.json asks for approval first); the free tool needs no wallet, and the paid tools need a spend ceiling (npx -y @zendiq/mcp@latest budget init 1.00) and a paying key in ~/.zendiq. The MCP server runs locally over stdio; agents that discover us from this page can call the endpoints directly over HTTP with x402, with nothing to install.

Weekly build videos — a dated build log from the Colosseum Crypto World's Fair. Each video states what ran locally and what ran live.

Endpoints

Base URL: https://api.zendiq.ai

curl -X POST https://api.zendiq.ai/v1/agent/analyse \
  -H "Content-Type: application/json" \
  -d '{
    "inputMint":  "So11111111111111111111111111111111111111112",
    "outputMint": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
    "amount":     "1000000000",
    "slippageBps": 50
  }'

Latency, unknowns and reusing an analysis

Most of a call's time is token screening: sixteen checks across on-chain data, RugCheck, DexScreener, GeckoTerminal and pump.fun. One scan per mint is shared by all callers and cached for 60 seconds.

No partial results

A scan always runs to completion. It is never cut short and returned with checks missing, because an agent cannot act on a partly scanned token: a missing creator-history check looks exactly like a clean one to anything that does not read every field.

One read is bounded on purpose: creator history (creator_launches_30d) has a 4 s budget. When a creator's record is longer, the launches counted so far come back as a lower bound with reason: "partial_scan_lower_bound", and the status is warn or fail, never pass.

Reading unknowns

Each source has its own timeout. One that errors or runs out its timeout is a real unknown. The scan still completes and says what it could not find out.

• Every check is in signals[] with a status of pass, warn, fail or unknown; an unknown carries a reason.
• signals_resolved is the coverage, as resolved checks over the total: "11/16" means five are unknown.
• An unknown never lowers the score. Most add an explicit …: unavailable factor with +5 caution points, so an unchecked token cannot score as clean.
• A market figure no real token can have (a market cap above $5T, or a 24h gain above +10,000% on a token over 30 days old) is an unknown with reason: "implausible_value". value is null and the rejected figure is in rejected_value; do not quote it as fact.
• Market fields come from one DexScreener pool, named in inputs.marketPair with how many pools were considered and how many were dropped for disagreeing with the median price by more than 5×.
• schema_version is per endpoint: /analyse and /analyse-token are at 1.2, /optimize at 1.1.
• The exception is a short list of established assets: regulated stablecoins, established protocol tokens such as SOL, JUP and RAY, and liquid staking tokens. An asset-class factor such as Regulated stablecoin names the checks that do not apply to that class; those are not scored, so an unknown on one of them adds nothing. Every other check still counts.

Treat unknown as unknown, never as safe. A LOW score at 6/16 means ten checks were never answered.

Reusing an analysis: analysisId

/analyse-token and /analyse return an analysisId. Pass it to /optimize within 60 seconds and it reuses that token scan instead of running a new one. Token facts are stable over seconds; market state is not. So the reused parts are the authorities, holder concentration, RugCheck report, launch platform, token age, creator history and the bundled-launch check. The quote, price impact, sandwich exposure and congestion are always fetched fresh.

POST /v1/agent/analyse-token   { "mint": "DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263" }
  → { "analysisId": "an_Q2hsZ3v0mK7pX1aRt9Yc", "analysisExpiresAt": "…", "tokenRisk": { … }, … }

POST /v1/agent/optimize   { "inputMint": "So111…112", "outputMint": "DezXAZ8z…B263",
                            "amount": "10000000", "taker": "<your wallet>",
                            "analysisId": "an_Q2hsZ3v0mK7pX1aRt9Yc" }
  → { "analysis": { "source": "reused", "reason": null, "ageSeconds": 4, … },
      "transaction": "…", … }

A missing, expired or unknown ID is not an error. /optimize resolves the scan itself and says so. analysis.source is full_scan, or cached when a scan of that mint from the last 60 s was found. reason is no_analysis_id, analysis_id_expired or analysis_id_unknown. IDs live in server memory, so a restart makes earlier ones unknown: the next call is slower, not broken.

An ID for a different mint is rejected with 400 analysis_mint_mismatch, uncharged, rather than silently replaced. Pairing one token's analysis with another token's trade is a caller bug, and fixing it quietly would hide it while you believed you were trading on a screened token. The ID must match /optimize's outputMint.

Paying for a call

ZendIQ uses the x402 protocol. There are no API keys and no accounts. You POST your request, the server replies 402 with a challenge describing the price, asset, network and payee, you sign an authorization for exactly that amount, and you retry the identical request with a PAYMENT-SIGNATURE header. X-PAYMENT is accepted as an alias; a bare PAYMENT header is not read and will return another 402.

• Requests are validated before the 402. A malformed body gets 400 invalid_request, an address that is not a token mint gets 422 not_a_mint, and on /optimize a taker that does not hold the input amount gets 422 taker_insufficient_balance, so you never sign a payment for a request that cannot be served.
• A 429 does not consume a payment authorization. Back off for Retry-After seconds and present the same one again.
• Any response ≥ 400 cancels settlement. A failed /optimize build charges nothing.
• Rate limits: 60 requests per IP per minute and 30 per payer per minute on the paid endpoints. The free /analyse-token has its own limit of 240 per IP per minute. The live figures are in rateLimits at GET /v1/agent.
• Deprecation and Sunset headers (RFC 8594) are set ahead of the payment gate, so you can detect a retiring version from the 402 without paying.

Settlement can hold the response for up to 90 seconds

The server settles your payment after your result is ready, and replies only once it knows whether the transfer landed. That usually takes a second or two. If the facilitator cannot confirm the transfer itself, the server reads the chain until the transfer confirms, fails, or can no longer land because the blockhash you signed against has expired, about 60 s after you signed. It never waits more than 90 s.

Keep the connection open: disconnecting does not stop a transfer that was already sent. If you do disconnect, present the same authorization again. While it is still settling that returns 409 with priorOutcome: in_flight; once settled, the original 200 with replayed: true.

Retry once after settlement_pending

The server keeps checking the chain after it answers. If the transfer lands, the payment is recorded as charged and not served, and presenting the same PAYMENT-SIGNATURE header again redeems it for one fresh response. The body may differ, so an /optimize is rebuilt from current quotes. Wait about 5 s first.

• Once. The redeemed response carries PAYMENT-RESPONSE with redeemed: true and the original settlement transaction. A later retry gets 409 already_served.
• Same route. An /analyse payment ($0.01) cannot be redeemed on /optimize ($0.02): 409 redemption_route_mismatch.
• Within 24 h. After that, 409 redemption_expired; email support@zendiq.ai with the signature for a refund.
• A failed build does not use it up. An error status leaves the payment redeemable.
• Still unknown. 409 settlement_unresolved with charged: null. Do not pay again.

Each of these 409s carries charged and the settlement signature. The example client and the MCP server retry for you.

Custody

None, on any endpoint. /analyse and /analyse-token build nothing. /optimize returns an unsigned transaction that only your own wallet can sign and submit. ZendIQ never sees a key, cannot move funds, and there is no deposit or approval to unwind.

When it cannot answer

ZendIQ returns 502 analysis_unavailable rather than a guessed verdict when an upstream source fails and no honest answer is possible. You are not charged. Sub-analyses degrade independently to explicit available: false objects rather than quietly returning a safe-looking score they could not compute, and the top-level degraded field names which ones — null when token screening, route and sandwich exposure all produced a result, otherwise an array of "source:reason" strings. It does not report individual token checks: a completed scan at 7/16 still has degraded: null, and its unknowns are in signals[].

This is deliberate. A safety check that fails open is worse than no check at all, because you have already calibrated trust on it and get no signal that it did not run.