DEV Community: Douglas Borthwick

What a Wallet Can Prove: Every InsumerAPI Condition Type, With Why It Exists

Douglas Borthwick — Wed, 02 Sep 2026 01:16:22 +0000

Every condition type InsumerAPI evaluates, what comes back in the signed bytes, what a verifier recomputes, and why each design choice was made. Longer than usual, because the surface has grown.

The primitive has not changed: read wallet state, evaluate conditions, return a signed boolean. What has changed is the range of conditions, the two output formats, the proofs you can attach, and, since the first of September, a second signature beside the first. This is the reference walk-through I would want if I were integrating today. Requests and responses are shown in the shape the API emits; every number here is checked against the running system.

The request shape, and the one rule people trip on

One call, POST /v1/attest, one wallet, one to ten conditions, each with its own chain. The response is a signed attestation: an id, an aggregate pass, per-condition results, and timestamps, with the signature and key identifier beside it.

POST https://api.insumermodel.com/v1/attest
X-API-Key: insr_live_...

{
  "wallet": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045",
  "conditions": [
    { "type": "token_balance", "chainId": 1,
      "contractAddress": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
      "threshold": "1000" }
  ]
}

The rule: quantities are decimal strings. "threshold": "1000", never 1000. Every key issued since June signs a canonical, domain-separated payload in which a string quantity is exact to any precision and serializes identically in every runtime; a JSON number is rejected with a 400. The same holds for the ratio fields below. The one deliberate exception is nft_ownership, whose threshold is the number zero, because it is a presence check and always has been.

What is inside the signed bytes

Each result carries the exact predicate that was evaluated, as evaluatedCondition, and a conditionHash, the SHA-256 of its canonical form. It also carries the chain anchor: blockNumber and blockTimestamp on EVM chains, a ledger index and hash on XRPL and Stellar, a block height and hash on Bitcoin and Tron, a slot on Solana, a checkpoint on Sui. The anchor shape differs by family on purpose, and a verifier that assumes blockNumber finds no anchor on a Bitcoin result. All of it is inside the signature. The expiresAt field is beside the signed payload, not inside it, which is why the spec's verification procedure binds it to the signed attestedAt (an expiresAt further than the issuance window from attestedAt can only have been edited after signing).

That combination, predicate plus hash plus anchor, is the recompute basis. It is what lets anyone re-run the read against any node and compare, which is the property everything else in this guide depends on.

The nine condition types

1. token_balance

Does the wallet hold at least the threshold of a token? Thirty-eight chains: thirty-two EVM plus Solana, XRPL, Bitcoin, Tron, Stellar and Sui. Use "contractAddress": "native" for the chain's own asset. On XRPL the same type covers issued currencies and trust lines, and the result surfaces whether the line is frozen. Why it exists in this shape: the balance itself is never returned, only the boolean, and the threshold travels as a string so the verdict is reproducible to the last decimal.

2. nft_ownership

Does the wallet hold at least one of a collection? Thirty-four chains: the EVM set plus Solana and XRPL. Bitcoin, Tron, Stellar and Sui are balance-only. Why: presence is the question, so the threshold is fixed at zero and the verdict is the cleanest possible boolean.

3. eas_attestation

Does an attestation exist for this wallet on the Ethereum Attestation Service, on any of six chains, matching a schema? Five templates cover the common cases: coinbase_verified_account, coinbase_verified_country, coinbase_one, gitcoin_passport_score and gitcoin_passport_active; any raw schemaId works too. Why: it lets a condition say "cleared a regulated exchange's checks" or "cleared a humanity score" without the caller ever handling a document. The attestation was issued elsewhere; the verdict says it exists.

4. farcaster_id

Does this address own a Farcaster account? Read from the identity registry on Optimism. Why: it is the one social identity that lives on-chain and can therefore be a condition rather than an API call to a platform.

5. evm_view_call

Call any view function on a supported EVM chain that takes a single address and returns a boolean, named by a canonical selector of the form functionName(address). The result is met when the function returns true; a revert is a signed false, not an error. Why: every contract that already encodes membership, allowlisting, delegation or voting rights becomes a gate with no new deployment, and the reproduction procedure is stated in the spec so anyone can re-issue the call.

6. ratio_to_amount

Met when balance is at least multiple times amount, both decimal strings. The derived threshold, computed with a ceiling so the gate errs toward strictness, travels inside evaluatedCondition. Why: "hold ten times what you are about to spend" is one rule that needs no retuning across chains, prices or transaction sizes. EVM chains with direct RPC access.

7. ratio_to_supply

Met when balance divided by totalSupply() is at least minFraction, a decimal string in the open-closed interval up to 1. The raw supply read is a sibling of evaluatedCondition, inside the signed payload but outside the condition hash, so a verifier re-reads balance and supply at the pinned block and re-derives the boolean exactly. Why: share of supply is the honest measure of stake for governance and project tokens; it is meaningless for stablecoins, and we say so.

8. erc8004_agent

Is this wallet the owner of, or the signature-bound agent wallet for, agent agentId in the ERC-8004 identity registry on Base? The result carries agentExists and matchedVia (owner, agent_wallet or none). Why the scope note is in the signed bytes: registration is permissionless minting. The verdict states registration and binding, and implies no vetting, no reputation and no endorsement. Merkle proofs are not offered for this type.

9. erc7710_delegation

Given a delegation object the caller already holds, is it currently valid for this wallet as delegate? Met when: the EIP-712 signature verifies (an EOA signature or an ERC-1271 smart-contract assertion, and the result names which, because those are different claims), the declared delegator matches expectedDelegator, the delegation is not revoked as of the anchored block, every caveat uses a recognized enforcer, and any time-window caveat is open. Managers must be a recognized delegation framework deployment on Base; root authority only; up to sixteen caveats; up to three delegation conditions per request.

Two design points worth understanding. First, declaredLimits: the decoded caveat terms (timestamps, ERC-20 and native spend ceilings, allowed targets, call counts) are reported, not simulated. They sit inside the signed results but outside conditionHash, as a sibling of evaluatedCondition, because the caller submitted those bytes itself and can re-decode them with no external lookup; on-chain redemption enforces them. Second, failReason distinguishes delegate_mismatch, principal_mismatch, invalid_signature, delegator_not_deployed, revoked, unknown_caveat_enforcer and outside_time_window, and delegator_not_deployed is its own reason because no signature was evaluated when the principal has no code on chain yet. Delegation verdicts expire in five minutes, not thirty, because revocation is one transaction away. If the attestation will be forwarded, "declaredLimits": "omit" keeps the principal's ceiling out of it; met and the hashes are byte-identical either way.

Proof mode

Add "proof": "merkle" and a balance condition carries an EIP-1186 storage proof of the balance slot; a delegation condition carries a proof of the revocation slot, tagged subject: "delegation_revocation" with the contract address, mapping slot and storage key alongside the standard account and storage proofs. Verify it against the block header's state root from any header source. For revocation: recompute storageKey = keccak256(abi.encode(delegationHash, mappingSlot)) from the delegationHash in the signed evaluatedCondition first, because that is what binds the proof to this delegation, then read the proven value, where 1 is revoked and 0 is a positive proof that no revocation exists. Proof mode anchors a few blocks behind the tip on purpose, since the state trie is not reliably retrievable at the tip, and the verdict and the proof always describe the same block. It costs two credits instead of one, and on a balance condition it reveals the raw balance, so it trades privacy for trustlessness by explicit choice. If a proof cannot be produced for a transient reason, the premium is refunded and the call costs one.

JWT format

Add "format": "jwt" and the response also carries a standard ES256 JWT with the same verdict, verifiable by any JWT library against the published JWKS with no SDK. The claims: pass, the condition hashes, the block anchor, the results, issuer, subject (the wallet), jti (the attestation id), iat and exp. Why both formats: the raw form is the canonical artifact with the exact signed bytes; the JWT is what an API gateway, a WordPress plugin or an edge worker can check with tooling it already has.

Fact profiles

POST /v1/trust runs a curated set against one wallet: forty-four base checks across twenty-five chains in five dimensions (stablecoins, governance tokens, NFTs, staking, institutional stablecoins), up to forty-nine checks across twenty-seven chains in nine dimensions with the optional Solana, XRPL, Bitcoin and Tron wallets. The whole profile is signed as one object. No score, no opinion, just cryptographically verifiable evidence organized by dimension. POST /v1/trust/batch profiles up to ten wallets in one call, fetching block numbers once, with each profile independently signed. Three credits per profile, six with proofs.

Paying without a key

Every attest and trust call is also reachable with no API key at all via x402 on Base, paid in USDC per call: five cents for an attestation, ten with a proof, fifteen for a profile, thirty with proofs. The invariant, stated exactly: the payer is charged only for a successful answer, and the payer sees the answer only after the payment settled. Evaluation failure means no payment; settlement failure means no response; settlement success means payment, response and the settlement transaction hash in-band so the payment itself is independently checkable. For keyed access there are three paths: POST /v1/keys/create for the email free tier (10 free verifications plus 100 reads/day), POST /v1/keys/buy on-chain, and POST /v1/credits/buy to top up. Prepaid starts at four cents a call.

Verification: five independent verdicts

The reference verifier is insumer-verify on npm, zero required dependencies, Web Crypto only, and it never collapses its answer into one boolean. It reports five verdicts and lets you decide what each means for you:

Signature. Resolve the key by the kid on the response from the JWKS; an unresolvable kid fails closed rather than falling back to the first key. Rebuild the exact preimage the kid selects and verify ECDSA P-256 over it.
Condition hashes. Canonicalize each evaluatedCondition, hash it, compare.
Freshness. Compare the signed blockTimestamp to your own maximum age. The window is yours to set: a checkout wants seconds, an auditor wants none.
Expiry. Bound expiresAt to the signed attestedAt plus the issuance window, then compare to now.
Post-quantum companion. New, and covered next.

The point of separating them is that "valid" is a policy, and the policy belongs to the relying party. An attestation records that a wallet met a condition at a named block, and that does not decay. The expiry is a freshness policy for access decisions, not a statement about whether the verdict was correct.

The post-quantum companion

Since the first of September, every attest and trust response carries a second signature beside the first: pqSig and pqKid on the raw form, and a sibling pqJwt on the JWT form. The algorithm is ML-DSA-65 under FIPS 204. The public key is published in the same JWKS as RFC 9964 AKP entries under the kids insumer-attest-pq1 and insumer-trust-pq1, appended after the three EC entries so that any verifier still falling back to the first key keeps a classical one.

The design is additive, and that word is doing work. sig, kid, jwt, every preimage and every existing key are byte-for-byte unchanged. The companion signs the post-quantum domain tag plus the exact classical preimage the response's kid selects, so no new canonicalization was introduced and the v1 and v2 eras are covered identically. The pqJwt is its own compact JWS with the same claims as jwt, and the verifier binds it to the classical token by jti, exp and pass, so a companion cannot be transplanted from another artifact. Before any of it was published we ran the previous release of the verifier against live responses to confirm it returned identical verdicts with and without the new fields.

The binding between the classical key and the post-quantum key is a content-addressed statement at /.well-known/pq-key-binding.json, signed by both keys and anchored on Base in block 50758053. Its block time is the public record of when the companion came into existence, which is what lets a verifier reading an old artifact say, truthfully, that no companion could have existed when it was issued.

The fifth verdict has four states: verified, refuted (present and failing), absent, and unverifiable (present but not checkable, because the key could not be resolved or the runtime has no ML-DSA implementation). The rules: refuted always fails the artifact. Absent or unverifiable fail only under your own pqRequiredFrom cutoff, judged by your clock at verification time and never by any timestamp inside the artifact, because under a classical break every one of those timestamps is forgeable. In mode: "evidence", for reading an artifact after the fact, nothing is refused; the verifier reports the state and, given the anchored binding date, whether a companion existed at issuance.

import { verifyAttestation } from "insumer-verify";

// A live access decision: from this date, insist on the companion.
const r = await verifyAttestation(response, {
  jwksUrl: "https://insumermodel.com/.well-known/jwks.json",
  pqRequiredFrom: "2027-06-01T00:00:00Z",
});
r.checks.pq.status; // "verified" | "refuted" | "absent" | "unverifiable"

