DEV Community: Douglas Borthwick

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, kid: "insumer-attest-v1", JWKS at /v1/jwks. 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 profile across 21 EVM chains plus Solana, XRPL, and Bitcoin.
Verify the signature. Every response carries an ECDSA P-256 signature under kid: insumer-attest-v1. The skill makes Claude verify against the published JWKS at https://insumermodel.com/.well-known/jwks.json, never trust the raw JSON body.
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.
Use stable kid pinning. The skill pins kid: insumer-attest-v1 as the primary signing key and shows Claude how to resolve future kids through the JWKS endpoint without breaking offline verification.
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:

{
  "attestation": {
    "wallet": "0x...",
    "chain": "base",
    "pass": true,
    "results": [
      { "type": "erc20", "met": true, "evaluatedCondition": {...} }
    ],
    "conditionHash": "0x...",
    "blockNumber": 19234567,
    "blockTimestamp": 1745000000,
    "issuedAt": 1745000003,
    "expiresAt": 1745001803,
    "kid": "insumer-attest-v1",
    "sig": "..."
  }
}

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 33 chains buys you

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

26 EVM chains with optional Merkle storage proofs (Ethereum, Base, Arbitrum, Optimism, Polygon, BNB Chain, Avalanche, and others).
4 more EVM chains without proofs.
Solana for SPL token holdings and SOL.
XRPL for trust lines and stablecoin holdings (RLUSD, USD-issued lines).
Bitcoin for native BTC holdings.

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 starter credits plus 100 /v1/attest calls 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 33 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. 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.

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 insumer-attest-v1 key.

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": "...",
    "kid": "insumer-attest-v1"
  },
  "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.

Would You Trust Your Agent? KYA Is Real.

Douglas Borthwick — Fri, 10 Apr 2026 13:59:16 +0000

Everyone is deploying AI agents. Almost no one is verifying them. And those agents are already moving money. You wouldn't hand your wallet to a stranger. KYA, Know Your Agent, is real, and the speed at which the ecosystem is converging on it is the proof.

The convergence is here

The headlines landed in a pile this March. CZ declared AI agents will dominate crypto payments. Visa announced readiness for agent transactions, while Coinbase pitched a fundamentally different internet. Mastercard introduced "Verifiable Intent" for autonomous commerce. Crossmint shipped agent virtual cards. MoonPay launched an Open Wallet Standard. Coinbase's x402 protocol and Stripe MPP are already being compared head-to-head.

Every one of these is a payment rail. None of them check whether the agent should be trusted before money moves. That is the gap KYA fills.

The rails are here. The trust layer isn't.

You can authenticate an agent. You can resolve its DID. You can confirm the public key it signs with. None of that tells you whether the agent's wallet still holds the funds it claimed yesterday. None of it tells you whether the source code was compromised in last week's dependency update. None of it tells you whether the operator's delegation has expired, whether the counterparty has been added to a sanctions list, whether the agent has actually delivered on past commitments, or whether the reasoning chain that led to its current action is sound.

The nine dimensions of agent trust

Each dimension is answered by an independent issuer in the open multi-attestation spec at insumer-examples #1, with a JWKS endpoint anyone can verify offline:

Wallet state. What does this agent's wallet hold right now? Token balances, NFTs, staking positions, DeFi activity, governance participation, across 33 blockchains. Provider: InsumerAPI.
Compliance risk. Is the counterparty on a sanctions list? OFAC, EU, and UN screening, plus domain hygiene and IP reputation. Provider: Revettr.
Identity verification. Who actually controls this agent? DID resolution, delegation chains, interaction patterns, completion ratios. Provider: AgentID.
Security posture. Has the agent's source code been scanned for vulnerabilities, secrets, and unsafe patterns? Provider: AgentGraph.
Governance. Is the agent operating within an authorized delegation chain? Principal identity, policy compliance, spending limits, full chain of custody. Provider: APS (Agent Passport System).
Job performance. Has the agent actually delivered quality work in the past? Task completion rates, accuracy metrics, performance history. Provider: Maiat.
Settlement history. Has the agent followed through on past commitments? Operation binding, delivery verification, settlement witness receipts. Provider: SAR.
Behavioral trust. Is the agent's wallet a coordinated bot or a real entity? Signal depth and risk intensity, sybil detection across 12 EVM chains and Solana. Provider: RNWY.
Reasoning integrity. Is the agent's decision chain sound? Adversarial multi-model critique, logical consistency, temporal freshness. Provider: ThoughtProof.

