AI agents transacting with other agents need to answer one question before moving funds: can I trust this wallet? The existing attestation endpoint can answer it, but the agent needs to know what to check and construct conditions manually. A new dedicated endpoint sends only a wallet address and gets back a structured, ECDSA-signed on-chain fact profile. No score, no opinion. Just cryptographically verifiable evidence organized by dimension.

The problem with ad-hoc wallet assessment

When an AI agent encounters an unfamiliar wallet, it has limited options. It can check a single token. It can run multiple attestation calls, each consuming a credit and requiring the agent to know which contracts and chains to query. Or it can skip verification entirely and accept the risk.

None of these are good defaults for autonomous systems. An agent performing wallet verification should not need to know that USDC on Ethereum is at 0xA0b8...eB48 with 6 decimals, or that governance participation is best measured through UNI, AAVE, ARB, and OP holdings. That is domain knowledge the infrastructure should encode.

DJD Agent Score already demonstrated this pattern. It uses InsumerAPI attestations as a cold-start identity signal for AI agent wallets in the Coinbase x402 ecosystem. But DJD had to build its own condition set and orchestration layer on top of the attestation endpoint. The trust endpoint productizes that pattern as a first-class API call, providing a structured input for the three layers of trust that agent payment systems require.

What the trust endpoint does

POST /v1/trust takes a wallet address and returns a structured fact profile across four dimensions:

If a Solana wallet is also provided, an 18th check adds USDC on Solana to the stablecoins dimension.

Every check uses balance > 0. The question is "does this wallet have X?" not "how much?" This is presence detection, not portfolio analysis. The response never reveals actual balances.

Dimensions, not scores

The response organizes results into dimensions with per-dimension pass/fail counts and an overall summary. A wallet might pass 7/7 on stablecoins, 3/4 on governance, and 0/3 on NFTs. The consuming agent sees this structure and decides what it means for its use case.

This is a deliberate design choice. InsumerAPI stays in the evidence layer. Scoring, weighting, and thresholds belong to the application. A lending agent cares about stablecoins. A DAO membership tool cares about governance. An NFT marketplace cares about blue-chip holdings. The same fact profile serves all three without the API making assumptions about what matters.

Cryptographic guarantees

The entire trust profile is ECDSA P-256 signed. The signature covers the trust object including all dimensions, all checks, the wallet address, the condition set version, and the profile timestamp. Each individual check includes an evaluatedCondition and conditionHash (SHA-256), making the profile tamper-evident at the condition level.

For RPC chains, each check also includes blockNumber and blockTimestamp, so the consuming agent can verify freshness. The profile expires after 30 minutes, matching the existing attestation TTL.

Optionally, pass proof: "merkle" to include EIP-1186 Merkle storage proofs on stablecoin and governance checks. This lets the consuming agent verify results against public block headers without trusting InsumerAPI at all. Merkle proof mode costs 6 credits ($0.24) instead of 3 credits ($0.12).

What the response looks like

A trust profile for a well-known wallet returns something like:

The ID format is TRST-XXXXX (five hex characters), distinguishing trust profiles from attestations (ATST) and verification codes (INSR). The condition set is versioned as v1, allowing future expansion without breaking existing integrations.

Integration across all four SDKs

The trust endpoint is available everywhere InsumerAPI is available:

For MCP and LangChain integrations, the agent simply calls the trust tool with a wallet address. No need to construct conditions, look up contract addresses, or manage chain IDs. One call, one structured response.

When to use trust vs. attest

The two endpoints serve different needs:

Use attest when you know exactly what you need to verify. Use trust when you need a comprehensive profile without domain expertise about which contracts and chains to check.

Batch profiling: 10 wallets, one call

Agents rarely need to profile a single wallet. A portfolio rebalancer evaluates counterparties. A DAO tool checks a voter list. A compliance agent screens a batch of addresses. Making 10 sequential POST /v1/trust calls means 10 separate block-number fetches across 7 chains — 70+ RPC round-trips.

POST /v1/trust/batch eliminates that overhead. Send up to 10 wallets in one request. Block numbers are fetched once and shared across all wallets, then each wallet is evaluated in parallel. The result is 5–8× faster than sequential calls.

The batch endpoint supports partial success. If 8 of 10 wallets succeed and 2 fail (e.g., RPC timeout on one chain), you get 8 full profiles and 2 error entries. Credits are only charged for successful profiles. Each successful profile gets its own ECDSA signature, independently verifiable with insumer-verify.

Same pricing: 3 credits per successful wallet (standard) or 6 per wallet with Merkle proofs. The entire batch counts as 1 request toward the daily rate limit.

Evidence, not opinion

The trust endpoint returns facts. It does not return a score, a rating, or a recommendation. A wallet that passes 0/36 checks is not "bad." It might be new, it might hold assets not in the curated set, or it might deliberately hold nothing on the checked chains. The response is a signal, not a verdict.

This separation matters for autonomous agents. As the WEF trust requirements make clear, an agent making a financial decision should reason about the evidence in its own context, not defer to an API's judgment. The trust endpoint gives the agent structured inputs. What it does with them is up to the agent's own logic.

Try the trust endpoint

InsumerAPI is free to start. 10 credits included. Profile a single wallet with POST /v1/trust or batch up to 10 with POST /v1/trust/batch.

View Trust Docs