// Reading a receipt years later: never refused, always explained.
const e = await verifyAttestation(response, {
  jwksUrl, mode: "evidence", pqActivatedAt: bindingBlockTime,
});
e.checks.pq.existedAtIssuance; // false for anything issued before the binding

ML-DSA is not in Web Crypto yet, so the verifier loads it from an optional dependency and reports unverifiable with a reason when it is missing, never a silent pass and never a silent failure. A PHP verifier can do the same through OpenSSL 3.5 or later on PHP 8.4 or later, and SkyeMeta's plugins do exactly that, probing the host with a real vector at activation and saying plainly when the host cannot.

Test vectors and the multi-issuer envelope

Seventeen published vectors at /.well-known/state-attestation-test-vectors.json, mirrored from the insumer-examples repository, which is the authority if the two ever differ. Eleven cover the classical checks, tampered conditions, tampered signatures and an unresolvable kid. Six cover the companion: both key eras verified, a tampered companion refuted, an unresolvable pqKid under a cutoff, a pre-companion artifact under a cutoff, and the JWT envelope. Each carries a recompute block with the canonical condition, its hash, and the anchor, and states its expected verdicts as separate booleans rather than one. Anyone can run the whole set against any node without anything from us, which is why a run is the runner's to publish.

For stacks that carry attestations from several issuers, the same repository holds a multi-attestation envelope spec and a reference verifier: each slot keeps its own issuer's signature and key identifier, the envelope is transport rather than trust, and the aggregate is recomputed from the slot verdicts plus pinned options. Eight envelope fixtures pin the behaviour, including the two cases that matter most, a slot with its signature stripped and an object stapled beside a JWS that bears no signature at all.

Where it plugs in

Forty-six operations in the OpenAPI spec. An MCP server with twenty-seven tools, a LangChain toolkit with twenty-six, LlamaIndex tools, ElizaOS actions, a ChatGPT action, and the insumer-verify package for the checking side. On the product side, SkyeMeta's SkyeGate and SkyeWoo plugins and SkyeMeta's Vercel SDK consume the JWT format and now report the companion too. None of that is new surface; it is the same primitive packaged for wherever your code already lives.

What to take from this

If you integrate one thing, integrate the verifier and read its five verdicts instead of one boolean. If you integrate two, add a delegation condition in front of anything an agent can spend. And if you keep attestations as evidence, keep the whole envelope: the block, the condition, the hash and both signatures are what make it worth keeping.

Conditions in. Signed attestations out. That has not changed. The list of conditions has.

Douglas

Originally published at insumermodel.com.

What Is Wallet Attestation in the UCP Spec?

Douglas Borthwick — Fri, 28 Aug 2026 17:43:01 +0000

The Universal Commerce Protocol release of 25 August 2026 uses the phrase “wallet attestation” in its normative text. It never defines it. If you went looking for what it means and found nothing, this is that page — what the reserved slot is, how it got into the spec, and what would go in it.

What the spec actually says

Two places, both in the identity linking capability. The first is the schema, on the provider definition in identity_linking.json:

A trusted identity provider for delegated authentication, keyed by the
'type' discriminator. 'oauth2' denotes an OAuth 2.0 / OIDC authorization
server. Future versions MAY define additional types (e.g. wallet
attestation) as non-breaking extensions; platforms MUST treat entries
whose 'type' they do not support as filtered out (see Provider Selection).

The second is the Future Extensibility section of the identity linking specification, which describes provider.type as “a required, open string” where oauth2 is the only type defined in this version, and which “reserves space for future types — wallet attestation, verifiable credentials, or other proof-of-identity protocols.”

Read that precisely, because the precision is the interesting part. The slot is reserved, not filled. No platform is obliged to support wallet attestation, and verifiable credentials are named in the same sentence. What the spec does commit to is the mechanics of extension: type is an open string rather than a closed enum, so an unrecognised value validates instead of failing, and a platform that does not understand a provider entry must filter it out rather than reject the whole profile.

What wallet attestation is

It is a way to answer a question about a buyer without learning who they are. A verifier reads public blockchain state at a specific block, evaluates a condition the business defined, and returns a signed boolean. Not a balance, not an address, not a profile — a yes or no, with a signature over the condition that was evaluated.

The reason it fits beside OAuth rather than against it is that the four operations an identity system has to perform are already native to chain state:

Issuance is a chain mutation. Someone minted, was granted, or bought the asset.
Consent splits in two, and the distinction is worth being exact about. The durable half — I chose to hold this, and still do — is the on-chain act itself. The per-transaction half — I am choosing to show you, now — is the presentation: connecting a wallet, showing a code, tapping a tag. Possession on its own is not consent to disclose, so it is the presentation that carries that, never the holding. OAuth collapses both into one consent screen; here they are separate, and only the second is per-transaction.
Revocation is a chain mutation too. Burn it, transfer it, drop below the threshold, and the next evaluation returns false on its own.
Verification is a read of current state, signed, checkable offline against a published key set.

OAuth builds consent screens, token expiry, revocation lists and introspection endpoints to approximate those four things for account systems, and it does that well. The point is not that one replaces the other. It is that when the fact you need is already on a public ledger, you can read it directly, and the business never has to hold a session, host a consent page, or store anything about the person.

When you would reach for it

The shape is useful whenever a business needs to act on a fact about a buyer that it should not have to store, and that the buyer should not have to prove by logging in.

Member pricing an agent can act on. A shopping agent is completing a checkout on someone’s behalf. The business offers a better price to holders of a particular pass. Without something like this, the agent has to drive an account login it does not have, or the business has to trust an unverifiable assertion from the agent. With it, the business asks one question and gets a signed answer it can keep as evidence of why it applied the price.

Eligibility that currently requires an account. Student, alumni, union, employee, early-supporter, season-ticket — these are all facts that exist somewhere, and the usual way to check them is to make the person create yet another account, or to trust a photograph of a card. Where the underlying credential already lives on a chain, checking it is a read rather than an onboarding flow.

Shareholder perks an agent could actually use. Issuers have offered benefits to their own shareholders for decades — onboard credit, product discounts, meeting access — and the way you claim one is still to email a brokerage statement to somebody and wait. Tokenised equity does not change what is on offer; it changes what is checkable, because a holding becomes a ledger entry a business can evaluate the same way it evaluates any other wallet condition. The moment that stops being hypothetical is an agent completing a purchase on behalf of someone who holds the issuer’s stock, and wanting the holder’s price. The issuing side of that is being built now, by exchanges and registrars. Reading a holding at a checkout is a different question, and it is the one this mechanism answers — which is what we wrote about when an exchange pitched issuers on shareholder rewards and the register had no way to see the share.

Recognition across businesses that share nothing. A community issues one pass. Twenty independent shops honour it. None of them holds a customer list, none of them integrates with the others, and the community can add or remove members without telling any of them. Each business evaluates the same public fact independently.

Revocation that is actually current. A lapsed membership is the awkward case for token-based access, because a token issued last year says nothing about today. Here the check reads present state at a block: if the asset moved, was burned, or fell below the threshold, the next evaluation returns false with no revocation list to publish and no stale-token window to reason about.

And the boundary, because it matters as much as the cases: if the fact you need is not on a chain, this is the wrong instrument. It answers questions about wallet state. It does not tell you someone’s name, that they are over eighteen, or that they are who they claim to be, and no amount of signing makes it do so. For those, the spec reserved room for other mechanisms in the same sentence, which is the right outcome.

Compared with the alternatives

It is not better than the other mechanisms. It is better at one specific question — does this buyer’s wallet satisfy this condition right now — and worse at most others. The useful comparison is what each one costs you.

Against an account login. OAuth is the right answer when the fact lives in your database or an identity provider’s, and it is far better than this at anything involving a person’s profile. Agents can use it perfectly well, too — that is exactly what UCP’s identity linking capability is for, and the August release describes agents negotiating identity providers on a buyer’s behalf. What OAuth needs is that a human consented at some point. The consent screen is a human moment by design, and everything afterwards runs on the strength of it, which is a feature rather than a defect. It does mean the first encounter between a buyer and a business contains a person-shaped step. A wallet condition has no prior relationship to establish: the buyer already holds the thing, and the business reads whether they still do.

Against verifiable credentials. These are stronger wherever an authority has to vouch for something about a person — age, qualification, residency. The cost is an ecosystem: an issuer willing to issue, holder software, a status mechanism for revocation. When the fact is already a public ledger entry, that machinery is doing work the chain has already done.

Against calling a partner’s API. A lookup is fine when the partner owns the data. It leaves you with a live dependency, a bilateral integration per partner, and a partner who learns every question you ask. Chain state is readable by everyone independently, so twenty businesses can check the same fact without any of them integrating with each other or with the issuer.

Against a card, a code, or a screenshot. No contest, and this is the honest baseline for most in-person eligibility today. Those are trivially forged and leave no evidence afterwards. A signed result is checkable later by someone who trusts neither party.

Where it loses is worth being just as plain about. The fact has to be on a chain. It establishes nothing about identity, age or personhood. It requires the buyer to hold and present a wallet, which is a real adoption cost. And it is not privacy for the underlying fact — the ledger is public — it is privacy in what the business ends up holding, which is a boolean and a signature rather than an address or a balance.

How it got into the spec

Through review, which is how vocabulary usually enters a specification.

On 15 March 2026 we proposed the mechanism and its literal shape in the discussion thread on UCP issue #265 — a provider type of wallet_attestation carrying a provider_jwks URL, contributing no scopes and issuing no token. On 18 March a UCP maintainer quoted that block back into the thread. Both comments are public.

What happened next was not ours. In PR #354, which merged on 6 May 2026, the identity linking foundation established config.providers with a type discriminator and reserved room for non-OAuth mechanisms. In PR #423, merged 12 June, the maintainer made that extension structural rather than merely documented: type became an open string, each mechanism got its own conditional requirements, and unrecognised types were defined as filtered rather than rejected. We had argued for a different structure in that review and were overruled, correctly — the shape that shipped extends more cleanly than the one we proposed.

The release of 25 August carried that reservation into published normative text. Our own proposal for the concrete mechanism, PR #415, is open and unmerged. It is a proposal, not a standard, and this page is not claiming otherwise.

What a provider entry looks like

Inside the identity linking capability config, providers are keyed by reverse-domain name:

"config": {
"providers": {
"com.example.walletauth": [
{
"type": "wallet_attestation",
"provider_jwks": "https://api.example.com/.well-known/jwks.json"
}
]
}
}

Because type is an open string and the provider object permits additional properties, an entry like this validates against the released schema as published. A platform that supports the mechanism resolves the key set and verifies attestations against it. A platform that does not filters the entry out and carries on with whatever else is advertised. Neither one breaks, which is what the forward-compatibility rule is for.

The verification itself is ordinary: fetch the key set, verify the ES256 signature, and check the hash of the condition that was evaluated so you know which question was answered. No callback to the issuer, no shared secret, nothing that expires in a drawer.

What this is not

It is worth being blunt about the limits, because they are checkable and you would find them anyway.

UCP has not adopted wallet attestation. It reserved a slot and named it as one candidate.
Verifiable credentials are named alongside it in the same sentence. Nothing privileges one over the other.
oauth2 remains the only provider type defined in the current version.
Our proposal for the concrete mechanism is open, not merged.

What is durable is smaller and more useful than an adoption claim: the extension point exists in released normative text, it names the mechanism, the mechanics of adding a type are specified, and a conforming entry can be written today. If you are building on UCP identity linking and want the wallet-state question answered without taking custody of an identity, that is the shape it takes.

Whether this becomes how agentic commerce checks eligibility, or one option among several, is not something this page can tell you — the slot is reserved and nothing is settled. For the wider argument about why checks that work without a human present are being asked for at all, that is a separate and more opinionated piece: From Passwords to Proofs.

Verifying an AI Agent's Authority Before It Spends: Signed Booleans Across Six Chains

Douglas Borthwick — Thu, 30 Jul 2026 19:32:09 +0000

At 4:52 on a Friday afternoon, an instruction lands at a corporate treasury service: pay this invoice. $48,000 in USDC to a vendor wallet, on behalf of a client called Meridian Labs. The sender is not Meridian's CFO. It is Meridian's procurement agent, a piece of software carrying a signed permission slip.