Nine dimensions, nine independent providers, nine signed attestations. No single provider sees all of them. No central authority makes the trust call. The consumer trusts no one and verifies everything.

Identity is one dimension. Trust is nine.

The momentum is the proof

Building one trust dimension is hard. Building nine in coordination is harder. Getting nine independent companies to agree on a single envelope format and start populating it with real signed attestations is the kind of thing standards bodies usually take years to do.

The open multi-attestation spec opened in March. Three weeks ago we wrote about four issuers in one verification pass. Today the count is nine issuers in the envelope and five with shipped wallet binding. Each of the five accepts a wallet address as input and returns an attestation about that specific wallet, signed against their published JWKS. The remaining four cover their dimensions through different integration paths and are converging on wallet integration through bilateral interop work. All nine are live. All nine sign attestations. All nine are consumed by a single orchestrator behind one API call.

That convergence speed is not coincidence. It is the demand signal. Nine independent companies do not build around the same wire format in 30 days unless the market is asking for it loudly. KYA is real because the people building it are racing to ship it.

And the production reality is already ahead of the discussion. AsterPay's KYA Hook runs in production for ERC-8183 agentic commerce today, with InsumerAPI feeding 4 of 7 trust score dimensions through cryptographic attestations. Manual KYB replaced with signed signals, one API call, no human review when the wallet qualifies. KYA is not a thought experiment. It is a shipping product.

Where each issuer stands today

Five of the nine ship signed wallet binding directly: InsumerAPI, Revettr, AgentID, AgentGraph, and APS. Each accepts a wallet address as input and returns an attestation about that specific wallet. The other four serve their dimension through complementary paths:

Maiat ships wallet acceptance via a long-standing ?address= parameter and falls back to a reference identity when the wallet has no Maiat job history.
SAR accepts the wallet via an envelope-level counterparty field, surfaced in the response but not yet bound into the signed payload.
RNWY's behavioral trust model is keyed to canonical agent IDs from major registries (ERC-8004, Olas, Virtuals), with bilateral interop in progress with AgentGraph for cross-provider lookup.
ThoughtProof's reasoning verification is wallet-agnostic by design. Its attestation surface is the reasoning chain for a specific tool call, which is a property of the action, not the actor.

The runtime ratio for any individual agent depends on whether that specific agent is registered with each issuer. The spec coverage is solid: nine independent providers, all coordinating around a single open envelope, all signing JWKS-verifiable attestations today.

One API call

Asking nine independent questions about an agent could mean nine integrations, nine API keys, nine retry policies. That is not how it works. The multi-attestation spec defines a single envelope format that lets all nine issuers respond in parallel. One call in. Nine signed attestations out. Every signature verifiable offline against each issuer's published JWKS, with no callback to the orchestrator at verification time.

The orchestrator code is open source. Both files use only Node built-ins (crypto and https from the standard library, no external imports):

wallet-resolve.js takes a wallet address and fans out to the nine issuers in parallel
multi-attest-verify.js verifies each signed payload against the right JWKS

What the consumer side taught the spec

Wiring nine issuers behind a single orchestrator surfaces a pattern that the current schema does not capture: whether an attestation actually evaluated the wallet you sent is consumer-relevant metadata. From the consumer's perspective, all three states (wallet-bound, envelope-acknowledged, reference data) look identical at the signature layer. A valid JWS from a known issuer with a known kid resolving against a known JWKS endpoint. That is not enough to make a trust decision.

The proposal we posted to A2A #1628 is a subject_binding field on each signal entry, with three states:

