Build against proof.

Record and policy-check a declared agent payment, independently observe what settled onchain, reconcile the two against what the executor reported, and get a signed record either side can verify — across HTTP, MCP, and a TypeScript SDK. The core HTTP and MCP surfaces need no account or API key; workspace features and Auto-Evidence use an existing OCD workspace API key.

1 · Agent payments

Overview

OnChainDiligence is a pay-per-call HTTP API. A client calls an endpoint, receives a 402 Payment Required challenge, pays a few cents of stablecoin, and retries the request with proof of payment attached. The server verifies payment, runs the check against live data or an on-chain observation, and returns a signed result.

Each response carries an Ed25519 signature over the data and the signer’s timestamp assertion. Store the response with independently trusted key records to verify it later without contacting this service. A separately verified anchor is required for an external time bound.

• Sanctions, name, and company data come from public sources documented under Evidence Providers below — they are inputs this infrastructure signs and delivers, not the product itself.
• Action and provider evidence (allowance, swap, bridge, staking, and commerce-executor settlement) independently observe what an agent's payment actually did on-chain, separate from any provider's own claim.
• The fee covers infrastructure only — not the underlying data, which is free and public where sourced externally.

Base URL

All API requests go to the api subdomain over HTTPS:

https://api.onchaindiligence.com

The bare domain onchaindiligence.com serves this site, not the API — point integrations at api.onchaindiligence.com.

Evidence Provider API quickstart

This separate paid Evidence Provider API example is not the offline demo or a native Tempo MPP/Stripe MPP commerce integration. For agent-payment onboarding, use SDK 0.10.1. Commerce lifecycle requests go to https://mcp.onchaindiligence.com, not the Evidence Provider API base above.

See a live 402 challenge right now — no wallet, no key, just curl:

# returns 402 Payment Required with the MPP challenge
curl -i https://api.onchaindiligence.com/screen/0x7f268357A8c2552623316e2562D90e642bB538E5

To run the check and get a signed result, the mppx CLI handles the entire challenge-pay-retry flow for you. Set the private key of a Tempo wallet holding pathUSD, then call any endpoint:

# key of a wallet holding a little pathUSD on Tempo
export MPPX_PRIVATE_KEY=0xYOUR_KEY

npx mppx https://api.onchaindiligence.com/screen/0x7f268357A8c2552623316e2562D90e642bB538E5

The CLI receives the 402, builds and submits the payment on Tempo, and prints the signed JSON result. To call the API from your own code instead, see how payment works below.

Command line

The @onchaindiligence/cli package is the fastest way to try the API. Some commands are free and need no key — run them straight from npx. --trust/--fetch-keys and offline-by-default verification require @onchaindiligence/cli@0.4.0 or later — check with npx @onchaindiligence/cli --version if a command below reports an unknown flag.

# check the API + upstream data sources
npx @onchaindiligence/cli health

# genuinely offline against caller-trusted key records
npx @onchaindiligence/cli verify result.json --trust keys.json

# is an attestation anchored on Tempo?
npx @onchaindiligence/cli anchored <signature>

verify exits 0 for VALID, 3 for INVALID, 4 for UNVERIFIABLE, and 2 for usage errors. Online discovery is available only with explicit --fetch-keys.

The paid checks settle a real per-call payment, so they read a funded payer key from the PAYER_KEY environment variable:

# a viem private key funded on the payment rail
export PAYER_KEY=0xYOUR_KEY

npx @onchaindiligence/cli screen 0x7f26…38E5
npx @onchaindiligence/cli screen-name "Vladimir Putin"
npx @onchaindiligence/cli company 00000006
npx @onchaindiligence/cli us-company AAPL
npx @onchaindiligence/cli diligence 0x7f26… 00000006

Add --json for raw output you can pipe into jq. Install globally with npm i -g @onchaindiligence/cli to get the onchaindiligence and ocd commands. Source: github.com/Qazza1/onchaindiligence-cli.

Sandbox / test mode

Build and CI-test your full integration — including a positive sanctions hit — without paying or touching production. Sandbox screening is free, takes no payment, and never calls the live oracle.