There is no human to call. The payment is irreversible the second it settles. And the one thing everyone has learned about AI agents this year is that some of them are compromised, confused, or running on authority that was revoked twenty minutes ago.

This post walks through how I answer that question with two API calls: what goes in, what comes back, why every answer is a signed boolean instead of a score, and how to verify the signatures yourself without trusting the API that produced them.

The two-party problem

The thing that makes agent payments different from checkout is that the actor and the owner are different parties. The agent spends; the money is Meridian's; whoever executes the payment sits in the middle carrying the liability if those two facts ever disagree.

So there are questions about two different wallets:

The agent's wallet: is this a registered, identifiable agent, and does it hold currently-valid authority from its principal?
The principal's wallet: is there a KYC-attested entity behind this, and can the treasury actually stand the payment?

An attestation evaluates one wallet, so this is two calls to POST /v1/attest. One receipt for the actor, one for the owner.

Call 1: may this agent act?

Two conditions against the agent's wallet, both answered from chain state on Base:

POST https://insumermodel.com/v1/attest
X-API-Key: <key>

{
  "wallet": "0xA9b3...the agent's wallet",
  "conditions": [
    {
      "type": "erc8004_agent",
      "chainId": 8453,
      "agentId": "412",
      "label": "Registered ERC-8004 agent"
    },
    {
      "type": "erc7710_delegation",
      "chainId": 8453,
      "delegationManager": "0xdb9B1e94B5b69Df7e401DDbedE43491141047dB3",
      "expectedDelegator": "0x51fA...Meridian's treasury",
      "delegation": { "...the signed ERC-7710 delegation object..." },
      "label": "Currently authorized by Meridian's treasury"
    }
  ]
}

Response, abridged (illustrative values, exact real shape):

{
  "pass": true,
  "results": [
    {
      "label": "Registered ERC-8004 agent",
      "met": true,
      "matchedVia": "owner"
    },
    {
      "label": "Currently authorized by Meridian's treasury",
      "met": true,
      "declaredLimits": [
        {
          "kind": "erc20_transfer_amount",
          "token": "0x8335...USDC on Base",
          "maxAmount": "75000000000"
        }
      ]
    }
  ],
  "attestedAt": "2026-07-31T20:52:14.000Z",
  "expiresAt": "2026-07-31T20:57:14.000Z",
  "sig": "MEUCIQDrT...",
  "kid": "insumer-attest-v2"
}

A few fields worth unpacking:

erc8004_agent is honest about what it proves. ERC-8004 registration is permissionless NFT minting, so met: true means exactly "registered in the Identity Registry at this agentId, and this wallet owns the agent NFT or is the registry's signature-verified agent wallet binding." matchedVia tells you which. No vetting, no reputation, no endorsement implied. An attestation that overclaims is worse than none.

erc7710_delegation checks the whole chain of facts. met: true only when the attested wallet is the delegate, the declared principal matches expectedDelegator, the EIP-712 signature verifies (EOA recovery, or ERC-1271 for smart-contract principals, and the result names which), the delegation is unrevoked as of the anchored block, every caveat uses a recognized enforcer, and any time window is currently open.

declaredLimits is a decode, not a verdict. The spending caveats the principal signed come back decoded, with amounts in base units. 75000000000 on a 6-decimal token is a $75,000 USDC cap, sitting above this $48,000 invoice. It is reported as what the principal signed rather than something the API simulated, and each entry carries the raw caveat terms hex it was decoded from, so you can re-derive the decode yourself from the enforcer's documented byte layout. If you plan to forward the attestation and would rather the cap not travel with it, send declaredLimits: "omit" in the request; met and the hashes stay byte-identical.

The expiry is 5 minutes, not the standard 30. Revocation is one transaction away, so a verdict about delegation is only fresh while it is fresh. The short window is the honest window.

Call 2: the owner, wherever the money lives

Corporate crypto treasuries are never on one chain. BTC in cold reserve, USDT on Tron because that is where payment liquidity is, RLUSD on the XRP Ledger, operating USDC on Base and Ethereum. The second call attests Meridian's treasury wallet, and each condition carries its own chainId:

{
  "wallet": "0x51fA...Meridian's treasury",
  "xrplWallet": "rN7n...",
  "bitcoinWallet": "bc1q...",
  "tronWallet": "TWdc...",
  "conditions": [
    { "type": "eas_attestation", "template": "coinbase_verified_account",
      "label": "KYC-attested entity" },
    { "type": "ratio_to_amount", "chainId": 8453,
      "contractAddress": "0x8335...USDC on Base",
      "multiple": "1.5", "amount": "48000",
      "label": "Operating account covers 1.5x this payment" },
    { "type": "token_balance", "chainId": 1,
      "contractAddress": "0xA0b8...USDC on Ethereum",
      "threshold": "250000",
      "label": "Mainnet float above policy floor" },
    { "type": "token_balance", "chainId": "xrpl",
      "contractAddress": "rMxC...RLUSD issuer", "currency": "RLUSD",
      "threshold": "100000",
      "label": "RLUSD reserve above floor" },
    { "type": "token_balance", "chainId": "bitcoin",
      "contractAddress": "native", "threshold": "5",
      "label": "BTC cold reserve intact" },
    { "type": "token_balance", "chainId": "tron",
      "contractAddress": "TR7N...USDT on Tron", "threshold": "150000",
      "label": "USDT payment float above floor" }
  ]
}

Six booleans come back across five chains, each block-anchored (blockNumber on EVM chains, ledgerIndex on XRPL, block height on Bitcoin), all under one signature. One call, one credit.

Two details I want to highlight for developers:

ratio_to_amount is the payment check that never goes stale. A flat threshold tuned for $48,000 invoices is wrong for $480,000 invoices. With a ratio you pass the transaction amount and your risk multiple per request, and the signed boolean is always scaled to the payment in front of you: balance >= multiple * amount.

The caller never learns a balance. The service knows the operating account holds at least 1.5x this payment. It does not know if that is $72,001 or $40 million. That asymmetry is why a counterparty is willing to answer at all. (One documented trade-off: Merkle proof mode on a token_balance condition does reveal the raw balance to the caller, since the proof is of the balance storage slot itself. Standard mode never does.)

Verify the signature yourself

The response is ECDSA P-256 signed. kid tells you which scheme: insumer-attest-v2 signs a domain-separated canonical preimage of {v, id, pass, results, attestedAt} with keys sorted recursively. The public key is in a standard JWKS at:

https://insumermodel.com/.well-known/jwks.json

So verification is any JOSE library plus the documented preimage, or npm install insumer-verify if you want it done for you. Add "format": "jwt" to the request and you also get the whole attestation as an ES256 JWT that any standard JWT library can verify against the same JWKS, which makes the verdict portable: hand it to another service and they can check it without calling anyone.

And for the one clause that could change a block later, you do not have to take the API's word at all. Request the delegation check with proof: "merkle" and the response carries an EIP-1186 storage proof of the DelegationManager's revocation slot, verifiable against the block header from any source you trust. "Unrevoked as of block N" stops being an assertion and becomes arithmetic.

No API key? The agent can pay per call

The part I find most fitting: the machine this was built for does not need an account. Send the request with no credential headers and the API responds with an HTTP 402 quote. Sign an EIP-3009 USDC authorization on Base, retry with the X-PAYMENT header, and the attestation comes back. Five cents, gasless for the payer, settled on-chain. An agent can go from never having heard of the API to holding a signed delegation verdict in two HTTP requests.

The menu is bigger than this scenario

Everything above is one composition. The same endpoint takes up to ten conditions per call, mixed across 38 chains, from nine condition types: token balances (including native BTC, TRX, XLM, SUI), NFT ownership (34 of the 38 chains), EAS attestations by template or raw schema, Farcaster identity, arbitrary boolean view calls against your own contracts (hasAccess(address) style), ratio rules against an amount or against total supply, and the two agent-standing types shown here.

The shape of the answer never changes: wallet state, checked against conditions you wrote, at a block, signed. Not a score. Nobody's model weighed anything. The policy (the 1.5x multiple, the reserve floors, which attestation counts as KYC) stays in your request where an auditor can read it, and the facts come back signed where an auditor can verify them. Fourteen months later, when someone asks why your service let a bot move $48,000, you are not defending an opinion. You are handing over arithmetic.

Docs, if you want to try it: verification API reference, state attestation spec. Free tier is an email and 100 reads a day, or skip the key entirely and pay per call over x402.

Your Agent Doesn't Need an API Key

Douglas Borthwick — Wed, 20 May 2026 14:31:50 +0000

Every AI agent today carries secret strings. Open its .env file and you will see them. OPENAI_API_KEY. ANTHROPIC_API_KEY. STRIPE_SECRET_KEY. Whoever holds those strings gets the access. That is the entire authentication model. After running our own agent for a few months, we got tired of it, so we shipped something else. It is on-chain. You can verify it on Basescan in two minutes.

API keys authenticate possession of a secret. Wallet signatures authenticate control of a wallet. That distinction is the whole article.

A secret is a thing that exists somewhere. It can be copied. It can be exfiltrated. It can be checked into a public repository by accident at 11pm on a Friday and sit there indexed by every crawler on the internet by Monday morning. The string itself is the authentication; whoever holds it is the legitimate user, as far as the API can tell.

A signature is not a reusable secret. It is a proof, generated on the spot, that whoever wrote this specific message also holds the private key for this specific wallet. The signature can be safely transmitted in cleartext. There is nothing in it that lets the recipient impersonate the signer. The signing key never moves.

Agents are already good at signing

Humans hate wallets. Humans forget passwords, lose hardware devices, paste seed phrases into the wrong channel, and get phished by emails that look exactly like the real ones. That aversion is the load-bearing reason wallet auth never replaced passwords for consumer login. Wallets are hard for humans, and it is a real reason.

Agents are not humans. For an agent, signing a message is a function call. The signing library is already in the runtime because the agent already uses a wallet for payments. The marginal cost of using the same wallet to sign API requests is zero. The thing that made wallet auth a non-starter for humans is the thing that makes it natural for agents.

What we built

We dogfooded it on our own API first, so we could speak from the experience of running it rather than describing what it might look like.

The agent's wallet sends 5 USDC to our platform wallet on Base. That buys 125 attestation credits, the unit one /v1/attest call consumes.
The agent POSTs the transaction hash to a single endpoint at api.insumermodel.com. In one response, the API returns an API key string and mints a non-transferable access pass to the same wallet on-chain.
For every subsequent /v1/attest call, the agent has two options. Present the API key in an X-API-Key header, the way every API has worked since the early 2000s. Or sign a fresh message with its wallet's private key and put the signature in an Authorization: Wallet header. No reusable secret crosses the wire. Other endpoints currently require X-API-Key; we'll expand wallet auth to them in later stages as their billing and write paths are reviewed for wallet-identity callers.
Our backend verifies the signature, confirms the wallet holds the access pass, debits one credit, and returns an ECDSA-signed attestation that anyone with the published key can verify offline.
No bearer secret ever transmitted. The signing key stays in the agent's runtime. The wallet sits where it is. The pass does not move.

Authentication becomes signing.

That is the whole pattern.

The token is not the payment

The token is the proof the wallet belongs to a legitimate customer.

This is where the design gets interesting, and where it would be easy to confuse two things that need to stay separate.

The pass is a membership. It proves that the wallet has paid for an InsumerAPI account at some point. It lives in the wallet permanently. It does not expire when credits run out. It does not have to be re-issued. If the agent stops using the account, the pass sits there. If it comes back a year later and tops up, the same pass is still there.

Credits are consumption. The agent buys a batch, uses them up on attestation calls, buys more. When they run out, the API returns a 402 with a clear path to top up. The wallet itself does not change. The pass is unaffected.

That separation matters because it lets the token act as a portable trust signal without coupling the holder to anybody's billing system. A third party building an API can check whether a wallet holds the pass and treat that as a soft signal that this wallet is a real customer of a real verification service, without needing to talk to us about anything, without OAuth federation, without shared databases, without a live API coordination round-trip.

The token is not the payment. The token is the proof the wallet belongs to a legitimate customer.

You can see the collection on Basescan: 0x3E2a408cc6eceba04FF9d04A5B8B05aBa8DD50ce. The settler wallet that mints to customers is owned by us. Customers only ever receive passes.

Issuers can deploy an access collection from any NFT factory, or write their own. We used RNWY's on Base for ours: 0x7ee64394....