wallet_bound: the issuer evaluated the wallet you sent and signed the result over it
wallet_acknowledged: the wallet flowed through the response envelope but the signature does not bind it
reference: the issuer returned data not specific to the wallet

Consumers can then weight wallet-bound dimensions highest, treat acknowledged ones as informational, and aggregate reference attestations as background context.

Try it on a wallet

SkyeProfile is the live consumer of the multi-attestation spec. (For the architectural deep-dive on how the orchestrator dispatches nine specialists in parallel, see What Is SkyeProfile?.) Each dimension card on the page shows a binding badge so the consumer can weight signals correctly:

Green ("Your Wallet"). The issuer signed an attestation about the specific wallet you submitted.
Amber ("Acknowledged"). The wallet flowed through the response envelope but the signature does not bind it.
Gray ("Spec Demo"). The issuer returned reference data, either because they have no entry for your wallet or because their integration uses a non-wallet identifier.

The page renders Vitalik's wallet on load as the canonical reference. Vitalik is not registered with any of the agent issuers, so the visible ratio is two wallet-bound, one acknowledged, six spec demo. Below the reference, a user-input form takes any EVM or Solana wallet you paste and computes the live ratio for that specific address. If you have a wallet for an agent you actually want to evaluate, paste it. Each card with a registered binding flips from gray to green in real time.

Why this matters

Most discussions of agent trust focus on identity. Who is the agent. What credentials does it have. What does its DID look like. Identity is necessary but it is not sufficient. An agent with a verified identity can still drain its wallet, fail its delegation check, get sanctioned, run compromised code, or under-deliver on what it was paid for. Identity tells you the agent's name. KYA tells you whether the agent should be trusted right now.

The Drift Protocol exploit on March 31 is the cleanest recent illustration of what happens when the trust layer is missing entirely. Two hundred and eighty-six million dollars moved in twelve minutes because signers had no way to verify counterparty trust before approving transactions. KYA would not have auto-prevented Drift. KYA is a check primitive, not a tripwire. But the layer that would have given Drift's signers the data to make a different decision is the layer that did not exist. KYA is that layer.

The composability primitive is no longer theoretical. It is running in production today, against real agent wallets, with the open multi-attestation spec converging in real time. Nine independent issuers, one envelope format, one API call, every signature verifiable offline.

Payments are getting faster. Trust isn't. That is the gap. Before you trust an agent with anything that matters, run the full check.

Quantum Breaks Static Credentials. Wallet Auth Was Never Static.

Douglas Borthwick — Thu, 09 Apr 2026 19:03:13 +0000

A Nobel Prize-winning physicist warned this week that Bitcoin could be among the earliest real-world targets of quantum computing. Google published research showing that fewer than 500,000 qubits could derive a private key from a public key in under nine minutes. The Bitcoin community is debating BIP 360, a hard fork to hide public keys behind Merkle roots. The Federal Reserve published a paper on "harvest now, decrypt later" attacks against blockchain networks. The quantum threat is no longer theoretical. But the vulnerability it exploits is not new. It is the oldest assumption in digital security: that a single, long-lived cryptographic secret can protect everything, forever.

What quantum actually threatens

Every quantum attack vector against Bitcoin comes back to the same architectural assumption: one private key, held for years, protecting all funds associated with it.

The specific attack works like this. When a Bitcoin transaction is broadcast, the sender's public key becomes visible in the mempool before the transaction is confirmed on-chain. A sufficiently powerful quantum computer running Shor's algorithm could derive the corresponding private key from that public key. Google's research suggests this could take roughly nine minutes. The average Bitcoin block takes ten.

That is the window. Nine minutes of exposed public key, and every satoshi behind it is at risk.

But the problem runs deeper than the mempool. The Federal Reserve's research on "harvest now, decrypt later" points out that every historical Bitcoin transaction with an exposed public key is permanently recorded on-chain. An adversary could record those public keys today and wait for quantum hardware to mature. Even if Bitcoin migrates to post-quantum signatures tomorrow, the old transactions are already written. The chain is immutable. The exposure is permanent.