It lives on its own path, /sandbox/screen/:address, and only accepts the documented test-vector addresses below. A real address is deliberately refused, so you can never screen a real counterparty against test data by mistake.

# always SANCTIONED — test your block/deny path
GET /sandbox/screen/0x00000000000000000000000000000000000000ba

# always CLEAN — test your allow path
GET /sandbox/screen/0x00000000000000000000000000000000c1ea0000
GET /sandbox/screen/0x0000000000000000000000000000000000000001

# list the vectors any time
GET /sandbox

A sandbox response mirrors the shape of a real one so you can code against the same structure — but it is always flagged and never signed. The attestation block carries signed: false and sandbox: true with an explicit note, and the body carries "source": "sandbox". A sandbox result can never be mistaken for a real determination or pass verification.

{
  "data": {
    "address": "0x…ba",
    "sanctioned": true,
    "source": "sandbox"
  },
  "attestation": { "signed": false, "sandbox": true },
  "sandbox": true
}

Because it's free and deterministic, it drops straight into CI — assert that your code blocks the sanctioned vector and allows the clean one, on every build:

# the sanctioned vector must be blocked by your code
curl -s .../sandbox/screen/0x…ba | jq -e '.data.sanctioned == true'

# the clean vector must pass
curl -s .../sandbox/screen/0x…c1ea0000 | jq -e '.data.sanctioned == false'

When you're ready for real screening, switch the path from /sandbox/screen/:address to the production /screen/:address — same response shape, now paid and signed.

How payment works

Payment rides on the HTTP 402 standard over the Machine Payments Protocol (MPP). The exchange is three steps:

1 — Call with no payment

The server responds 402 Payment Required with a WWW-Authenticate: Payment header. The challenge encodes the amount, the stablecoin contract, the Tempo chain id, and the recipient.

HTTP/1.1 402 Payment Required
WWW-Authenticate: Payment id="...", method="tempo",
  intent="charge", request="<base64 challenge>"
Content-Type: application/problem+json

2 — Pay and retry

The client pays the requested stablecoin amount to the recipient on Tempo, then retries the same request with the payment proof attached in the Authorization header. The mppx CLI and SDK do this automatically.

3 — Get a signed result

The server verifies the payment, runs the check, and returns 200 OK with the result and an attestation. If the upstream data source is unreachable, the server returns 503 before requesting payment — you are never charged for a check that cannot complete.

2 · Action evidence

Overview

Beyond a simple payment, an agent's on-chain action can be a token approval, a swap, a cross-chain bridge, or a stake. Each of these has a dedicated preflight route on the MCP server (Base mainnet, x402): it validates the proposed action against your policy and returns a signed PREFLIGHT artifact before anything executes. A matching evidence check independently observes the on-chain settlement afterward and reports whether it matches what was preflighted — the same before/after distinction as payments.

These are MCP-surface tools, not routes on the api.onchaindiligence.com HTTP API documented above. See MCP server for the connection details.

ERC-20 allowance

Validates a proposed ERC20_ALLOWANCE action (network, token, spender, amount) against a caller policy before the agent submits an on-chain approve. Schema: onchaindiligence.erc20-allowance-action.v1.

Swap

Validates a proposed swap (input/output asset, amounts, router, recipient) on Base against policy before execution. Schema: onchaindiligence.swap-action.v1.

Bridge (Circle CCTP)

Validates a proposed Circle CCTP V2 bridge from Base to Ethereum mainnet (eip155:8453 → eip155:1) — source/destination network, asset, and amount bounds. Schema: onchaindiligence.bridge-action.v1.

Lido staking

Validates a proposed Lido stETH submit (stake) on Ethereum mainnet against policy before execution. Schema: onchaindiligence.staking-action.v1.

3 · Provider evidence

Executors & providers

The @onchaindiligence/sdk/commerce export includes provider-specific executor adapters, not six interchangeable payment rails. OCD evaluates policy and independently observes settlement; each executor's own authorization stays fully independent from OCD's decision — an OCD ALLOW never overrides a provider's own denial, and a provider approval never implies OCD ALLOW.