The proof you can check yourself

Last night, our test agent's wallet, starting with $6 of USDC and a few cents of Base ETH for gas, ran the loop end to end. The four transactions sitting on Base mainnet are the public record. Anyone with the right amount of USDC can repeat the exercise.

USDC payment, test wallet to platform wallet: 0xf873f5e6...
Pass mint to the same wallet: 0x6cb43ea1...
Holder address: 0x259e32F4...
Collection: 0x3E2a408c...

We then revoked the pass from the test wallet and tried to authenticate again. The API rejected the request with the exact message it should: wallet does not hold an Insumer Access pass. The negative path works too. The whole cycle is repeatable.

And the signed attestations themselves are not just checkable today. Every response is signed against a public key published at our JWKS endpoint. Anyone holding the response, today, tomorrow, or years from now, can verify the signature offline against that key, without calling our service at verification time. The bytes are tamper-evident.

Where this fits in the wallet's evolution

Wallets started as places to hold crypto. Then they became login systems. Sign-in-with-Ethereum has been a standard since 2021. Now they are becoming machine authenticators.

The wallet is the natural credential.
The signature is the natural authentication primitive.

The agent is the natural user. There is no human in the loop to lose a hardware device or forget a passphrase. The runtime signs in milliseconds, every time, without complaint. That progression has been visible in the standards conversations for a while. Mastercard is drafting an agent-payment standard. NIST is running workshops on agent identity. Coinbase is opening agentic markets that assume agents will arrive with wallets attached. The shape is settling. We are one of several teams arguing that wallet-signed authentication will end up doing for agents what OAuth did for delegated human login.

We are not replacing API keys

Humans will keep using API keys for a long time. For the typical developer, with a handful of services and a personal laptop, the API key model works. It is familiar. It is supported by every client library. The marginal benefit of switching is small.

What we shipped is purely additive. The X-API-Key header still works on every endpoint. Every existing customer sees zero behavioral change. We are not pushing anyone to switch. We are not killing the old path. We are not requiring wallets.

But agents are different. Agents already:

sign,
transact,
hold wallets,
persist identity across sessions,
and operate continuously, without human supervision.

For software with those properties, wallet-based authentication is often the more natural primitive. The asymmetry between human pain and machine ease, the one that kept wallet auth out of consumer login, runs in the opposite direction when the user is autonomous code.

The category, in our terms

The primitive is wallet auth: read wallet state, evaluate conditions, return a signed boolean. The category is condition-based access. A single signed call can stack up to 10 conditions across 37 chains, mixing ERC-20 balances, NFT ownership, EAS attestations, and Farcaster identity in any combination. Agent API auth is one stack among many. An SDK adopter who wants to gate on the access pass and an EAS attestation and a Pudgy Penguin can ask for that exact compound in one call.

You can do this for your own API

We built this for ourselves first because we wanted to feel the operational friction of running it before recommending it to anybody else. It went into production yesterday. The next step is letting other APIs do the same thing without having to write the middleware from scratch.

Our sister company, Skye Meta, ships a free, MIT-licensed npm package for exactly this, called @skyemeta/access. One line to install:

npm install @skyemeta/access

It is either-or middleware. API-key requests pass through unchanged. Wallet-signed requests are verified through InsumerAPI's /v1/attest endpoint under the hood. Your existing customers see zero change. Your agent customers get a path that does not require them to manage a secret string. Bring your own InsumerAPI key, pick the access collection of your choice, and wrap your existing route handlers with the supplied middleware.

The developer quickstart walks through grabbing a free InsumerAPI key (10 attestation credits, 100 requests per day, no credit card) and the first /v1/attest call. The package source is on GitHub at douglasborthwick-crypto/skyemeta-access. If you would rather skip the middleware and call the underlying InsumerAPI primitive directly, the API reference documents every endpoint.

The ending

The first generation of APIs authenticated software with shared secrets. The next generation may authenticate software with signatures instead.

Last night, our own agent's wallet paid for access, received a pass, signed a request, and successfully authenticated, without ever transmitting a reusable secret. The transactions are public. The pattern works.

We are not arguing that every API should switch tomorrow. We are arguing that, for the subset of API consumers that are autonomous software with wallets, the more natural primitive is now available and on-chain, and the cost of trying it is the price of one cup of coffee.

Originally published at insumermodel.com.

Wallet Auth Now Reads Tron, Stellar, Sui, and XDC

Douglas Borthwick — Thu, 14 May 2026 18:56:51 +0000

Stablecoin settlement runs through Tron. Tokenized money market funds issue on Stellar. Object-native value lives on Sui. Trade finance is collateralizing on XDC. Four chains. Four different storage models. Four different reasons to be there. Wallet auth reads all of them now.

The chain count moved from 33 to 37 this week. That is not the headline. The headline is what the new four represent: four economic environments that look nothing like each other underneath, all answering to the same signed boolean on the way out.

InsumerAPI's primitive is wallet auth. Read on-chain state, evaluate against caller-supplied conditions, return an ECDSA-signed attestation. Conditions in. Signed attestations out. The contract surface for a relying agent or service is one POST to /v1/attest and one signature to check against the public JWKS. What changes when a new chain ships is not that surface. It is the set of things the surface can answer about.

Tron: where USDT actually moves

USDT on Tron is the largest stablecoin venue on chain by transfer volume. The supply of USDT-TRC20 has, at various points across 2025 and into 2026, exceeded the supply of USDT on every other chain combined. Remittance corridors in Southeast Asia, Latin America, and parts of Africa default to it. Centralized exchanges treat it as the canonical deposit rail.

If an agent's job is to evaluate whether a counterparty wallet can settle in dollars, ignoring Tron means ignoring the largest dollar venue on chain. The new tronWallet parameter on POST /v1/attest and POST /v1/trust closes that gap. Pass a T-prefixed base58 address, set chainId to "tron", and the attestation returns the same shape as every other chain. Native TRX uses contractAddress: "native". TRC-20 tokens use a T-prefixed contract address. USDT-TRC20 lives at TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t, six decimals.

Stellar: where tokenized US Treasuries issue

Stellar hosts BENJI, Franklin Templeton's tokenized US Government Money Market Fund (the on-chain wrapper of FOBXX). BENJI is one of the largest tokenized money market funds in circulation. Holders receive the underlying fund's yield. Redemption is in-fund. The token tracks the share price. BENJI on Stellar is a classic trustline asset, not a smart-contract balance.

Stellar also hosts Circle's classic-trustline USDC, distinct from any Soroban contract version. Wallet auth reads the classic trustline state, because that is the issuer-anchored deposit ledger that BENJI and USDC actually live on. Pass a G-prefixed StrKey wallet, set chainId to "stellar", and add an assetCode field for trustline tokens ("USDC", "BENJI"). The signed attestation comes back with ledgerIndex and ledgerHash alongside the boolean. Soroban contract balances are out of scope for this release.

The USDC issuer on Stellar is GA5ZSEJYB37JRC5AVCIA5MOP4RHTM335X2KGX3IHOJAPP5RE34K4KZVN. The BENJI issuer is GBJW74JRHIIIYC3X3J5VKLR2CR4UJHKO76V5J5SAYTUFAUE7PJBKCT5R. Pass either as the contractAddress, pair with the matching assetCode, and the trustline state is the read.

Sui: object-native USDC

Sui runs on the Move language, and Move does not think about balances the way EVM does. There is no contract holding a mapping from address to amount. There are objects, owned by addresses, with types. USDC on Sui is a Coin<USDC> object type. Reading how much USDC a wallet holds means summing the wallet's owned objects of that type.

Circle deployed native USDC on Sui in 2024, and the deployment has expanded supply through 2025 and into 2026, with growing integration on Cetus, Navi, and Sui's institutional rails. The contractAddress for a Sui token is the fully-qualified Move type string. For USDC on Sui, that is 0xdba34672e30cb065b1f93e3ab55318768fd6fef66c15942c9f7cb846e2f900e7::usdc::USDC. Pass a 64-hex-character suiWallet, set chainId to "sui", and the attestation comes back with checkpointSequence and checkpointDigest binding the read to a specific Sui consensus checkpoint.

XDC: enterprise EVM where trade finance settles

XDC (chainId: 50) is the EVM chain banks actually point at. It is the only EVM ledger with native ISO 20022 message-format compatibility, which is the standard banks already use for cross-border wire and clearing instructions. That alignment is why the TradeFinex consortium runs there and why a growing pile of tokenized trade-finance assets, factoring receivables, and institutional RWAs issue on XDC rather than on consumer-DeFi EVM venues. The economic identity is different from a Base or an Arbitrum: it is the venue where regulated cash-flow instruments tokenize.

Because XDC accepts standard EVM tooling, every condition type works without any chain-specific wrapper. Add chainId: 50 to a condition that already worked on another EVM chain and it evaluates the same way. No new wallet parameter. No new address shape. The same wallet field handles it. Merkle proofs (EIP-1186 storage proofs) are available for token_balance conditions on XDC, the same as on the other EVM chains whose RPC supports eth_getProof.

The trust profile got a new dimension

POST /v1/trust returns a multi-dimensional fact profile. The previous shape had four base dimensions: stablecoins (USDC and USDT across 21 EVM chains), governance, NFTs, and staking. Optional solanaWallet, xrplWallet, and bitcoinWallet would tack on Solana, XRPL, and Bitcoin dimensions when those wallets were supplied.

This release adds a fifth base dimension that runs on every call: institutional_stablecoins. Eight checks spanning EVM, Solana, XRPL, Stellar, and Sui. The inventory covers Société Générale-FORGE's EURCV on Ethereum, Solana, and XRPL; FORGE's USDCV on Ethereum and Solana; Circle's classic-trustline USDC on Stellar; Franklin Templeton's BENJI on Stellar; and Circle's native USDC on Sui. The five EVM/Solana/XRPL checks resolve from the standard wallet fields. The three Stellar and Sui checks activate when stellarWallet and suiWallet are passed.

Optional tronWallet adds a separate tron dimension covering USDT-TRC20. Up to 49 checks across 27 chains in a single signed profile. No score. No opinion. Just verifiable evidence organized by dimension.

What did not change