BIP 360 addresses the forward-looking problem by introducing Pay-to-Merkle-Root (P2MR), a new output type that hides the public key inside a Merkle tree until the moment of spending. BTQ Technologies implemented it on testnet in March 2026. But deploying it requires a hard fork, coordination across every exchange, hardware wallet, and node operator on the network. Adam Back, the Hashcash inventor, says the migration clock is ticking even though he believes the threat itself is still decades away. The debate is not about whether to prepare. It is about whether Bitcoin's governance can move fast enough.

The design assumption quantum breaks

Zoom out from Bitcoin specifically. The quantum threat is not unique to one chain or one algorithm. It is a threat to a design pattern: systems that depend on a single, long-lived cryptographic secret as the root of all trust.

Private keys. API keys. Session tokens. Passwords hashed with algorithms that will eventually fall. Any system where one secret, if compromised, unlocks everything, and where that secret must persist for months or years to remain useful.

This is what makes quantum different from classical attacks. A classical attacker who steals your password gets your password. A quantum attacker who factors your public key gets your private key, which is equivalent to getting every transaction you will ever make from that address. The permanence of the secret is the vulnerability.

Wallet auth inverts this

Wallet auth does not protect secrets. It eliminates them. The primitive is: read on-chain state, evaluate it against conditions, return a signed result. The result is a boolean. Did this wallet meet the condition, or not.

There are three properties of this architecture that make the quantum threat structurally irrelevant.

First: the attestation is ephemeral. Every signed result from InsumerAPI carries a 30-minute expiration. After that, it is worthless. There is nothing to harvest. An adversary recording attestations today gains a collection of expired booleans. Compare this to a Bitcoin public key, which protects funds indefinitely. The harvest-now-decrypt-later strategy assumes the encrypted data will still be valuable when the decryption becomes possible. A boolean that says "this wallet held 100 USDC at 2:47pm on April 9th" has no exploitable value at any future date.

Second: the signing algorithm is swappable. InsumerAPI currently signs attestations with ES256, an ECDSA signature on the P-256 curve. The same algorithm family that quantum threatens in Bitcoin. But there is a critical difference in how it is deployed. Verifiers check the signature against a public key published at a JWKS endpoint. To migrate to a post-quantum algorithm like ML-DSA (the NIST-standardized version of CRYSTALS-Dilithium), the change is: update the signing key, publish the new public key to the JWKS endpoint, update the algorithm identifier. Every verifier that fetches the JWKS picks up the new key automatically. No hard fork. No coordination across thousands of independent node operators. No BIP proposal. One deployment.

Third: even a broken signature reveals nothing exploitable. Suppose a quantum computer cracks the ES256 signature on an InsumerAPI attestation. What does the attacker learn? That a particular wallet met or did not meet a particular condition at a particular time. The attestation does not contain private keys. It does not contain balances. It does not contain any credential that grants access to funds. The boolean is the entire payload. Breaking the signature proves the boolean was not tampered with. It does not unlock anything.

Static secrets break. Ephemeral proofs don't.

Continuous re-verification

The ephemeral property becomes even more pronounced in session-based systems. Consider a multi-party agent session where every participant must prove their wallet meets on-chain conditions to enter. The session does not check once and grant permanent access. It re-verifies. Agents that no longer qualify are ejected. The session is never static.

Even if an attacker cracked one attestation signature during the session window, the session has already moved on. The next re-verification produces a fresh attestation with a fresh signature. There is no single credential to target because the credential regenerates continuously from live on-chain state.

This is the architectural difference. Bitcoin protects a static secret that must survive forever. Wallet auth evaluates a live condition that only needs to survive for its verification window.

The condition hash

There is one more piece worth noting. Every InsumerAPI attestation includes a condition hash: a SHA-256 digest of the exact condition that was evaluated, with keys sorted canonically. This hash is embedded in the signed payload.