Provider claim vs. independent settlement. Turnkey, Crossmint, and Circle each deliver a provider-signed webhook that OCD verifies server-side — that authenticates who authored the claim, but it is still the provider’s claim, not settlement evidence. PayBox and CDP have no such webhook, so their executor instead submits a caller-reported claim to POST /operations/:operationId/provider-evidence. Every provider claim is recorded separately from OCD’s own independent chain observation, which is the only thing that confirms settlement. The distinction always travels with the record. See Provider evidence.

See the SDK coverage summary and the full executor documentation for integration details.

FLOP, Tempo MPP and Stripe MPP are not native commerce integrations here. Network settlement observation and the separate Evidence Provider billing protocol must not be read as executor support.

4 · Receipts & verification

Signed receipts

A receipt records what was decided (decision), what executed (execution), and what independently settled on-chain (settlement) — each reported separately, never merged into one summary judgment. Every check on this record resolves to one of three states:

Explore a real signed receipt at /r/OCD-RCP-NB51-QG4S-VCAN-Y57F or in the Explorer.

Reconciliation Ledger

The Reconciliation Ledger in your authenticated workspace lists payment activity and gives each item one operational status, with a reason. Every item links to its existing operation or transaction evidence. Declared intent and preflight, provider or executor claims, independent settlement and receipt proof stay separate in that evidence.

Scope. Counts and filters cover the current source page of activity, not workspace totals; older activity is on later pages. Wallet rows appear only for a wallet address you explicitly add, on a supported Wallet Evidence network, and only within the loaded, bounded range. They are not complete wallet history, and they don't establish wallet ownership or agent causation. Merchant fulfilment and refund entries are caller-reported claims, not proof of delivery or of money returned. Receipt proof VALID only means the signed receipt verifies. The Ledger is private to your workspace and creates no receipts or payments. Public and private evidence boundaries are unchanged: the Ledger adds nothing to public receipt pages, and the public MCP and A2A surfaces do not expose it.

Wallet Evidence

Wallet Evidence is a read-only view in the OnChainDiligence dashboard. For a wallet you choose, it shows recent activity in the supported payment asset and which of that activity is exactly linked to evidence already recorded in your authenticated workspace. It is not a portfolio: no balances, pricing, other tokens or complete wallet history.

1. Connect an EVM wallet, or paste an address.
2. Optionally verify wallet control with a read-only signature.
3. Choose Base, Tempo or Arc.
4. Select Check wallet activity. Nothing is scanned until you do: connecting, signing and choosing a network never start a read.
5. OCD correlates exact network + transaction hash pairs with evidence in your workspace.
6. Review each transfer as Agent-linked, OCD-linked, Saved receipt or Unlinked.
7. On Arc, you can explicitly search earlier bounded activity when the initial range does not contain the transaction you need. Nothing older is searched unless you ask.
8. For a supported transaction you have reviewed, you may choose Create signed receipt. Nothing is created until you do.

Compatible injected EVM wallets are discovered using standard browser-wallet interfaces (EIP-6963). When several are installed, OnChainDiligence asks which one to connect, and Disconnect wallet clears the connection locally. Wallet Evidence does not imply an endorsement of, or partnership with, any wallet vendor. Manual address lookup works without connecting or signing.

Block time differs by network, so the same block count covers different amounts of time. The dashboard always shows the block range it scanned. Loaded history is complete only within the stated loaded block range, not complete wallet history. A read that cannot finish returns an error, never a partial result presented as complete.

Create signed receipt. Viewing wallet activity remains read-only. When you select Create signed receipt on a supported transaction, OCD independently re-observes that exact network + transaction on-chain and creates a signed observation receipt, or returns the existing one for that transaction. It uses the same past-payment receipt system as Create a payment receipt. The receipt's policy decision is UNKNOWN unless a policy check was separately established. Creating a receipt does not prove wallet ownership, authorization of the payment, agent identity, provider identity or merchant delivery, and it does not require wallet-control verification.

Unlinked and a signed receipt can both be true. A transfer can correctly show Unlinked and Signed OCD receipt at the same time. Unlinked means there is no exact OCD operation or signed agent provenance associated with it. The signed receipt means OCD independently observed the completed transaction and signed that evidence. Creating a receipt never changes Unlinked into OCD-linked or Agent-linked.