The /v1/attest envelope is byte-identical for existing callers. The signature scheme is unchanged: ECDSA P-256, resolved by kid from the JWKS at /v1/jwks (insumer-attest-v1 on keys from this release's era; keys minted today sign under insumer-attest-v2). The JWT format (set format: "jwt" on the request body) returns an ES256 token verifiable by any standard JWT library. Existing integrations on EVM, Solana, XRPL, and Bitcoin keep working with zero code changes. The four new wallet fields and the new chainId enum values are additive optionals.

That non-event is the point. Wallet auth as a primitive is meant to abstract chain differences. If adding four chains had broken the envelope, the primitive would have failed its job.

Available today

All four chains are live in production at api.insumermodel.com. The SDK family shipped the same day: insumer-verify@1.4.4 (npm), mcp-server-insumer@1.10.0 (npm), @insumermodel/plugin-eliza@2.1.0 (npm), langchain-insumer@0.11.0 (PyPI), and llama-index-tools-insumer@0.3.0 (PyPI). The OpenAPI spec, ChatGPT Custom GPT action schema, and llms.txt agent-discovery files all reflect the 37-chain surface.

The free tier at insumermodel.com/developers grants 10 verification credits, which is enough to run a multi-chain trust profile call against a wallet that touches Tron, Stellar, Sui, and EVM, then inspect the institutional_stablecoins dimension end to end. Add tronWallet, stellarWallet, and suiWallet to the same request body and the response composes everything in one signed envelope.

The full chain list and per-chain condition shapes live in the API reference and the trust profile docs.

Condition-Based Access for Machine Payments Protocol: A Signed Yes-or-No Before the Charge

Douglas Borthwick — Thu, 07 May 2026 13:35:59 +0000

This is pre-transaction gating: a signed yes-or-no before any machine payment executes. MPP routes charge money. @insumermodel/mppx-condition-gate puts that yes-or-no in front of any charge: wallets that meet your conditions get a free-access receipt referencing a per-call signed attestation, everyone else falls through to the normal paid path. First listed entry on Tempo's /extensions page (PR #445, merged March 23). The primitive underneath is the same wallet auth that backs every other InsumerAPI surface: read → evaluate → sign.

What it does

The Machine Payments Protocol (MPP) gives every payment method a typed shape. A Method.Server returns a Promise that resolves to a payment receipt. @insumermodel/mppx-condition-gate sits in front of any Method.Server and inserts one decision before the charge runs.

If the requesting wallet meets the configured conditions, the gate returns a free-access receipt that references a per-call signed attestation. If it does not, control falls through to the original Method.Server, and the charge proceeds normally.

Tempo's MPP documentation lists @insumermodel/mppx-condition-gate as the first entry on its /extensions page, merged March 23, 2026.

The gap MPP leaves open

MPP already carries the payer's wallet on every request. Each payment credential includes a credential.source field shaped like did:pkh:eip155:8453:0xABC.... The chain ID and address are part of the request envelope.

What MPP does not provide is the layer that decides whether a particular wallet should be charged at all. There is no native pattern for "this wallet meets a configured condition, give it a free receipt." Without an adapter, every Method.Server that wants this behavior has to:

Parse the DID format
Maintain RPC endpoints across however many chains it cares about
Run its own ownership and attestation checks
Cache the result
Decide what to return when the check fails

Most projects skip the work. The ones that do build it end up reimplementing the same plumbing the next project will reimplement next month.

Four condition types

The package exposes one function. Hand it any Method.Server and a list of conditions. v2.0 supports four condition types. Mix any of them in a single call:

import { Mppx, tempo } from 'mppx/server'
import { conditionGate } from '@insumermodel/mppx-condition-gate'

const tempoCharge = tempo({
  currency: '0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913',
  recipient: '0xYourAddress',
})

const gatedCharge = conditionGate(tempoCharge, {
  apiKey: process.env.INSUMER_API_KEY,
  matchMode: 'any',
  conditions: [
    // Token holders pass
    { type: 'token_balance', contractAddress: '0xYourToken', chainId: 8453, threshold: '100' },
    // NFT holders pass
    { type: 'nft_ownership',  contractAddress: '0xYourNFT',   chainId: 8453 },
    // Coinbase-verified wallets pass
    { type: 'eas_attestation', template: 'coinbase_verified_account', chainId: 8453 },
    // Wallets with a Farcaster account pass
    { type: 'farcaster_id' },
  ],
})

const mppx = Mppx.create({ methods: [gatedCharge] })

When a request lands, conditionGate extracts the wallet from credential.source, calls POST /v1/attest with that wallet and the conditions, and looks at the result.

If any of the conditions are met (or all of them, when matchMode: 'all'), the gate returns a receipt where the reference field is condition-gate:free:{attestationId}. The signed attestation is retrievable by ID, the receipt itself just points to it.

If no conditions are met, or the API is unreachable, the gate calls the original Method.Server's verify and lets the payment proceed normally.

What the adapter does not do

The adapter does not re-sign the attestation. The signature on the result is the one InsumerAPI produced, the adapter passes it through unchanged.

The adapter does not wrap the attestation in a second envelope. The receipt's reference field carries the attestation ID as a plain string, the attestation itself is retrievable byte-identical to what a direct curl to /v1/attest would produce.

The adapter does not introduce a second signing key. There is no MPP-side or adapter-side root key that signs anything. The only signature in the chain is the one from InsumerAPI's per-call signing.

The adapter does not call back to InsumerAPI for verification. Any downstream service can check the signature offline against the public JWKS.

The signed primitive stays untouched. The adapter is plumbing. It translates between MPP's request shape and the wallet auth call. It is not an actor that produces its own claims.

Why this shape composes

Method.Server is the right composition point. Every MPP payment method ships one. So the same conditionGate adapter applies to:

Tempo charges
Stripe charges
Any other Method.Server built on the MPP interface

It is also framework-agnostic. The adapter never touches request routing. It takes a Method.Server in and returns a Method.Server out. So the same package works under:

Hono
Express
Elysia
Next.js
Any other framework that consumes an MPP server

And it is non-destructive. The adapter sits before the original verify, on miss it falls through to the original Method.Server. Adding it to a paid route does not break the paid path, it only adds a free path for wallets that meet the configured conditions.

Verifying offline

Every result that comes out of the attest call carries an ECDSA P-256 signature and a key ID (kid). The signing key is published at insumermodel.com/.well-known/jwks.json. Any party that has the attestation can verify the signature against that JWKS using any standard JOSE library. No callback to InsumerAPI required.

If you ask for jwt: true in the options, the same result also comes back as a standard ES256 JWT with the signed attestation as JWT claims. That turns the output into a drop-in bearer token. Any service that already verifies JWTs can verify the gate result without learning anything new.

Each result is a boolean per condition. Met or unmet. Boolean, not balance. The gate tells you whether the wallet meets the configured condition, never how much it holds.

Chains and pricing

InsumerAPI covers 33 chains today: 30 EVM (Ethereum, Base, Polygon, Arbitrum, Optimism, BNB, Avalanche, and 23 more), plus Solana, XRPL, and Bitcoin. Token and NFT conditions evaluate on any of these. EAS conditions evaluate on EVM chains. Farcaster ID conditions always evaluate on Optimism.

The wallet holder pays nothing at the gated route. The operator running the gate pays per attestation call out of the API key's credit balance.

Two ways to provision a key. POST /v1/keys/create takes an email and ships 10 free attestation credits, no credit card. POST /v1/keys/buy takes a USDC, USDT, or BTC transfer and provisions a key in one call. The transaction sender wallet is the identity, the payment is the auth. No email, no human in the loop. The first path is the natural fit for human-managed deployments, the second for an autonomous agent inside the gate.

Top up an existing key on-chain via POST /v1/credits/buy: USDC or USDT on any major EVM chain, USDC on Solana, or BTC on Bitcoin. Same rails the Method.Server underneath sits on, same self-serve loop.

Where this fits

The wallet auth primitive does not change shape when it lands inside MPP. It still reads on-chain state, evaluates conditions, and returns a signed boolean. @insumermodel/mppx-condition-gate is the thin adapter that lets MPP routes ask for that boolean across token, NFT, EAS, and Farcaster conditions before deciding whether to charge. Tempo's extensions page is the first listed surface. The shape extends to any payment-route platform that exposes a Method.Server-style interface.

Before a machine pays, it should qualify.

How InsumerAPI Powers SkyeGate Lite

Douglas Borthwick — Tue, 05 May 2026 13:21:56 +0000

SkyeGate Lite is now live on WordPress.org. It runs on InsumerAPI. The primitive is wallet auth: read, evaluate, sign. Boolean, not balance. Verified yes or no. This is what InsumerAPI provides, and what a product like SkyeGate stands on.

Wallet auth, defined

Wallet auth is to a wallet what OAuth is to an account. It is a primitive for proving access. The difference is what it proves. OAuth proves who the user is. Wallet auth proves what the wallet holds.

A caller sends conditions. A token balance threshold. An NFT held. An EAS attestation present. A chain of these, combined into one boolean. InsumerAPI reads chain state, evaluates the conditions, and signs the verdict. The response is one boolean per condition.

Verified yes or no. Boolean, not balance.

What the signed verdict carries

Every verdict from InsumerAPI is an ES256 JWT. ECDSA over P-256, the same cryptographic shape used in modern web standards. The payload is short. Pass or fail per condition. A condition hash for tamper detection. An expiration. The issuer (https://api.insumermodel.com). A signing key identifier (insumer-attest-v1).

The signing key is published at https://api.insumermodel.com/.well-known/jwks.json. Anyone can fetch it. Anyone can re-verify any verdict, end to end, without asking InsumerAPI again.

Three properties products inherit

A product running on InsumerAPI inherits three things by virtue of using the primitive.

Deterministic. Same wallet, same conditions, same chain state. Same verdict. No model drift. No scoring opinion. No judgment call.
End-to-end verifiable. The signature is from InsumerAPI, not from the product. A product cannot forge a pass even if it wanted to, because anyone can re-verify the JWT against the public JWKS endpoint.
No consumer secrets in the loop. The primitive does not accept and cannot use consumer credentials. There is nothing to phish, rotate, store, or leak.

A product like SkyeGate gets all three properties by design, not by discipline.

No secrets, no identity-first, no static credentials

This is the narrative core. A visitor connects a wallet and supplies a public address. That is the entire input on the consumer side. There is no password. No email. No API key on the consumer side. No shared secret between the merchant and the customer. There is no identity claim at all. Only what the wallet holds.

The merchant inherits this property automatically. A merchant running on InsumerAPI cannot accidentally introduce consumer-secret leakage, because the primitive does not accept consumer secrets to begin with. The failure mode wallet auth removes from the surface is the failure mode every credential-based gate suffers from. Storing consumer secrets that someone, somewhere, eventually leaks.

Provable and private

Both properties have to coexist or the primitive does not work.

Provable. A merchant or end user can take any verdict and re-verify it against the public JWKS using only public information. The verdict cannot be forged. The condition cannot be silently changed, because the condition hash catches it. InsumerAPI itself cannot rewrite history, because the signature pins the verdict to the moment it was issued.

Private. The verdict is a boolean. It does not say how much is in the wallet, what else is held, who the user is, what other addresses they control, or what they have done. A merchant gating ETH at a 0.1 threshold learns yes or no. Not the balance. Not the wallet history. Not the identity. Boolean, not balance.

Provable and private.

Condition-based access, one primitive, many surfaces

SkyeGate is one product on top of the primitive. It runs on WordPress.

The same primitive also slices. SkyeGate Lite, the free WordPress plugin, exposes one condition per gate. SkyeGate, the paid version, exposes up to ten conditions chained into one boolean. Both run on the same /v1/attest call. The primitive does not change. The product chooses the slice.

The same primitive runs other surfaces too. SkyeWoo gates WooCommerce. AgentTalk handles agent-to-agent calls. Same boolean, same JWKS, different transport. Any HTTP-speaking client can call /v1/attest, get back a signed verdict, and gate whatever it gates.

The primitive scales sideways. New surfaces do not require a new primitive. They require a new consumer of the same primitive. A signed boolean is portable.

Try it

SkyeGate Lite is free on WordPress.org. The SkyeMeta announcement walks through install and the first shortcode.

Or build your own consumer. POST conditions to /v1/attest, verify the returned JWT against the JWKS endpoint, and gate whatever your stack gates. The full reference is at /developers/api-reference/.

Add Wallet Auth from Claude Code in One Command

Douglas Borthwick — Tue, 28 Apr 2026 15:42:58 +0000

You are building something in Claude Code. A discount flow that requires holding a specific token. An AI agent that will not move money for unverified wallets. An NFT-gated dashboard. The wallet auth piece is fiddly. Chain RPCs, contract calls, signature verification, edge cases. One Smithery skill turns it into one command.

Install once, ask Claude

The skill lives at smithery.ai/skills/douglasborthwick/insumer-skill. Add it to Claude Code:

smithery skill add douglasborthwick/insumer-skill --agent claude-code

That registers the skill at the project level. --global registers it across every project on the machine. The skill works the same way across the rest of the agent ecosystem: --agent cursor, --agent codex, --agent windsurf, --agent cline, and others.

Once installed, ask Claude what you want. Examples:

Add a check that gates this endpoint on holders of at least 100 USDC on Base.
Verify this wallet owns the Pudgy Penguins NFT before letting them claim.
Before this agent moves money, pull a trust profile and require it to score above the warning threshold.
Add a delegated-authority check using delegate.xyz.
Verify an EAS attestation on the wallet before approving the transaction.

Claude reads the skill, picks the right endpoint, writes the call, parses the signed response, and adds JWKS verification so the result holds up offline. You review the diff and ship.

What Claude knows after installing

The skill is procedural knowledge, readable in full on Smithery before you install. It teaches Claude six things that are easy to get wrong otherwise:

Pick the right endpoint. POST /v1/attest when the developer specifies the exact condition (token balance, NFT ownership, delegated authority, EAS attestation, USDC threshold). POST /v1/trust when the developer wants a curated multi-dimension fact profile across 25 chains, up to 27 with optional Solana, XRPL, Bitcoin, and Tron wallets.
Verify the signature. Every response carries an ECDSA P-256 signature under one of three key IDs: insumer-attest-v1, insumer-attest-v2 or insumer-trust-v2. The skill makes Claude verify against the published JWKS at https://insumermodel.com/.well-known/jwks.json, never trust the raw JSON body. (Update, September 2026: every response also carries a post-quantum companion signature, pqSig and pqKid under insumer-attest-pq1 or insumer-trust-pq1, resolved from the same JWKS; the ECDSA signature and the three EC key IDs are unchanged.)
Boolean, not balance. The skill stops Claude from leaking raw balances to the client. Standard mode returns a signed yes or no plus the condition hash. The actual chain read happens server-side.
Resolve the key by kid. The skill reads the kid on each response (insumer-attest-v2 on keys minted today, insumer-attest-v1 on pre-cutover keys) and selects the matching key from the JWKS set, so verification survives key rotation instead of breaking on a pinned literal. (Update, September 2026: the set now also holds two AKP entries for the post-quantum companion key, so matching by kid, and by pqKid for the companion, is the only safe way to pick an entry.)
Never inline the API key. The skill enforces process.env.INSUMER_API_KEY server-side only. No browser fetches. No keys in source.
Use the right primitives for the right layer. Wallet auth is condition-based access. The skill stops Claude from confusing it with WalletConnect (UX layer), wagmi or viem (RPC layer), or SIWE / EIP-4361 (proof of ownership). Different primitives, different jobs.

What you get back from a call

Every /v1/attest response is a signed envelope. The shape Claude will write against:

{
  "ok": true,
  "data": {
    "attestation": {
      "id": "ATST-9F2C4E6A1B3D5F70",
      "pass": true,
      "results": [
        {
          "condition": 0,
          "label": "100+ USDC on Base",
          "type": "token_balance",
          "chainId": 8453,
          "met": true,
          "evaluatedCondition": {
            "type": "token_balance",
            "chainId": 8453,
            "contractAddress": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
            "operator": "gte",
            "threshold": "100"
          },
          "conditionHash": "0x3a7f...",
          "blockNumber": "0x21e8a40",
          "blockTimestamp": "2026-03-06T10:00:01.000Z"
        }
      ],
      "passCount": 1,
      "failCount": 0,
      "attestedAt": "2026-03-06T10:00:01.000Z",
      "expiresAt": "2026-03-06T10:30:01.000Z"
    },
    "sig": "MEQCIB...base64...",
    "kid": "insumer-attest-v2"
  },
  "meta": { "version": "1.0", "timestamp": "2026-03-06T10:00:01.000Z", "creditsCharged": 1, "creditsRemaining": 9 }
}

The verification is portable. Any service downstream of the agent can re-verify the signature against the public JWKS without calling the API back. The condition hash lets the caller confirm the verdict is for the exact condition they asked about, not a substituted one. The block number and timestamp pin the read to a specific point in chain history.

What 38 chains buys you

Coverage is the boring part of wallet auth that bites you in production. The skill knows the live surface:

32 EVM chains, with optional Merkle storage proofs where the chain's RPC serves them (Ethereum, Base, Arbitrum, Optimism, Polygon, BNB Chain, Avalanche, and others).
Solana for SPL token holdings and SOL.
XRPL for trust lines and stablecoin holdings (RLUSD, USD-issued lines).
Bitcoin for native BTC holdings.
Tron, Stellar, and Sui for token balances.

If a developer asks Claude to verify a condition on a chain the API does not cover, the skill instructs Claude to surface that explicitly rather than fabricate an integration. The list of supported chains lives in the skill's reference data, not in Claude's training-time memory.

Free key, no signup

The first thing the skill tells Claude to do is mint a free key. The flow is one curl, no email confirmation:

curl -s -X POST https://api.insumermodel.com/v1/keys/create \
  -H "Content-Type: application/json" \
  -d '{"email":"you@example.com","appName":"my-project","tier":"free"}'

The response includes a key starting with insr_live_. Drop it in .env as INSUMER_API_KEY. The free tier comes with 10 free verifications plus 100 reads per day, enough to wire up an integration end-to-end and ship the first version.

Where this fits with the rest of the agent stack

The Smithery skill is one of several integration paths into InsumerAPI. Pick whichever matches the stack:

Smithery skill: the post you are reading. Best when the developer is in Claude Code, Cursor, Codex, Windsurf, or another Smithery-compatible agent and wants Claude to write the integration.
MCP server: when the agent needs typed tools at runtime, not procedural guidance at code-write time. npx -y mcp-server-insumer, 27 tools across 38 chains.
LlamaIndex toolkit: for Python agents on LlamaIndex or LangGraph.
OpenAPI Actions: load openapi.yaml directly into a custom GPT.

All four hit the same endpoints, return the same signed envelopes, and verify against the same JWKS.

The transport changes; the primitive does not.

Why this is a good fit for Claude Code in particular

Claude Code already writes most of the boilerplate. The hard part of wallet auth is not the boilerplate. It is the parts most LLMs get subtly wrong: confusing wallet auth with wallet connection, validating a JWT but not the underlying signature, picking the wrong endpoint, asking for a balance when a boolean is the right contract. The skill closes that gap. Claude reads the rules, writes correct integration code the first time, and the diff is small enough to review in a minute.

If you are sitting in Claude Code right now, the install is one command. The next thing Claude writes will be the integration you actually wanted.

Coinbase Agentic.Market Opens: Agents Need Wallet Auth, Not Just Tools

Douglas Borthwick — Mon, 27 Apr 2026 00:04:44 +0000

Coinbase just launched Agentic.Market, a marketplace where AI agents discover tools, transact autonomously, and settle payments using the x402 protocol. Agents can browse services, negotiate terms, and execute payments without human intervention. The infrastructure is live. Agentic.Market proves agents can pay. It doesn't prove they should be trusted. Payment rails solve settlement. They don't solve counterparty risk. That's the gap wallet auth fills, and it's what POST /v1/trust was built for.

What Agentic.Market Actually Launched

Agentic.Market is Coinbase's new marketplace for autonomous agent commerce. Agents discover services, evaluate pricing, and complete transactions server-to-server using x402, the open standard for agent payments. The protocol standardizes how agents pay for API calls, data feeds, and compute services using USDC or other stablecoins.

The market is aimed at agent builders who need their agents to autonomously procure resources: language model inference, data retrieval, blockchain indexing, oracle feeds, compute cycles. Instead of developers pre-funding API accounts with credit cards, agents operate their own wallets and pay per request.

This is a big unlock. Agents can now discover and purchase capabilities at runtime, not just use what their creator hard-coded. The vision is agent-to-agent commerce at scale. One agent sells compute. Another buys it. Settlement happens on-chain. No human approval loop.

But autonomy creates a trust problem. When an agent shows up at your API endpoint with a wallet and a payment, how do you know it's safe to serve the request? You need more than proof of payment. You need context about what kind of wallet this is.

Why Payment Rails Are Not Enough for Agent Commerce

x402 solves the payment side: the agent proves it can pay, the service delivers, settlement happens atomically. That's the easy part. The hard part is deciding whether to accept the transaction in the first place.

Traditional commerce has credit scoring, fraud detection, KYC, transaction history, chargebacks, dispute resolution. Agent commerce has none of that. An agent wallet shows up. It has USDC. Should you serve the request? Charge premium pricing? Require escrow? Reject it outright?

You can't ask for identity. Agents don't have passports or corporate registrations. You can't rely on reputation systems that don't exist yet. You can't call the agent's creator, because the whole point is autonomous operation.

What you can do is read the wallet's on-chain state and evaluate it against conditions. Does it hold governance tokens? Stablecoins across multiple chains? NFTs from known projects? Has it staked assets? This is wallet auth: condition-based access against on-chain state. It's verifiable in real time, and it doesn't require the agent to disclose balances.

That's what POST /v1/trust returns: a signed wallet auth profile with up to 40 checks across up to 7 dimensions. The base profile covers stablecoins (26 checks: 16 USDC + 10 USDT), governance tokens, NFT ownership, and staking positions. Optional Solana, XRPL, and Bitcoin holdings extend the profile when those wallets are supplied. The API reads on-chain state, evaluates the conditions, and returns a cryptographically signed result. No balances exposed. No transaction history. Just a boolean summary.

For attestations like Coinbase KYC, Coinbase Verified Country, or Gitcoin Passport, the right surface is POST /v1/attest with custom conditions. These EAS attestations (Ethereum Attestation Service, the on-chain registry where issuers publish signed claims) sit alongside token balance thresholds in the same signed result.

This is the same pattern Web2 went through. Stripe solved payments; every merchant still needed fraud detection. Plaid solved bank-account linking; every fintech still needed KYC. Settlement and trust live at different layers, and trust is where the differentiation sits. Agent commerce is the same dynamic, just on-chain. Wallet auth is to agent commerce what fraud detection was to e-commerce.

How Integrators Use Wallet Auth in x402 Agent Commerce

Revettr is a counterparty risk scoring service for x402 payments. Their integration pattern uses POST /v1/trust as the wallet auth signal that feeds their scoring model. Revettr doesn't write its own multi-chain logic. It consumes Insumer's signed wallet auth profile and maps it to its own counterparty tiers.

This is the pattern with x402 infrastructure: payments are commoditized, wallet auth is not. Stablecoin settlement is a solved problem. Knowing whether to accept the transaction is the hard part. As we covered in AI Agents Need Wallet Trust Profiles Before They Handle Money, agents need verifiable context about their counterparties before settlement, not just proof of funds.

AsterPay's KYA Hook (ERC-8183 agentic commerce) is built on POST /v1/attest with custom conditions. Token balance thresholds combined with EAS attestations like Coinbase KYC and Coinbase Verified Country feed AsterPay's trust tiering, which determines the commercial terms an agent receives at checkout.

What Merchants on Agentic.Market Actually Need

If you're a service provider listing on Agentic.Market, here's what you need to make agent commerce work:

Payment verification. x402 gives you this. The agent proves it can pay, you deliver the service, settlement happens atomically. This is the base layer.

Wallet auth. Before you accept the transaction, you need to evaluate the counterparty wallet against your conditions: Is this a wallet I should serve? Should I charge standard pricing or require premium? Should I ask for escrow or deliver immediately? POST /v1/trust gives you this. Up to 40 checks across up to 7 dimensions. Signed result. 3 credits per call. Single-call latency.

Audit trail. When an agent transaction goes wrong, you need a signed record of what the wallet looked like at the time of transaction. Insumer responses are ECDSA P-256 signed with public keys published at /.well-known/jwks.json. You can verify the signature client-side using insumer-verify (npm, zero dependencies) or server-side using any JWKS library. The signature proves the data came from Insumer and hasn't been tampered with.

Multi-chain coverage. Agents operate across chains. Your wallet auth layer needs to cover all of them. Insumer supports 33 chains: 30 EVM chains (Ethereum, Base, Polygon, Arbitrum, Optimism, BNB Chain, Avalanche, and 23 others), plus Solana, XRPL, and Bitcoin. One API call, one signed profile, all chains.

Privacy by default. You don't need to see raw balances. You need boolean results: does this wallet meet the threshold or not? Insumer never returns balance amounts, transaction history, or portfolio data. Just evaluated conditions and a signed yes/no.

How to Integrate Wallet Auth into Your Agent Commerce Flow

If you're building a service for Agentic.Market or any x402-enabled agent platform, here's the integration pattern:

Agent initiates transaction. It sends a payment proof via x402. Before you accept, you call POST /v1/trust with the agent's wallet address. Insumer returns a signed wallet auth profile. You evaluate the profile against your own merchant tiers: standard pricing, premium access, escrow-required, or reject.

You serve the request or reject it. If you serve, you log the signed wallet auth profile as your audit trail. If something goes wrong later, you have cryptographic proof of what the wallet looked like at transaction time.

This is not a human-in-the-loop decision. It's a server-side API call that happens before settlement. The entire flow is autonomous: agent discovers service, requests access, proves payment ability, gets evaluated against your conditions, completes transaction. No email. No KYC form. No manual approval.

For AI agent platforms, the MCP server integration makes this even simpler. mcp-server-insumer (npm, also published in the MCP Official Registry) ships 27 tools spanning attestation, wallet auth profiles, compliance templates, merchant onboarding, and credit management. The agent can call wallet_trust directly and get back a parsed signed result without the developer writing integration code. Same for LangChain agents: langchain-insumer (PyPI) ships 26 tools covering the same surface.

The agent doesn't need to understand blockchain RPCs, signature verification, or multi-chain state. It just asks: does this wallet meet the conditions? The API answers with a signed boolean. The agent uses that result to make autonomous decisions.

What This Means for Agent Commerce Infrastructure

Agentic.Market is the first major marketplace for autonomous agent commerce, but it won't be the last. Google announced up to $185 billion in AI infrastructure spend for 2026, with CEO Sundar Pichai framing this as the "agentic era." Agents are moving from demos to production, and production agents need to transact autonomously.

Payment rails are necessary but not sufficient. Every agent commerce platform will need:

Settlement infrastructure (x402, USDC, stablecoin rails)
Wallet auth infrastructure (condition-based access, signed boolean verdicts, multi-chain state evaluation)
Audit infrastructure (signed records, cryptographic proof, dispute resolution)

Insumer is infrastructure for number 2. We're not an x402 tool. We're the wallet auth layer x402 tools build on. Revettr's pattern consumes signed wallet auth profiles from POST /v1/trust as the input to its counterparty scoring. AsterPay's KYA Hook (ERC-8183) is built on POST /v1/attest with custom conditions for agent trust tiering. SettlementWitness's pattern published POST /v1/attest as the pre-transaction wallet auth layer in its Settlement Attestation Record (SAR) flow. Wallet auth qualifies the counterparty before payment, and SAR verifies the deliverable after.

Payment infrastructure commoditizes. Wallet auth differentiates. Stablecoin settlement is a solved problem; wallet auth is the hard part. And unlike Web2 fraud detection, on-chain wallet state is verifiable, composable, and privacy-preserving. You don't need to see transaction history. You just need a signed boolean: does this wallet meet the conditions or not?

That's what Insumer returns. Boolean, not balance. Verified yes or no. Provable and private. Read, evaluate, sign. No secrets. No identity-first. No static credentials. Just condition-based access for autonomous agents operating at scale.

Payment rails let agents transact. Wallet auth determines whether they should. In agent commerce, that distinction becomes infrastructure.

AI Agents Need Wallet Trust Profiles Before They Handle Money

Douglas Borthwick — Sun, 19 Apr 2026 17:21:56 +0000

AI agents can now write code, deploy contracts, and execute payments. They still can't answer one question: should this wallet be trusted with money? Raw capability doesn't solve that. Neither does identity. What's missing is a verification layer that runs before settlement, one that reads wallet state, evaluates conditions, and returns a signed boolean, without private keys or human approval. Claude Opus 4.7 just hit 87.6% on SWE-bench Verified. Impressive, but meaningless if the agent can't prove trustworthiness before touching real money.

The Missing Layer in Agent Commerce

The AI agent payment narrative focuses on rails: x402 protocol, Chainlink CRE workflows, USDC settlement. Every demo shows an agent paying for an API call, executing a transaction, or buying compute. Great. But who verifies the agent's wallet before it gets access?

This is the flaw that drains treasuries and exposes wallets. Without a verification layer in front of settlement, the question isn't whether an agent system gets exploited, it's when. If an agent requests access to a service, a payment gateway, or a privileged API endpoint, the receiving system needs to answer a binary question: is this wallet trusted enough for this action?

That's not an identity problem. It's not an auth problem. It's a condition-based access problem. You don't need to know who the agent is. You need to know what kind of wallet it's operating with. Does it hold stablecoins across multiple chains? Does it participate in governance? Does it stake assets? Has it held NFTs long-term? Those signals indicate wallet maturity, not identity.

The pattern is simple and keeps appearing: verification before settlement. Read wallet state, evaluate conditions, return a signed boolean. Read-only. No signatures. No approvals. No private keys. No human in the loop.

What POST /v1/trust Actually Returns (and Why It's Not a Balance Check)

POST /v1/trust is the wallet trust profile endpoint. It runs a fixed, curated set of checks across stablecoins (USDC and USDT), governance tokens, NFTs, and staking, 36 base checks across 20 chains, extensible to Solana, XRPL, and Bitcoin when those wallet types are provided. (Update, September 2026: 44 base checks across 25 chains, up to 49 across 27 chains with the optional Solana, XRPL, Bitcoin, and Tron wallets.) Each check returns met: true or met: false. No raw amounts. No balance sheet. No exposure.

The response is signed using ECDSA P-256. Public keys are available at /.well-known/jwks.json. Any system receiving the profile can verify the signature client-side using the insumer-verify npm package, four independent checks: signature validity, condition hash integrity, block freshness, and expiry timestamp. Zero dependencies. (Update, September 2026: insumer-verify 1.8.0 and later reports a fifth verdict, the post-quantum companion signature, ML-DSA-65, that every response now carries as pqSig and pqKid beside the ECDSA one.)

This is fundamentally different from POST /v1/attest, which evaluates 1-10 custom conditions you define in the request. /v1/trust answers one question: what kind of wallet is this? It refuses to sign partial data. If any check fails to complete, the entire request fails. That prevents cherry-picking signals or gaming the profile.

Payment rails solved how agents move money. Verification layers will determine which agents are allowed to. Every agent commerce stack will need to answer that question before settlement. Most don't today.

How AI Agents Use MCP and LangChain to Verify Wallets Autonomously

Agents reach the verification layer two ways: the MCP server (npm: mcp-server-insumer, 26 tools, listed in Anthropic's official registry) or the LangChain toolkit (PyPI: langchain-insumer, 26 tools, exposes WalletTrustTool and AttestConditionsTool). An agent negotiating a transaction calls WalletTrustTool to evaluate counterparty trustworthiness before proceeding, no human in the loop.

The demand signal is already here. Cryptact (200,000+ users) just shipped its own MCP server for read-only portfolio queries. MCP crossed 97 million monthly downloads in March 2026. TRON's B.AI launch integrates ERC-8004 for agent identity and x402 for agent payments, the same stack AsterPay and Coinbase are building on. Agent commerce is consolidating around read-only, signed, cross-chain primitives. Wallet verification is one of them.

The x402 Ecosystem Pattern: Verification Before Settlement

The x402 payment protocol (Coinbase's standard for agent-initiated transactions) creates a new verification layer. Agents request payment authorization. Gateways need to evaluate trust before approving settlement. This is where condition-based access infrastructure fits.

AsterPay's KYA implementation is the live proof. They use ERC-8183 (the agentic commerce standard) to structure requests. Before approving EUR settlement for an AI agent transaction, AsterPay's KYA Hook fires a single POST /v1/attest call with 4 conditions: Base USDC balance, coinbase_verified_account, coinbase_verified_country, and gitcoin_passport_score. Those 4 conditions feed 4 of 7 trust score components, contributing up to 44 out of 100 points. Higher score = lower friction. Lower score = additional verification or rejection.

The AsterPay KYA Hook is the first IACPHook with third-party attestation integration. The verification happens server-side. The agent never sees the API call. It just receives approval or denial based on the trust score.

Revettr does the same for counterparty risk. Their API serves wallet analysis to other platforms evaluating transaction risk. When a Revettr customer queries a wallet's risk score, Revettr calls POST /v1/trust in the background. The signed profile feeds their scoring model.

SettlementWitness takes it to pre/post transaction verification (the SAR pattern: Suspicious Activity Report workflows). They call POST /v1/attest as the pre-transaction verification layer before settlement clears. If conditions aren't met, the transaction doesn't proceed.

This is the x402 pattern: verification before settlement. Not auth. Not identity. Condition-based access. Does this wallet satisfy trust thresholds? Return a signed boolean. Let the gateway decide what to do with it.

Why Wallet Verification Needs to Be Read-Only (No Approvals, No Keys)

The hidden flaw in most agent payment systems: they require wallet approvals, signature requests, or private key exposure to verify holdings. That's a security disaster. An agent operating autonomously can't stop mid-workflow to ask a human for approval. And giving an agent access to private keys means one compromised model = drained wallet.

Read-only verification solves this. InsumerAPI never requests wallet signatures. Never asks for approvals. Never touches private keys. It reads public blockchain state (token balances, NFT ownership, staking positions, trust lines), evaluates conditions, and returns a cryptographically signed result.

The signed result is the proof. The ECDSA P-256 signature binds the attestation to the API's public key. Any system can verify the signature using the JWKS public key at /.well-known/jwks.json. The insumer-verify npm package does this client-side with zero dependencies.

The privacy model matters for agents. InsumerAPI returns booleans, not balances. An agent checking whether a wallet holds stablecoins gets back met: true or met: false for each chain. It doesn't see how much USDC the wallet holds. It doesn't see transaction history. It doesn't see wallet connections or interaction graphs. Just threshold results.

Agents operating in the x402 ecosystem need the same guarantees. Trustless verification. No balance exposure. No pivot risk. Signed results that any counterparty can independently verify.

The Missing Piece in Agent Commerce

AI agents don't fail because they lack capability. They fail because no one verifies them before they act.

Payment rails solved movement. This layer solves permission. This is the missing primitive in agent commerce. Verification before settlement isn't an optimization, it's the difference between autonomous systems that scale and ones that can't be trusted with money.

The primitive works today. 33 chains. 24 endpoints. 100,000+ tokens verifiable. Live in production with AsterPay, Revettr, and SettlementWitness. Free tier, no credit card: start at the developer docs.

Wallet Auth for LlamaIndex: Condition-Based Access for AI Agents

Douglas Borthwick — Thu, 16 Apr 2026 22:19:20 +0000

LlamaIndex ships 68 community tool integrations out of the box. Today there is a 69th: llama-index-tools-insumer. Four methods, 33 chains, ECDSA-signed boolean verdicts your agent can verify offline against a public JWKS. Boolean, not balance.

Why an agent needs wallet auth

Autonomous agents increasingly hold wallets, decide what to buy, decide who to trust, and decide when to act. The question "does this wallet meet this specific on-chain condition right now?" is one that agents ask constantly, before discounting, before routing a payment, before admitting a counterparty to a session. Today, most agents answer it by scraping a block explorer, parsing a JSON response, and guessing. That is neither portable nor verifiable.

Wallet auth collapses that question into a single tool call. The agent receives back a cryptographic artifact: a signed yes or no, bound to the exact condition that was evaluated, with a block height and a condition hash. The agent can reason over the result, pass it to a downstream service, or log it for audit, all without ever seeing the raw wallet balance.

What shipped today

One pip install, one ToolSpec, four methods:

pip install llama-index-tools-insumer

The package exposes a single InsumerToolSpec class. Following LlamaIndex convention, each of the four spec_functions becomes a tool the agent can invoke by name:

attest_wallet: run a wallet attestation against one to ten conditions (token balance, NFT ownership, EAS attestation, Farcaster ID). Returns a signed verdict per condition. Maps to POST /v1/attest.
get_trust_profile: fetch a multi-dimensional wallet trust profile (stablecoins, governance, NFTs, staking, plus optional Solana, XRPL, and Bitcoin dimensions). Returns a signed summary. Maps to POST /v1/trust.
list_compliance_templates: discover pre-configured EAS compliance templates (Coinbase Verified Account, Gitcoin Passport, and so on). No API key required.
get_jwks: fetch the public JSON Web Key Set so your agent can verify any signed result offline against the key named by the response's kid.

Drop it into an agent loop

Any LlamaIndex agent that accepts a tool list will accept this one:

from llama_index.tools.insumer import InsumerToolSpec
from llama_index.agent.openai import OpenAIAgent

insumer = InsumerToolSpec(api_key="insr_live_...")

agent = OpenAIAgent.from_tools(
    insumer.to_tool_list(),
    verbose=True,
)

agent.chat(
    "Does wallet 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045 "
    "hold at least 100 USDC on Base?"
)

Under the hood the agent picks attest_wallet, fills in the right arguments, receives back a signed boolean, and reasons over it the same way it reasons over anything else a tool returns. The agent never sees, and never needs to know, how the balance was read, from which chain, or whether the answer came from a cache or a live read. It just sees a yes or a no, with a signature attached.

What the API actually returns

A single live attest_wallet call against vitalik.eth checking USDC on Base ≥ 1:

{
  "ok": true,
  "data": {
    "attestation": {
      "id": "ATST-33DCD2AC57859853",
      "pass": true,
      "results": [{"met": true, "conditionHash": "0x...", "blockNumber": "0x..."}],
      "passCount": 1,
      "failCount": 0,
      "attestedAt": "2026-04-16T21:xx:xx.000Z",
      "expiresAt": "2026-04-16T22:xx:xx.000Z"
    },
    "sig": "...",                         // ECDSA P-256 signature, base64
    "kid": "insumer-attest-v2",            // JWKS key ID
    "pqSig": "...",                       // ML-DSA-65 companion, since Sept 2026
    "pqKid": "insumer-attest-pq1"          // JWKS AKP key ID
  },
  "meta": {"creditsRemaining": 999, "creditsCharged": 1}
}

The pass field tells you the verdict. The sig + kid let any relying party verify the result offline. The conditionHash binds the signature to the exact condition that was evaluated, tamper with the condition and the signature no longer checks. The raw balance is never in the response.

Boolean, not balance

This is the core differentiator worth spelling out for anyone coming from a block-explorer mindset. Standard on-chain APIs return balances, transaction lists, NFT inventories, the underlying state. The consumer is expected to evaluate the predicate themselves and act on the raw numbers.

Wallet auth inverts that. The caller sends the predicate in, the API evaluates it against the live chain state, and the response is a cryptographically signed yes or no. The balance never crosses the wire. That matters for three reasons:

Privacy by default. An agent that needs to know whether a wallet is a "USDC holder" does not also need to see the exact holdings.
Audit without exposure. The signed verdict is verifiable by any party, forever, without re-reading the chain.
Portability. The attestation is the receipt. It survives outside the agent, outside the session, outside the request context it was issued in.

Why LlamaIndex specifically

LlamaIndex is the second-most-adopted agent framework in Python after LangChain, with 48K GitHub stars and a library of nearly 70 official tool integrations. The plug-in shape, one ToolSpec class, multiple spec_functions, published as a standalone pip package, is exactly the pattern a new integration should follow. Anything else looks out of place.

There is also a langchain-insumer package for LangChain developers, an MCP server for any MCP-aware client (Claude Desktop, Cursor, Cline), and an ElizaOS plugin. The LlamaIndex tool completes the four major agent-framework surfaces. Developers can pick the framework they already use and get the same primitive everywhere.

What makes this different from scraping

A naive answer to "does wallet X hold Y?" is to hit a public RPC, call balanceOf, compare to a threshold, return a boolean. That works once, inside one program, for one caller. The answer is not portable, another service has to trust your service blindly, or repeat the RPC call itself. And if you log the answer, the log is worthless to anyone else.

A signed attestation is different. Any service that holds the verdict can verify it independently, offline, forever, against the published JWKS. The condition hash binds the signature to the exact predicate. The block number records when it was read. An audit log of signed attestations is an audit log anyone can verify, including regulators, counterparties, and future instances of the agent itself.

Free to start

Every new API key ships with enough credits to run end-to-end before you spend anything. Attestations cost 1 credit, trust profiles cost 3 credits. Template discovery and JWKS lookups are free.

curl -X POST https://api.insumermodel.com/v1/keys/create \
  -H "Content-Type: application/json" \
  -d '{"email": "you@example.com", "appName": "my-agent", "tier": "free"}'

When a real agent deployment needs more, credits top up via on-chain payment, USDC or USDT on any major EVM chain, USDC on Solana, BTC on Bitcoin, through POST /v1/credits/buy. No Stripe, no signup flow, no fiat rails. Same rails the agents themselves run on.

The three-step primitive

If you take one thing away from this post: wallet auth is read → evaluate → sign. The API reads wallet state from the chain, evaluates it against the caller-specified condition, and signs the verdict. No secrets. No identity-first. No static credentials. The condition is public, the signature binds it to the verdict, and the verdict is the truth, right up until expiresAt, when the agent is free to re-read.

LlamaIndex now gives agents that primitive as a first-class tool. pip install is the whole ceremony.

Canonical URL: https://insumermodel.com/blog/llamaindex-tool-wallet-auth-condition-based-access.html

Package: https://pypi.org/project/llama-index-tools-insumer/

Source: https://github.com/douglasborthwick-crypto/llama-index-tools-insumer

Wallet Auth for Tether's WDK: Pre-Transaction Checks in 20 Lines

Douglas Borthwick — Tue, 14 Apr 2026 20:43:08 +0000

Tether's Wallet Development Kit ships Swap, Bridge, Lending, and Fiat protocols. It does not ship a pre-transaction policy layer. Here is one, as a first-class WDK protocol module, installable from npm.

The gap

Tether's Wallet Development Kit (WDK) is the open-source toolkit that powers tether.wallet, Rumble Wallet, and any other multi-chain self-custodial wallet built on its modular plug-in framework. It is explicitly designed for "humans, machines, and AI agents."

Out of the box, WDK exposes four protocol categories alongside its wallet modules: Swap (Velora), Bridge (USDT0/LayerZero), Lending (Aave), and Fiat (MoonPay). Each is a typed interface that wallet apps compose into their UX.

What is missing is the layer that runs before any of those: a pre-transaction check. Given a wallet and a set of on-chain conditions, return a cryptographically signed yes or no. Before signing a transfer, before approving a contract call, before letting an autonomous agent broadcast anything at all. That primitive is what wallet auth already provides for backends — we just hadn't yet packaged it as a native WDK module.

The fifth protocol

We shipped @insumermodel/wdk-protocol-wallet-auth — a WDK protocol module that exposes the wallet auth primitive (read → evaluate → sign) inside the WDK shape. Same protocol pattern as Swap, Bridge, Lending, and Fiat. Two methods, two jobs:

attest({ address, conditions }) — evaluate 1–10 on-chain conditions against a wallet, get back a signed pass/fail attestation. Maps to POST /v1/attest.
trust({ address }) — get a multi-dimensional trust profile: 36+ signed checks across stablecoins, governance, NFTs, and staking. Maps to POST /v1/trust.

Install it like any other WDK protocol module:

npm install @insumermodel/wdk-protocol-wallet-auth

And use it before any state-changing call:

import WalletAuth from '@insumermodel/wdk-protocol-wallet-auth'

const walletAuth = new WalletAuth({ apiKey: process.env.INSUMER_API_KEY })

// Before broadcasting a transfer, verify the counterparty:
const { passed, sig, kid } = await walletAuth.attest({
  address: counterparty,
  conditions: [
    {
      type: 'token_balance',
      contractAddress: '0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48',
      chainId: 1,
      threshold: '1000',
      decimals: 6,
      label: 'USDC >= 1000'
    }
  ]
})

if (!passed) throw new Error('counterparty failed wallet auth check')
// sig + kid are the audit trail: verifiable offline against the JWKS.

That is the complete surface. Twenty lines is generous — the real surface is three: construct, call, check the boolean. Everything else the module does — bound account resolution, multi-chain address routing, error envelope unwrapping, optional JWT output, optional EIP-1186 Merkle proofs — is plumbing.

The napkin version, collapsed into one line:

if (!(await walletAuth.attest({ address, conditions })).passed) block()

Same operation. Block is whatever your app does when a check fails — throw, redirect, refund, tell the user to top up. The protocol itself doesn't prescribe the reject path. It just tells you, with a signature, what the right answer is.

Why this matters for WDK wallets

There are three distinct buyers for a pre-transaction check inside a self-custodial wallet, and WDK touches all three:

1. Agent wallets. WDK's own framing puts "machines and AI agents" alongside humans. When an autonomous agent holds keys, the operator wants programmable constraints the agent cannot argue its way around — and a cryptographic audit trail the operator can verify after the fact. "Only send to counterparties that pass trust check X" is a real constraint. The signed attestation is the receipt.

2. Consumer apps on WDK rails. A creator-payment tool like Rumble Wallet, a remittance app, a treasury product — any WDK-based app that serves end users and wants compliance cover needs something between "user clicks send" and "transaction broadcasts." Travel Rule. Sanctions. Counterparty risk. A drop-in module that returns a cryptographically verifiable attestation is cheaper than building it in-house and, crucially, portable — the attestation survives outside the wallet.

3. Receive-side trust display. The most interesting call is not on your own send, it is on someone else's incoming payment. A creator wants to know the wallet sending them money is not freshly funded from a mixer. A merchant wants to know the incoming USDT is not about to be frozen. That is trust() on the inbound address, surfaced in the UI before the user accepts the payment.

Why it fits WDK's shape

WDK's protocol modules are not hooks or middleware. They are typed interfaces that wallet apps compose into their own flow. Swap has quoteSwap() and swap(). Lending has supply(), borrow(), repay(). Each is a verb the app calls when it needs that capability.

WalletAuthProtocol follows the same pattern. The app calls attest() or trust() before the action it wants to gate. The protocol itself never touches private keys, never signs transactions, never broadcasts. It runs before the signing flow, not inside it. This matters: it means the module is additive and composable with every other WDK protocol, not a replacement or a wrapper.

The abstract base class (WalletAuthProtocol) is shape-compatible with WDK's existing SwapProtocol, BridgeProtocol, LendingProtocol, and FiatProtocol base classes in @tetherto/wdk-wallet/protocols. It is intentionally structured so that it can be proposed upstream as a blessed fifth protocol module. The reference implementation (InsumerWalletAuthProtocol) is a clean subclass that any WDK app can install from npm today.

What gets signed

Every attest() result carries an ECDSA P-256 signature and a key ID. Every trust() result does the same. Verification is offline — any JOSE or JWT library can check the signature against the public JWKS at insumermodel.com/.well-known/jwks.json. There is no server call, no account, no API key required to verify. Only to create.

If you ask for jwt: true, the attestation also comes back as a standard ES256 JWT with the signed result as JWT claims. That turns the output into a drop-in bearer token: Kong, Nginx, Cloudflare Access, or AWS API Gateway can verify it the same way they verify any other JWT, without knowing anything about wallet auth at all.

Supported chains

InsumerAPI covers 33 chains today: 30 EVM networks (Ethereum, Polygon, Arbitrum, Optimism, Base, Avalanche, BNB, and the rest of the major EVM set), plus Solana, XRPL, and Bitcoin. WDK's own chain coverage overlaps heavily with this — every EVM chain you hit via wdk-wallet-evm is already attestable today, same with wdk-wallet-solana and wdk-wallet-btc, and the module also covers XRPL natively even though WDK doesn't yet ship an XRPL wallet module.

Three WDK surfaces do not yet have InsumerAPI coverage: TRON, TON, and Lightning/Spark. Apps on those runtimes can still use attest() and trust() against EVM, Solana, XRPL, or Bitcoin addresses the user holds — they just can't yet condition on, say, a TRC-20 balance. Those three chains are on our roadmap and the request shape will stay identical when they land.

The request shape is already identical across everything that is covered. EVM, Solana, Bitcoin, and XRPL addresses ride in their own fields (wallet, solanaWallet, bitcoinWallet, xrplWallet) and the module routes them automatically based on each condition's chainId.

Paying for it

The free tier ships 10 attestation credits to every new key so you can kick the tyres end-to-end before spending anything. When a wallet app needs more, credits are purchased on-chain — no Stripe, no fiat rails, no signup flow. The POST /v1/credits/buy endpoint accepts transfers of USDC or USDT on any major EVM chain (auto-detected from the transaction), USDC on Solana, or BTC on Bitcoin, and credits post as soon as the transaction confirms on-chain. Same rails the wallets themselves run on.

Where next

The package is public on npm and GitHub, and the README has the full API reference. Three things on the roadmap:

Upstream proposal. The WalletAuthProtocol base class is intentionally a clean extension of the @tetherto/wdk-wallet/protocols pattern. The next step is proposing it upstream as a blessed fifth protocol module on the WDK repo.
React Native and Bare runtimes. The module uses globalThis.fetch by default and accepts a fetch override, so it already works in WDK's React Native and Bare Kit environments. A first-party example in wdk-starter-react-native is the natural next doc.
Receive-side widget. The most visually obvious use case — a small trust badge surfaced in the wallet UI when a payment comes in — is a UI component, not a protocol. That will ship separately, layered on top of the protocol module.

If you are building a wallet on WDK and any of the three buyer profiles above apply, the module is one install away. And if you are on Tether's side of the fence and want to see Wallet Auth land in the official protocol base classes, open an issue on the repo and let us know.

OAuth proves who you are. Wallet auth proves what you hold. WDK now has both sides of the flow.