Even if the signature algorithm were compromised, the condition hash serves as an independent tamper-detection mechanism. A verifier can reconstruct the expected condition, hash it, and compare. If the condition was altered, the hash will not match, regardless of whether the signature is valid. This is defense in depth that does not depend on any single cryptographic primitive.

Why this matters now

The quantum timeline is debated. Estimates range from five years to twenty. Bernstein says three to five years to transition. Google is setting a 2029 internal deadline for post-quantum migration across its authentication services. NIST has finalized the post-quantum standards. Naoris Protocol launched the first Layer 1 built entirely on ML-DSA. U.S. federal agencies face an April 2026 deadline to submit their transition plans.

The migration is happening. The question is how painful it will be for each system.

For Bitcoin, it is a hard fork, a years-long coordination effort, and a permanent legacy of exposed historical public keys that no migration can fix.

For wallet auth, it is an algorithm swap behind a JWKS endpoint. The primitive does not change. You send conditions in, you get a cryptographically verifiable result out. The verification is the same whether the signature is ECDSA or Dilithium. Read, evaluate, sign. The operation is the same. Only the signature changes.

That is not quantum-resistant by accident. It is quantum-resistant by architecture. When the cryptographic ground shifts, systems built on permanent secrets have to rebuild from the foundation. Systems built on ephemeral proofs just swap the signature.

Quantum breaks systems built on secrets. Wallet auth was built without them.

What Is SkyeProfile? Eight Experts, One Call, Complete Wallet Trust

Douglas Borthwick — Wed, 08 Apr 2026 22:52:41 +0000

A balance check is not due diligence. Knowing a wallet holds tokens tells you almost nothing about whether it should be trusted. SkyeProfile changes the question from what does this wallet hold? to what kind of wallet is this? One API call dispatches eight independent specialists, each evaluating a different dimension of wallet trust, each signing their own attestation with their own cryptographic key. The result is not a score. It is a complete, verifiable, multi-dimensional trust profile. Think of it as hiring a team of experts with a single phone call.

The General Contractor Model

When you build a house, you do not hire one person to do everything. You hire a general contractor. The contractor coordinates the electrician, the plumber, the structural engineer, the roofer, the HVAC specialist, and the inspector. Each one brings deep expertise in their domain. Each one signs off on their own work. The contractor does not pretend to be all of them. The contractor orchestrates.

SkyeProfile is the general contractor for wallet trust.

When your system needs to decide whether to trust a wallet, SkyeProfile dispatches eight specialized providers in parallel. Each provider evaluates the wallet from their dimension of expertise. Each provider returns an independently signed attestation. SkyeProfile assembles the results into a single response. It does not generate the trust signals. It orchestrates them.

The foundation underneath all of it is InsumerAPI. It provides the wallet state attestation: what the wallet holds across thirty-three blockchains, evaluated against over forty checks, returned as a cryptographically signed result. The primitive is simple: read blockchain state, evaluate conditions, sign the result. That is wallet auth. Every other dimension branches off from that foundation. The plumber needs to know the house has walls before running pipe. The identity provider needs to know the wallet exists on-chain before evaluating who controls it.

The Crime Scene Analogy

Consider how investigators process a crime scene. The first officer secures the perimeter. Then the specialists arrive. A forensics team handles physical evidence. A ballistics expert examines projectiles. A medical examiner determines cause of death. A digital forensics analyst pulls data from devices. A toxicologist screens for chemicals. Each expert writes an independent report. Each expert signs their findings. No single expert sees the full picture, but the lead investigator assembles all reports into a comprehensive case file.

This is exactly how SkyeProfile works. The wallet address is the scene. Each provider is a specialist. Their signed attestations are independent expert reports. SkyeProfile is the lead investigator assembling the case file. And just like a real investigation, you can verify each expert's credentials and methodology independently. You do not have to trust the lead investigator's summary. You can check the signatures yourself.

Eight experts. One call. Verifiable results.

Eight Dimensions, Eight Specialists

Each dimension of SkyeProfile is handled by a provider that does nothing but that one thing, all day, every day. Here is the team:

Wallet State is the foundation. Powered by InsumerAPI, it evaluates what the wallet holds across thirty-three blockchains. Stablecoins, governance tokens, NFTs, staking positions, DeFi activity. Over forty checks. ES256-signed. This is the bedrock the other dimensions build on.

Behavioral Trust asks whether the wallet behaves like a real participant or a sybil. RNWY maintains a dual-score model across over one hundred fifty thousand agents spanning twelve EVM chains and Solana. Signal depth measures behavioral observability. Risk intensity measures fraud probability. A well-funded wallet with no behavioral history is not an error. It is a signal.

Identity Verification determines who controls the wallet. AgentID resolves DID chains, delegation patterns, interaction histories, and completion ratios. The attestation links a wallet to a verifiable identity without exposing personal data. EdDSA-signed.

Security Posture scans for vulnerabilities. AgentGraph performs source code scanning on agent wallets, categorizing findings by severity. A wallet controlled by an agent with known vulnerabilities is a different risk profile than one with a clean security audit. EdDSA-signed.

Governance verifies the wallet operates within a sanctioned authority chain. The Agent Passport System traces delegation lineage from human principal to agent action. Who authorized this wallet? What are its spending limits? Is its policy chain intact? EdDSA-signed with a full PolicyReceipt chain and Merkle commitment.

Reasoning Integrity is the most forward-looking dimension. ThoughtProof runs adversarial multi-model critique to determine whether the agent behind a wallet is making sound decisions. An agent can execute correctly but reason incorrectly. This catches the difference. EdDSA-signed.

Job Performance asks whether the agent delivers quality work. Maiat tracks task completion rates, accuracy metrics, and performance scores from real job execution through an ERC-8183 escrow system. Past performance is the best predictor of future performance. ES256-signed.

Settlement History answers the ultimate question: did this wallet deliver what it was paid for? SAR maintains a receipt chain of operation bindings, delivery verifications, and settlement witness receipts. EdDSA-signed with verdict scoring.

Why One Source Is Not Enough

The current market for wallet trust is fragmented. You can check a wallet's balance. You can look up its transaction history on a block explorer. You can run it through a sanctions list. Each of these is a single dimension. Each one, alone, is incomplete.

A wallet can be well-funded and malicious. A wallet can have clean transaction history and be controlled by a compromised agent. A wallet can pass sanctions screening and still be a sybil. A wallet can hold governance tokens and have no delegation authority.

This is the problem with single-source trust. It is like hiring only the electrician to inspect the house. The wiring might be perfect. The foundation might be crumbling.

SkyeProfile solves this by querying across dimensions simultaneously. You do not get a single number. You get eight independent assessments from eight specialized providers. You decide which dimensions matter for your use case. A DeFi protocol might weight wallet state and settlement history heavily. An agent marketplace might prioritize reasoning integrity and job performance. A compliance system might focus on identity verification and governance.

A wallet is not a balance. It is a history.

How It Actually Works

One API call. One wallet address. SkyeProfile calls all eight providers in parallel. Each provider evaluates the wallet independently. Each provider signs their attestation with their own cryptographic key (ES256 or EdDSA). Each provider publishes their public key at a JWKS URI. The response arrives as a unified payload with eight independently verifiable attestations, formatted as a multi-attestation envelope.

The critical design choice: you do not have to trust SkyeProfile. Each attestation includes the provider's JWKS URI and key ID. Fetch the public key. Verify the signature. You can do this offline, with no callback to SkyeProfile or any provider. The signatures are the proof.

If a provider is temporarily unavailable, that dimension returns as unavailable while the remaining seven still return valid, signed attestations. Graceful degradation. A house inspection does not fail because the roofer is stuck in traffic. The other six specialists still do their work.

Wallet state attestations from InsumerAPI are valid for thirty minutes. Behavioral scoring from RNWY can hold for up to twenty-four hours. JWKS keys are cacheable per standard HTTP cache headers. Once you have fetched the public keys, verification is fully offline.