Receipt for a payment that already happened

When a payment already happened without an OCD preflight, give OCD the network and transaction reference. OCD independently reads the chain and returns a signed COMMERCE receipt of what it could verify. Free, no account, no API key. Served by the MCP host, not the api subdomain:

curl -s -X POST https://mcp.onchaindiligence.com/observe-payment   -H "Content-Type: application/json"   -d '{"network":"eip155:8453","transaction_hash":"0x…"}'

Observation covers the supported canonical stablecoin on each network (USDC on Base, Ethereum and Solana; pathUSD on Tempo; USDC on Arc). On Arc (eip155:5042), OCD reads Arc's native USDC system Transfer stream at 18-decimal precision and requires the transaction's block to be at or below the finalized (committed) head; that stream is not an ordinary ERC-20 token contract.

Receipts are unlisted: they never appear in any public list or activity feed, but anyone with the exact receipt ID can retrieve and verify it. That is not private access. For a policy-bound receipt, run a preflight before your next payment.

Attestation

Every paid response includes a versioned attestation object. Version 2 signs RFC 8785 canonical JSON containing the exact data, timestamp, key ID, issuer, purpose, and schema version.

The exact key and its active, retired, revoked, or compromised status are published by key ID:

curl https://api.onchaindiligence.com/.well-known/attestation-keys

Offline verification

Verification has two modes, and the choice is always explicit — never a silent default.

The trust snapshot is the live key registry, unmodified

There is no separate offline key format to learn or convert. The key registry response at /.well-known/attestation-keys is already shaped exactly like the SDK's TrustedAttestationKeySet input ({ keys: [...], issuer, registry_version }) — save that JSON once while you have a connection, and pass the file straight to --trust later with zero transformation.

A real copy-paste flow

# obtain/save trusted public keys while online
curl -s https://api.onchaindiligence.com/.well-known/attestation-keys -o keys.json

# disconnect / disable network here if you want to prove it to yourself

# verify a saved result completely offline
npx @onchaindiligence/cli verify artifact.json --trust keys.json

Run against a free, real, signed fixture (GET /sandbox/attestation-sample — no counterparty screened, no payment) with the real published @onchaindiligence/cli@0.4.0:

✓ VALID  Attestation is valid under the supplied trust policy.
  key: ed25519-P2jIwhCn-Af6pTz4  code: valid

verify exits 0 for VALID, 3 for INVALID, 4 for UNVERIFIABLE, and 2 if you omit both --trust and --fetch-keys — there is no silent fallback path.

What VALID, INVALID, and UNVERIFIABLE establish

Signed evidence bundles

A bundle is a portable, signed package: a manifest, a set of existing evidence artifacts — receipts, attestations, allowance/swap/bridge/staking evidence — and a reconciliation summary, sealed together and verifiable completely offline. A bundle does not replace those artifacts or re-issue them; it packages ones that already exist so they travel as one file instead of several.

Bundle integrity and artifact verification are reported separately

Verifying a bundle answers two different questions, and the CLI and SDK keep them visibly distinct rather than collapsing them into one pass/fail:

Both use the same VALID / INVALID / UNVERIFIABLE states defined above. A bundle can be genuinely VALID at the manifest level while one artifact inside it is INVALID or UNVERIFIABLE — that distinction is the point, not an edge case to collapse away. An artifact of a family the verifier doesn't recognize is reported UNVERIFIABLE, never silently accepted as valid.

Reconciliation: agreements, contradictions, insufficient evidence

Where a bundle contains more than one artifact bearing on the same fact, its reconciliation summary separates three outcomes: agreements, contradictions, and insufficient_evidence. Evidence that is simply missing or unresolved is insufficient_evidence, not a contradiction — the two are never conflated.

SDK and CLI

import { verifyBundleOffline } from '@onchaindiligence/sdk'

const result = await verifyBundleOffline(bundle, trustMaterial)
// result.bundle_integrity  -> 'VALID' | 'INVALID' | 'UNVERIFIABLE'
// result.artifact_verifications -> per-artifact results, same tri-state

ocd verify bundle.json --trust keys.json

Bundle verification is offline-only by design — there is no --fetch-keys mode for a bundle, only --trust. Example output, produced by the published @onchaindiligence/cli@0.4.0 against a locally-assembled bundle:

✓ VALID  bundle integrity: VALID
  artifact sha256:PE__9LR3…: VALID
  artifact sha256:TUYpIKRQ…: VALID
  artifact sha256:cq76zr7N…: VALID
  artifact sha256:qWvhdY8M…: VALID
  reconciliation: none
  limitation: Bundle validity proves cryptographic integrity under the verifier contract only.

verify uses the same exit codes for a bundle as for a single attestation: 0 for VALID, 3 for INVALID, 4 for UNVERIFIABLE, 2 for a usage error.

Legacy key limitation

The key registry publishes an honest, machine-readable trust_warnings list and a strict_offline_verification_ready flag rather than asserting stronger guarantees than the historical record supports. As of this writing, one retired key has no recorded valid_from activation boundary — it was active before this registry began tracking exact activation times, and that boundary has not been invented to make it look known:

{
  "strict_offline_verification_ready": false,
  "trust_warnings": [
    "attestation key ed25519-D8wfc7civVNG05Ds has no valid_from activation boundary"
  ]
}

Anything signed with that key still verifies correctly — the signature, content, and its known valid_until upper bound all still apply. What's missing is a hard lower bound on when it started being trustworthy, so strict time-windowed verification of very old records signed with it cannot be fully bounded. Every key issued since — including the current active key — records a real, exact valid_from, so this specific gap does not recur going forward. Check trust_warnings on your own saved snapshot rather than assuming it is empty.

Legacy version 1 records

The manual snippet below is retained specifically for legacy version 1 attestations, which predate the domain-separated v2 signing input:

import crypto from 'node:crypto'

const input = JSON.stringify({
  data: envelope.data,
  issued_at: envelope.attestation.issued_at,
  key_id: envelope.attestation.key_id,
})

const ok = crypto.verify(
  null,
  Buffer.from(input),
  publicKeyPem,                  // from /.well-known/attestation-key
  Buffer.from(envelope.attestation.signature, 'base64url'),
)
// ok === true  ->  signature matches; issued_at is the signer's assertion

5 · MCP

MCP server

The checks and evidence types on this page are also exposed as a paid Model Context Protocol server, so an AI agent can discover them as tools and pay for them autonomously — no API key, no account. It is a live remote server over Streamable HTTP, listed in the official MCP Registry as com.onchaindiligence/compliance.

Connecting the server surfaces the checks and action-evidence preflights documented above as tools, each priced and payment-gated — the live server is the source of truth for the exact current tool list, since it changes as new evidence types ship.

How payment works

The MCP server settles with x402 — the open agent-payment standard built on HTTP 402. A tool call carries no payment on first attempt; the server returns the payment requirements, the agent signs a USDC authorization, and the call is retried with the payment attached. The server verifies and settles before running the check. The flow is non-custodial: payment goes directly from the agent's wallet to the recipient, and the server never holds funds.

Discovery

The server is published in the official MCP Registry, the canonical source that downstream MCP clients and marketplaces draw from. An agent that speaks x402 can find it, read its tool schemas, pay, and call — with no manual configuration.

6 · SDK

TypeScript SDK

@onchaindiligence/sdk wraps the HTTP API for typed calls, and its separate /commerce export is the client-side orchestration layer for the provider executors documented above: createCommerceClient opens an operation, preflight() evaluates policy, your executor's execute() authorizes and submits, and observeAndFinalize() independently observes what settled and reconciles it against what was declared and reported. Execute only when preflight is ready (an ALLOW decision), and treat pending and terminal-error as results to handle, not receipts.

import { createCommerceClient, apiPurchasePolicy, BASE_USDC } from '@onchaindiligence/sdk/commerce'
import { NodeFileRecoveryStore } from '@onchaindiligence/sdk/commerce/node'