Better Than What Exists Today

The alternatives fall into two categories: too narrow or too opaque.

Too narrow means single-dimension tools. Balance checkers tell you what a wallet holds but nothing about how it behaves. Sanctions screening tools tell you whether an address is flagged but nothing about its operational history. Sybil detectors tell you whether an address is real but nothing about its governance authority. Each tool requires a separate integration, a separate vendor relationship, and a separate trust assumption.

Too opaque means credit-score-style systems that return a single number from a black box. You get a 742. What does that mean? Which inputs drove it? Can you verify the methodology? Can you weight dimensions differently for your use case? With a single score, you cannot. You either trust the provider's model or you do not.

Everything else forces you to choose between incomplete or unverifiable. SkyeProfile removes that tradeoff. Eight dimensions, eight independent providers, eight verifiable signatures. You see exactly which providers assessed the wallet, what each one concluded, and you can verify every signature independently. No black box. No single score. No trust required. You send a wallet address in. You get cryptographically verifiable results out.

Built to Grow

The specification is open. Any provider that implements JWKS-published keys and signed attestations (ES256 or EdDSA) can submit their dimension for verification and inclusion. The architecture does not cap at eight. It caps at however many meaningful dimensions of wallet trust exist. Working code examples are in the insumer-examples repository.

Two additional dimensions are already in development: transaction history (counterparty graph analysis) and compliance screening (OFAC and sanctions). When they ship, existing integrations automatically receive those dimensions in their responses. No code changes. No version bumps. Two more specialists, two more signed attestations, a more complete picture.

This extensibility is the difference between a product and a specification. A product locks you into one vendor's view of trust. A specification lets the ecosystem define trust dimensions as they emerge. Six months ago, reasoning integrity was not a dimension anyone was evaluating. ThoughtProof built it, proved it, and plugged into SkyeProfile. The next dimension no one is thinking about yet will follow the same path.

The Foundation: InsumerAPI

InsumerAPI is not just one of the eight dimensions. It is the layer that makes the other seven meaningful. Without a verified view of wallet state, behavioral trust has no context. A sybil score means nothing if you do not know what the wallet holds. Identity verification has no anchor. Who controls this wallet matters only if the wallet controls real value. Governance has nothing to attach to. A delegation chain is academic if there are no assets at the end of it. Security posture, reasoning integrity, job performance, settlement history: each one is stronger, more actionable, and more trustworthy because InsumerAPI establishes ground truth first. Cryptographically signed. Cross-chain. Independently verifiable.

Without InsumerAPI, you can compose signals. With it, you can trust them.

InsumerAPI reads blockchain state across thirty-three chains, evaluates conditions, and signs the result. This primitive, the signed boolean, is the irreducible building block. SkyeProfile composes that building block with seven other signed attestations into something greater than the sum of its parts. But the composition only works because the base layer is cryptographically verified. Remove it, and the other seven dimensions are opinions. Keep it, and they are evidence.

Pre-Transaction Trust

You are about to send $10,000 to an agent wallet. Run SkyeProfile. Settlement history says it has delivered on twelve of twelve previous jobs. Behavioral trust confirms it is not a sybil. Security posture comes back clean. Reasoning integrity passes. You proceed. That entire check took one API call and returned eight signed attestations you can verify offline. Without it, you are trusting a wallet address.

Every transaction should start with a trust check. Before an agent pays another agent. Before a protocol grants API access. Before a marketplace accepts a new seller. Before a governance system weights a vote. The question is always the same: should this wallet be trusted for this action?

SkyeProfile is that check. Eight experts, one call, complete wallet trust. Not a score. Not a label. Not a black box. Eight independently signed, cryptographically verifiable attestations from eight specialized providers who do nothing but evaluate their dimension of trust. This is condition-based access at its fullest: the wallet either meets the conditions or it does not, and every answer is signed.

The general contractor model works because no single expert knows everything, but together they cover every dimension that matters. SkyeProfile works the same way. And like any well-built house, it is designed so you can add rooms as the needs grow.