// paidFetch: an x402-paying fetch (wrapFetchWithPayment) around your dedicated fee wallet -- the preflight costs $0.01
if (!process.env.OCD_API_KEY) throw new Error('Set OCD_API_KEY first')
const ocd = createCommerceClient({ preflightMode: 'paid', accountApiKey: process.env.OCD_API_KEY, recovery: new NodeFileRecoveryStore('./ocd-recovery'), fetch: paidFetch })
const { policy } = apiPurchasePolicy({ maxAmount: '1.00', allowedNetwork: 'eip155:8453', allowedAsset: BASE_USDC })
const op = await ocd.open({ action: proposedPayment, policy })

const preflight = await op.preflight()
if (preflight.kind !== 'ready') return handle(preflight)            // not ALLOW, or not settled yet: call no executor
const execution = await op.execute({ executor: myExecutor })
if (execution.kind !== 'execution-recorded') return resumeLater(execution) // never pay again on ambiguity
const finalized = await op.observeAndFinalize()
if (finalized.kind !== 'receipt-produced') return retryLater(finalized)  // pending or terminal-error

npm install @onchaindiligence/sdk@0.10.1 @x402/core @x402/evm @x402/fetch · Package on npm →. This excerpt remains the paid alternative: 0.01 USDC on Base, including BLOCK evaluations. The canonical onboarding checklist shows free mode first: authenticated Base/Solana USDC preflight, 100 completed evaluations per workspace per UTC month, no fee signer. On exhaustion, 429 free_allowance_exhausted never automatically switches to paid mode. The offline fixture is separate from both production modes.

SDK 0.10.1 forwards accountApiKey and supports explicit preflightMode: 'free'. Only documented payment flows are covered; installing a plugin does not intercept arbitrary payments. Use durable recovery for restarts; the plain withOcd wrapper does not have the proxy’s full stable purchase-attempt journal. Receipt proof VALID verifies integrity/authenticity, not settlement, payment authorization or merchant fulfilment. Auto-Evidence @onchaindiligence/auto-evidence-proxy@0.2.0-rc.0 is a published MIT prerelease under next; latest remains older. No successful production free-receipt or funded live proxy canary is claimed.

7 · Evidence Providers

The checks below are OnChainDiligence's Evidence Providers — sources of external, verifiable fact that the infrastructure signs and delivers. They are inputs to the product, documented here for completeness; they are not the product's identity.

Sanctions screen

Checks a single EVM wallet address for an exact match against the digital currency address identifiers on the U.S. Treasury OFAC SDN List, using a validated snapshot confirmed against OFAC within the last 6 hours. Returns match_status (listed / not_listed) with the dataset snapshot and limitations, signed and timestamped. SDN List only — not OFAC's non-SDN lists, EU, UN, UK or other regimes — and a non-match is not legal clearance. If the snapshot is not current the call answers 503 sanctions_screening_unavailable before payment, never a negative.

const r = await od.screen('0x7f26…38E5')
// or pass an ENS name: od.screen('vitalik.eth')

npx mppx https://api.onchaindiligence.com/screen/0x7f26…38E5

# MCP tool (Base / x402)
Tool: screen_wallet
Args: { "address": "0x7f26…38E5" }

{
  "data": {
    "address": "0x7f268357A8c2552623316e2562D90e642bB538E5",
    "match_status": "not_listed",
    "sanctioned": false,
    "matches": [],
    "screening": { "scope": "ofac_sdn_digital_currency_address", "dataset": { /* publication date, SHA-256, retrieved/revalidated */ }, "limitations": [ /* … */ ] },
    "source": "U.S. Treasury OFAC Specially Designated Nationals (SDN) List, SDN.XML (U.S. government data, public domain)",
    "checked_at": "2026-10-17T06:44:15.164Z"
  },
  "attestation": {
    "signed": true,
    "key_id": "ed25519-D8wfc7civVNG05Ds",
    "algorithm": "ed25519",
    "signature": "wFRfDRSiU5pMOG9y…yqHYfDQ"
  }
}

A listed address returns "match_status": "listed" with each matching SDN entry (sdn_uid, name, programs, listed value and entry URL). sanctioned is kept for compatibility and is true only when listed.

Counterparty verdict

Returns a single, signed decision — PASS or BLOCK — with human-readable reasons, rather than raw screening data for you to interpret. Built for agents that need to act, not analyse. Every response is signed with the same key as every other route, so the decision itself is verifiable.

This endpoint never returns a false PASS. If an upstream check fails, it returns an error rather than passing the address through.

npx mppx https://api.onchaindiligence.com/verdict/0x7f26…38E5

# unpaid requests return 402 with a payment challenge
curl https://api.onchaindiligence.com/verdict/0x7f26…38E5

{
  "data": {
    "verdict": "BLOCK",
    "reasons": [
      "Address is listed as a digital currency address on the OFAC SDN List (exact match; see signals.sanctions.matches)."
    ],
    "address": "0x8576acc5c05d6ce88f4e49bf65bdf0c62f91353c",
    "signals": {
      "sanctions": { "checked": true, "sanctioned": true },
      "direct_counterparty_exposure": {
        "checked": true,
        "transfers_scanned": 200,
        "counterparties_found": 112,
        "counterparties_screened": 25,
        "sanctioned_counterparties": [],
        "scope": "Direct (one-hop) counterparties observed on Tempo mainnet only…"
      }
    },
    "verdict_basis": {
      "live_signals": ["sanctions", "direct_counterparty_exposure"],
      "not_yet_evaluated": ["risk_score", "mixer_exposure", "wallet_age", "sanctions_proximity"],
      "note": "BLOCK = this address is sanctioned. WARN = it is not, but a direct counterparty is. PASS = neither, within the stated scope — not a full risk clearance."
    },
    "checked_at": "2026-07-07T14:22:08.441Z"
  },
  "attestation": {
    "signed": true,
    "key_id": "ed25519-D8wfc7civVNG05Ds",
    "algorithm": "ed25519",
    "signature": "UN4TzBvkRsf0eGm4…ZFyElhq1Cg"
  }
}

Three verdicts, and they mean different things. BLOCK means the address itself is sanctioned — a hard legal line. WARN means it is not sanctioned but transacted directly with an address that is: a counterparty risk signal, never a designation of the address you asked about. We do not designate by association. PASS means neither was found within the stated scope.

Read verdict_basis before you trust a PASS. live_signals lists the signals that actually ran for that request. If a signal could not be evaluated it is reported as not evaluated — never silently assumed clean — and the reasons say so explicitly. Direct counterparty exposure is deliberately narrow: one hop only (not a multi-hop proximity score), Tempo mainnet only (an address active elsewhere shows no counterparties here), and a bounded recent window. Those limits ride in signals.direct_counterparty_exposure.scope on every response. No sanctioned counterparty found does not mean none exists.

OFAC name screen

Screens a person or company name against the official U.S. Treasury OFAC Specially Designated Nationals (SDN) list — public-domain government data. Uses transparent fuzzy matching (token overlap + edit distance) against primary names and strong aliases, returning confidence-scored candidates. Weak AKAs are not screened, per OFAC guidance.

const r = await od.screenName('Vladimir Putin')
// optional: { threshold: 0.9 }

npx mppx 'https://api.onchaindiligence.com/screen-name?name=Vladimir Putin'

{
  "data": {
    "query": "Vladimir Putin",
    "hit": true,
    "matches": [
      {
        "ent_num": 306,
        "matched_name": "PUTIN, Vladimir Vladimirovich",
        "matched_on": "primary",
        "program": "RUSSIA-EO14024",
        "score": 0.9
      }
    ],
    "threshold": 0.85,
    "source": "U.S. Treasury OFAC SDN list (public domain)"
  },
  "attestation": { "signed": true, … }
}

Company check

Looks up a UK company by its registration number: status, type, incorporation date, registered address, and the people with significant control (PSC) behind it.

const r = await od.verifyCompany('00000006')

npx mppx https://api.onchaindiligence.com/company/00000006

# MCP tool (Base / x402)
Tool: verify_uk_company
Args: { "companyNumber": "00000006" }

{
  "data": {
    "profile": {
      "companyNumber": "00000006",
      "companyName": "MARINE AND GENERAL MUTUAL LIFE ASSURANCE SOCIETY",
      "status": "dissolved",
      "incorporatedOn": "1862-10-25",
      "registeredAddress": "Cms Cameron Mckenna Llp Cannon Place, London, EC4N 6AF"
    },
    "pscList": [],
    "source": "UK Companies House (open government data)"
  },
  "attestation": { "signed": true, "key_id": "ed25519-D8wfc7civVNG05Ds", … }
}

US company check

Looks up an SEC-registered US public company via EDGAR by ticker, CIK, or name: registered entity, CIK, industry (SIC), state of incorporation, exchanges, business address, and most recent filing. Covers public companies and funds only — private US companies register at the state level and are not in EDGAR, so the result carries an explicit coverage note.

const r = await od.verifyUSCompany('AAPL')

npx mppx https://api.onchaindiligence.com/us-company?q=AAPL

# MCP tool (Base / x402)
Tool: verify_us_company
Args: { "query": "AAPL" }

{
  "data": {
    "source": "SEC EDGAR",
    "cik": "0000320193",
    "name": "Apple Inc.",
    "sic_description": "Electronic Computers",
    "state_of_incorporation": "CA",
    "exchanges": ["Nasdaq"],
    "latest_filing": { "form": "4", "filing_date": "2026-06-17" },
    "coverage_note": "EDGAR covers SEC-registered (public) companies only…"
  },
  "attestation": { "signed": true, "key_id": "ed25519-D8wfc7civVNG05Ds", … }
}

Combined diligence

Runs both checks in one call, in parallel. Returns independent results plus an explicit disclaimer that no link between the wallet and the company is established by the data.

const r = await od.diligence({
  wallet: '0x7f26…38E5',
  company: '00000006',
})

npx mppx 'https://api.onchaindiligence.com/diligence?wallet=0x7f26…38E5&company=00000006'

# MCP tool (Base / x402)
Tool: diligence
Args: { "wallet": "0x7f26…38E5", "company": "00000006" }

{
  "data": {
    "wallet_check": { "sanctioned": false, … },
    "company_check": { "profile": { … } },
    "link_disclaimer": "These are independent checks against separate data sources. No verified link between the wallet and the company is established by this data."
  },
  "attestation": { "signed": true, … }
}

8 · Anchoring

On-chain anchoring

Any signed attestation can be anchored on Tempo mainnet for an immutable, timestamped, tamper-evident record that a check happened. Only the keccak256 hash of the attestation signature is written on-chain — never the wallet, name, company, or result — so records stay private while remaining provable by anyone. Anchoring is decoupled from checks: it never blocks or delays a paid response.

Cryptographically verifies the complete v2 attestation envelope before anchoring its signature hash. Pass the original { data, attestation } response. Idempotent — re-anchoring sends no new transaction.

await od.anchor(r)

POST /anchor
{ "data": { … }, "attestation": { "signed": true, "schema_version": "onchaindiligence.attestation.v2", … } }

Checks whether an attestation has been anchored on-chain, and when — so anyone can verify a record independently.

{
  "anchor_hash": "0xadb12c9f…401d",
  "anchored": true,
  "anchored_at": "2026-06-24T14:44:21.000Z",
  "chain": "Tempo",
  "network": "mainnet",
  "contract": "0xDe47…ea14"
}

9 · Reference infrastructure

Discovery & health

These endpoints are free and require no payment — they describe the service and report its status for humans and machines.

Reports whether each upstream data source is reachable and whether response signing is configured. Returns 200 when healthy and 503 when any upstream is degraded, so automated monitors can key off the status code.

{
  "status": "ok",
  "upstreams": {
    "sanctions_oracle": "reachable",
    "companies_house": "reachable",
    "sec_edgar": "reachable"
  },
  "attestation": "configured"
}

Service information: the routes, prices, and attestation key URL.

A complete, machine-readable OpenAPI 3.1 document describing every route, parameter, response schema, and the per-call payment terms — for automatic agent and tooling discovery.

Errors

Errors use standard HTTP status codes. Bad input is rejected before any payment is requested.

Rate limits

Requests are rate limited per client. When you exceed the limit the API returns 429 with a Retry-After header and an X-RateLimit-Remaining count on every response. Back off and retry after the indicated interval.

The full source for the HTTP API, MCP server, SDK, and anchoring contract lives on GitHub.