DEV Community: Douglas Borthwick

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 adds a new category: Wallet Auth. Same shape 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 category. 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 category 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.

How SkyeMeta Built a SCIF for AI Agents on InsumerAPI

Douglas Borthwick — Wed, 01 Apr 2026 12:26:46 +0000

AgentTalk is condition-based access applied to agent-to-agent sessions. Built by SkyeMeta on InsumerAPI, it verifies that every agent in the room meets the same on-chain conditions before information moves — the same model as a Sensitive Compartmented Information Facility (SCIF), where everyone inside has been verified to the same clearance level. Two agents or two hundred. Bilateral negotiations, working groups, town halls. The entire product is built on three InsumerAPI calls: POST /v1/attest for the creator, POST /v1/attest for each joiner, and POST /v1/attest again for re-verification.

The problem: identity is not qualification

Agent protocols handle trust with shared secrets. Agent A presents an API key. Agent B decides whether to trust it. This is identity-based authentication — it proves who you are, not what you are qualified to handle.

In regulated environments, this fails. A trading agent needs to prove collateral positions, not just identity. A legal agent needs to prove its principal holds compliance credentials. A defense agent needs to prove clearance-equivalent attestations. None of these are identity questions.

AgentTalk replaces identity-based auth with qualification-based access. Every agent in the room proves they meet a set of verifiable, on-chain conditions before any information moves. The conditions are composable — up to 10 per channel, across any mix of 33 chains.

The architecture: three API calls

AgentTalk is a thin session layer over InsumerAPI. The entire product runs on three endpoints that each call POST /v1/attest under the hood:

Declare (POST /api/agenttalk/declare): Creator opens a channel with conditions, a wallet address, and a capacity (2 for bilateral, or as many as the room needs). AgentTalk calls InsumerAPI POST /v1/attest with format: "jwt" to verify the creator's wallet. If the attestation passes, a channel is created with a channelId and a conditionsHash (SHA-256 of the canonical JSON conditions). With autoStart: true, the session is live immediately and agents join on the fly.
Join (POST /api/agenttalk/join): Agents submit their wallets to the channel. AgentTalk calls InsumerAPI POST /v1/attest for each joiner's wallet. Each agent's attestation JWT is stored with the session. For standard channels, the session activates when capacity is reached. For autoStart channels, agents join the live session immediately.
Enforce (POST /api/agenttalk/session): Re-verify the session at any time. AgentTalk calls POST /v1/attest for every wallet against the original conditions. Agents who no longer qualify are ejected — the session continues for everyone else. The creator can also kick agents (POST /api/agenttalk/session with action: "kick"), and agents can leave voluntarily (action: "leave").

Only the channel creator needs an InsumerAPI key. Every other agent provides only a wallet address — the creator's key covers all attestation calls. Free tier: 10 calls, no signup.

The combination is the security

A SCIF doesn't check one thing. AgentTalk supports up to 10 composable conditions per channel:

POST /api/agenttalk/declare
{
  "wallet": "0x...",
  "conditions": [
    { "type": "token_balance", "chainId": 1,
      "threshold": 1000000, "decimals": 6,
      "label": "USDC >= $1M on Ethereum" },
    { "type": "token_balance", "chainId": 137,
      "threshold": 500000, "decimals": 6,
      "label": "USDC >= $500K on Polygon" },
    { "type": "nft_ownership", "chainId": 1,
      "label": "Series 7 attestation NFT" },
    { "type": "nft_ownership", "chainId": 1,
      "label": "KYC credential" },
    { "type": "nft_ownership", "chainId": 8453,
      "label": "NDA attestation on Base" },
    { "type": "eas_attestation",
      "label": "Accredited investor (EAS)" }
  ]
}

Six conditions, three chains, every agent in the room, all must pass. But this is one configuration — not the ceiling. An agent can require a single token check on one chain, or crank it to ten conditions spanning all 33. And the room can hold two agents or two hundred. The strength of the lock and the size of the room are at the creator's discretion.

Each condition maps to a single InsumerAPI condition object — token_balance, nft_ownership, or eas_attestation. The API evaluates all conditions in a single call and returns a signed boolean per condition. The conditionsHash binds the exact conditions evaluated to the cryptographic proof.

Dynamic enforcement

Access in a SCIF is not permanent. Clearance lapses, and access is revoked. AgentTalk works the same way.

The re-verify endpoint (POST /api/agenttalk/session) re-attests every wallet live against the original conditions. Any agent whose wallet no longer meets a condition — the Series 7 NFT was revoked, the USDC balance dropped below threshold, the NDA attestation expired — is ejected from the session. The rest stay. The creator can also kick agents manually, and agents can leave voluntarily.

This is dynamic access enforcement. The session reflects current on-chain state, not the state at the time of issuance. Sell the token, get ejected from the room.

What the API returns

Each agent's attestation is an ECDSA-signed (ES256, P-256) response from InsumerAPI, verifiable offline via JWKS:

{
  "sessionId": "ses_51f5c240...",
  "agents": [
    {
      "wallet": "0xd8da6bf2...",
      "attestation": {
        "attestation": {
          "id": "ATST-74BB3943E691B5FF",
          "pass": true,
          "results": [{ "met": true, "conditionHash": "0x..." }],
          "attestedAt": "2026-04-01T02:15:19Z"
        },
        "sig": "17/J229P4P/0F3qr...",
        "kid": "insumer-attest-v1",
        "jwt": "eyJhbGciOiJFUzI1NiI..."
      }
    },
    {
      "wallet": "0x55fe002a...",
      "attestation": { ... }
    }
  ]
}

Every attestation carries sig (base64 P1363), kid (insumer-attest-v1), and a full ES256 JWT. Any third party can verify any agent's attestation offline by fetching the public key from the JWKS endpoint. No callback to InsumerAPI required at verification time.

Who uses this

AgentTalk is built for regulated industries where every participant must prove qualification before information moves:

Finance & Banking: Two trading agents verify collateral before negotiating. A syndication room where 20 lending agents each prove capital commitments before seeing the term sheet.
Legal: Law firm agents verify they represent parties to the same matter before sharing discovery. M&A data rooms where every participant verifies escrow deposits before accessing deal terms.
Intelligence & Defense: A multi-agency briefing room where every autonomous system verifies clearance-equivalent credentials before accessing shared intelligence. ITAR-controlled agents verify export compliance on-chain.
Healthcare: HIPAA-qualified data exchange — agents verify compliance attestations before sharing patient data. A clinical trial room where agents from multiple pharma companies verify IRB approvals before sharing interim results.

The InsumerAPI integration

AgentTalk uses exactly one InsumerAPI endpoint: POST /v1/attest. Every call includes format: "jwt" to receive the full ES256 JWT alongside the raw signature. The conditions array is passed through directly — AgentTalk does not interpret, transform, or cache conditions. It is a session layer, not a verification layer. The verification is InsumerAPI.

InsumerAPI returns a conditionHash per condition (SHA-256 of the canonical JSON for that condition), embedded in each signed result. AgentTalk independently computes a conditionsHash over the entire conditions array (SHA-256 of the canonical JSON array) to bind the channel to its declared conditions. Both use sorted-key canonical JSON for deterministic output. Together they create a tamper-evident binding: the channel knows what was declared, and each attestation proves what was evaluated.

Storage is ephemeral with TTL-based expiry. Channels and sessions expire automatically. No persistent database, no user accounts, no PII.

Two meeting types

Not every session needs a record. Some sessions are confidentiality-first — the perimeter is the entire deliverable. What is said inside stays inside, and there is no external proof of the meeting's content, only that every participant was qualified throughout. This is the SCIF case. AgentTalk natively serves it.

Other sessions are record-first. Lawyers meet, discuss, agree, and sign — the signed agreement is the deliverable. Regulated agent workflows, audit-ready transactions, and decision-evidence sessions fall here. For these, a co-signed outcome record layers on top of AgentTalk: all participants sign a shared receipt bound to the AgentTalk sessionId and conditionsHash. The outcome layer is a separate product line that composes on top of AgentTalk's perimeter, not a missing feature inside it.

Pipeline: InsumerAPI proves wallet state (before). AgentTalk proves all participants were qualified throughout (during). For sessions that need it, a co-signed record proves what was agreed (after). Three independent layers, composable as the use case requires.

AgentTalk is live at skyemeta.com/agenttalk. The reference implementation is on GitHub. 10 free calls to start — no signup, no credit card.

There Is No Secret: Condition-Based Access

Douglas Borthwick — Tue, 31 Mar 2026 20:17:29 +0000

Before passwords, there were no secrets to steal. Trust was physical. You showed up in person. Someone who knew you confirmed who you were. Or you carried a physical credential: a wax seal, a letter of introduction, a key. Identity was relational. You could not prove who you were at a distance without a trusted intermediary.

Passwords were the first attempt to solve remote authentication without a human in the loop. They replaced the letter of introduction with a shared secret. They worked because humans were the only ones authenticating, and humans could be held accountable for their secrets.

That assumption no longer holds.

What cookies actually do

Google and Facebook did not solve authentication. They solved something narrower: session continuity.

A cookie does not know who you are. It knows that this browser was here before. It links requests together across time. It is a memory device, not a trust device.

But the surveillance economy built itself on top of that memory. Follow the cookie across fifty websites and you reconstruct a profile. The cookie became a tracking mechanism by accident, because it was the only persistent identifier available.

Passwords created an industry. Cookies created a bigger one. Both are workarounds for the same underlying problem: proving something about a person or agent at a distance, without shared physical reality.

The problem with secrets

Every authentication system built on secrets has the same failure mode: the secret can be stolen.

Passwords get phished. Cookies get hijacked. API keys get leaked. Session tokens get forged. The security industry is largely a response to this single structural problem — billions of dollars spent managing the consequences of a primitive that requires you to extract something from the user and store it somewhere else.

Identity systems made it worse. To prove who you are, you hand over personal information. Name. Date of birth. Address. Social security number. The relying party stores it. The relying party gets breached. The information belongs to someone else now.

Every system built on secrets is a liability waiting to be realized.

Wallet state is different

A wallet state is not a secret. It is a fact about the world.

It exists on the chain. You do not share it. You do not hand it over. You do not trust anyone to store it safely. The fact is there, publicly readable, at any moment in time.

When a relying party needs to know whether you qualify for an interaction, the question is not: what secret do you hold? The question is: what is your state right now?

Read the chain. Evaluate the condition. Return a signed boolean.

That is all that travels. Yes or no. Nothing else.

The merchant does not learn your wallet address. The server does not learn your holdings. Nothing about your identity travels with the result. The agent does not carry a credential that can be stolen. The result is issued, used, and gone. The next query evaluates the condition again, from live state, at that moment.

A fundamentally different privacy model

Passwords require you to share a secret.

Cookies require you to be tracked.

Identity systems require you to hand over personal information.

All three work by extracting something from you and storing it somewhere else.

Wallet state requires none of that. The answer is derived from a public fact. The relying party learns one thing: whether the condition is met. Nothing about you, your history, your holdings, or your identity travels with the result.

This is not a marginal improvement on existing authentication. It is a different model entirely.

What this looks like in practice

Imagine you sign up for something. Instead of creating a password, they put an NFT in your wallet.

That is it. No form. No database entry. No credential to manage.

Every time you show up somewhere that needs to know if you belong, they check the wallet. Does this wallet hold the NFT? Yes or no. Nothing else changes hands. Nothing else gets stored. The proof lives in the wallet until you transfer it or it expires.

No asking you to remember anything. No asking you to prove anything. The fact is just there.

This is also why it works for AI agents, and why it matters now.

An agent has no memory in the human sense. It cannot manage a password. It cannot solve a CAPTCHA. It cannot navigate an OAuth flow designed for a person with a browser and ten seconds to spare. But it has a wallet. And a wallet has state. And state can be read.

The same model that works for a human signing into a website works for an agent qualifying for an API endpoint. No separate infrastructure. No different protocol. The wallet is the credential. The state is the answer.

That is what makes wallet state a primitive, not a product. It is the underlying thing that everything else gets built on top of, for both humans and machines, simultaneously.

The timing

Passwords took decades to displace physical credentials. The transition was slow because the infrastructure had to be rebuilt, and because the people building it did not always understand what they had.

Cookies accumulated decades of regulatory backlash before GDPR, ePrivacy, and the death of the third-party cookie finally arrived. The consequences of that architecture are still being unwound.

Wallet state is earlier in that curve than either of them were when the people building them understood what they had.

The agentic commerce protocols are being written now. UCP, x402, A2A, MCP. The standards that will govern how AI agents authenticate and qualify for access are being defined in open GitHub repositories, in real time, by a small number of people.

The primitive that gets embedded in those standards will be the primitive the market inherits.

That primitive is condition-based access. Not identity. Not secrets. Conditions. Read the wallet state, evaluate what the operator requires, return a signed result. The infrastructure is live. The integrations are in production.

InsumerAPI is live across 33 chains. API docs · How it works

How to Build Access Control Without Passwords, Keys, or Secrets

Douglas Borthwick — Sun, 29 Mar 2026 12:11:25 +0000

There is a page on the internet right now that anyone can visit. The URL is public. The server is unprotected. There is no login, no password, no firewall, no encryption standing between the world and what is on it.

And almost nobody on earth can see it.

Not because it is hidden.

Because there is no key to find.

Most security hides a secret. This does not. It asks whether you qualify.

This is condition-based access. Not identity. Not secrets. Conditions.

What "Secure" Has Always Meant

Every security system in history has been built on the same idea: hide something. A password. A private key. A certificate. A secret that, if found, opens the door.

Bitcoin hides a 256-bit private key. The security comes from the fact that guessing it is computationally impossible. A classical computer would take longer than the age of the universe to brute force one. A quantum computer running Shor's algorithm could theoretically change that, which is why the cryptography community is already building post-quantum replacements.

Every password, every private key, every certificate shares the same vulnerability: there is a secret. And secrets can, in principle, be found.

The Lock With No Key

What if there was no secret to find?

Not a better secret. Not a harder secret. No secret at all.

That is what a wallet-based condition lock is. And it is a different model of access control than anything that has existed before.

Here is how it works. A piece of content, an offer, a web page, an agent conversation, a product listing, sits on the open internet. No encryption. No password. No key. The URL is public. Anyone can knock.

But before anything is revealed, one question is asked: what does your wallet hold, right now, on the blockchain?

The answer comes back as a signed boolean. Pass or fail. If you pass, the content appears. If you fail, it does not. And nothing about what is behind the door is ever exposed.

The Combination That Cannot Be Guessed

A single condition is a welcome mat. Hold this token, get the discount. Simple, elegant, useful for millions of merchants.

But the same primitive that powers a simple fan token discount can power something else entirely.

Ten conditions. Ten independent requirements, each checked live against blockchain state simultaneously.

Hold a specific NFT minted in a limited collection of 500. Hold a minimum USDC balance on Base. Hold governance tokens on Ethereum above a specific threshold. Have a KYC attestation from a recognized issuer on Optimism. Hold a native Bitcoin balance above a specific amount. And five more conditions, each referencing specific contracts, specific token IDs, specific balances, specific attestations.

There is no algorithm, classical or quantum, that computes ownership. The only way to satisfy the conditions is to actually own everything on the list.

And even that is not enough. Ownership is static. The lock checks state. State is time. Time is the lock.

This Is Not Token Gating

Token gating has existed for years. Hold an NFT, get into a Discord. Hold a token, see a page. That model is real and useful. Collab.Land, Tokenproof, Guild.xyz have all built on it.

But it asks the wrong question.

Ownership is a fact about the past. State is a fact about now.

Token gating checks whether your wallet contains something. It runs once, at the gate, and moves on. It does not check your USDC balance. It does not verify a KYC attestation on a different chain. It does not evaluate ten simultaneous conditions across 33 chains and return a cryptographically signed answer.

Wallet auth does not ask whether you once held something. It asks what your wallet holds at this exact block, across every supported chain, against every condition you define, and signs the result. Every time. Not just at onboarding.

That is not an upgrade to token gating.

It is a different question entirely.

The Moving Target

There is no moment where you have already solved the lock.

Someone could know every condition. Could assemble every asset. Could hold every required token across every required chain. And still fail, because their USDC balance dropped a dollar below the threshold this morning. Because a staking position unlocked. Because a credential lapsed.

There is no static secret to steal. No list to compile and satisfy once. Miss by one condition, and the door does not open.

You don't just need to own it. You need to hold it — right now.

This is not a harder password. It is not a longer key. It is a security primitive that does not use secrets at all. The content is in plain sight. The conditions are the lock. And the conditions are the live state of the blockchain.

From Welcome Mat to Vault

The same API call. The same single script. One line changes the conditions.

That sounds abstract, but it already exists as software. We have built four products on this primitive. Each one is a different point on the same spectrum.

SkyeGate Lite. The welcome mat. A merchant adds a single token condition to their website. Hold the neighborhood token, see the members page. Hold the fan token, unlock the exclusive offer. One condition, instant setup, no technical knowledge required. The page is public. The content behind it is not.

SkyeGate. The company layer. A private portal, an investor room, a restricted content section. Multiple conditions: the equity token, a KYC attestation, a minimum balance, a governance credential, verified across chains. The URL is public. Anyone can visit. Nobody without the exact combination ever sees what is inside. Not because it is hidden. Because the door does not appear for them.

SkyeWoo. The store. Token-gated commerce. A product, a discount, a price tier that only exists for qualified wallets. The storefront is open. The offer surfaces only at checkout, only for the wallet that meets the conditions. Everyone else sees the standard price. Nobody sees what they are missing.

AgentTalk. The agent session. An AI conversation that only opens to a qualified principal. The agent does not respond until the wallet behind it clears. No conversation starts, no session opens, no information is exchanged until the signed attestation confirms the principal holds what is required. The agent is in plain sight. The conversation is not.

All four are built on InsumerAPI. Any developer can access the same primitive directly and build their own version of any of these, or something that has never existed before.

One API call. One signed boolean. The content never moves. The door never appears. Only those who qualify ever know it was there.

Try It

There is a page you can either see or not. The difference is not what you know. It's what you hold.

SkyeGate · SkyeWoo · AgentTalk

The Insumer Model™ · March 2026
Blockchains made writing permanent. We make reading them verifiable.

Why Agent Discovery Systems Check Identity First (and Why That's Wrong)

Douglas Borthwick — Sat, 28 Mar 2026 12:41:03 +0000

Credentials route. Identity confirms. That is the order every discovery system in history has followed. Medical boards, search engines, licensing authorities, the Yellow Pages. You find what you need first, then verify who it is. The agent ecosystem is building it backwards — racing to prove agents are real when the harder question is whether they are relevant.

The problem everyone is solving

Right now, dozens of projects are shipping specs for decentralized identifiers, trust registries, encrypted transport, and proof-of-key-ownership. The work is technically sound. Ed25519 passports, DID resolution, interop tests passing across three languages. Real engineering, solving a real problem. But it is the wrong problem for discovery.

"Is this agent real?" is a necessary check. It is not a useful filter. A verified agent with a clean DID Document and a valid trust registry entry that cannot do what you need is just a well-authenticated waste of time.

How every other discovery system works

When you need a cardiologist, you do not browse a list of every doctor and check each one's identity. You search by specialty and board certification. The credential routes you to the right person. Identity confirmation happens after.

When you need an electrician, you check the state licensing board. You filter by license type, active status, and geographic area. The licensing board does not just confirm the electrician exists. It confirms the electrician is qualified. An unlicensed electrician with a verified identity is still someone you cannot legally hire.

When you need a lawyer, you search bar associations by practice area and jurisdiction. The attorney's name is the output of the search, not the input.

This pattern is not accidental. It is how discovery works in every domain where the cost of choosing wrong is high. Medical boards, bar associations, contractor licensing, financial certifications. The credential is the filter. Identity is the handshake.

The history is older than you think

The Yellow Pages organized businesses by category, not alphabetically by name. The entire information architecture was capability-first. White Pages existed too, but only worked when you already knew who you wanted. Yellow Pages worked when you knew what you needed.

DNS maps names to addresses. Pure identity resolution. It has no concept of "find me a server that does X." Identity-first resolution requires you to already know what you are looking for. DNS could not answer "find me X," which is precisely why search engines had to be invented. Google indexes by content relevance, not by domain name.

Every discovery system that has ever worked at scale puts capability ahead of identity. The agent ecosystem is building White Pages and DNS when it needs Yellow Pages and search engines. That will not scale.

The firehose problem

When 10 agents exist, identity-first discovery works fine. You can inspect each one. When 10,000 agents pass identity verification for the same task category, you have 10,000 verified agents and you are no closer to choosing.

This is not a hypothetical. Information retrieval theory has studied this tradeoff for decades. In 1979, C. J. van Rijsbergen formalized the precision-recall tradeoff: systems optimized for recall return everything that might be relevant, at the cost of flooding users with irrelevant results. Systems optimized for precision return fewer results, but the right ones.

Identity-first discovery maximizes recall. Credential-first discovery maximizes precision. For agent selection, where you typically need one qualified agent rather than a complete census, precision is what matters.

Without credential-based filtering at the discovery layer, every verified agent can knock on every door. That is not trust infrastructure. That is a firehose with signatures.

This is not a new idea

In 1966, Jack Dennis and Earl Van Horn introduced capability-based addressing at MIT. A capability is an unforgeable token that simultaneously names a resource and authorizes access to it. The capability routes you to the resource. You do not find the resource first and then present credentials. Possession of the capability is both necessary and sufficient.

That is how a signed attestation works. "This wallet holds governance tokens on Ethereum" is a capability token. Possession of it should be sufficient to route an agent to services that require that credential. No separate identity check needed at the discovery layer.

The multi-agent systems community learned this lesson decades ago. The FIPA Agent Management Specification defined a Directory Facilitator where agents register capabilities and other agents query by capability description. Attribute-based matching, not identity lookup. The agent identity frameworks being built today are ignoring prior art from their own field.

NIST formalized the broader principle as Attribute Based Access Control: identity is just one attribute among many, and often not the most important one. What you hold, what you are certified for, and what conditions you meet tell a system more about whether you should have access than your name ever could.

Why it matters more for agents than for humans

Humans have a natural rate limiter on identity creation. Creating a new professional identity takes years of education, licensing, and reputation building. An AI agent can create a new identity in milliseconds. Unlimited keypairs, unlimited DIDs, unlimited trust registry entries.

In a world of synthetic identity, identity verification is checking the lock on a door with no walls. A signed DID Document proves key control. It does not prove the agent behind that key can do anything useful. It does not prove the wallet behind the agent holds anything of value. It does not prove the agent has ever successfully completed a task.

Credentials backed by verifiable state are different. On-chain holdings cannot be fabricated. Staking positions cannot be faked. Governance token ownership is observable. Wallet auth — a signed attestation that a wallet holds specific assets on a specific chain at a specific block — is a credential that resists synthetic inflation in a way that identity alone never can.

The more agents that exist, the less identity tells you and the more credentials matter. Wallet auth is the filter that scales.

The credential-first flow

The discovery architecture should invert:

Filter by credential. "Show me agents whose wallets hold governance tokens on Ethereum, with active staking positions, attested by a recognized issuer." This is a structured query against verifiable, machine-readable data. No ambiguity, no self-reported capabilities, no natural language matching.
Route to the qualified agent. The credential narrows the field from thousands to the handful that actually meet the requirements.
Verify identity on connection. Confirm the agent's DID, check the trust registry, validate the transport layer. All the identity work the ecosystem is building goes here. It is necessary. It is just not the first step.

Self-described capabilities do not scale. Two people use the same term for the same concept less than 20% of the time. One agent says "payment processing," another says "financial transactions." Structured credentials bypass this entirely. On-chain state, signed attestations, verifiable conditions. They are machine-readable, unambiguous, and comparable without interpretation.

Credentials route. Identity confirms.

The agent ecosystem is doing important work on identity. DIDs, trust registries, encrypted transport, and proof-of-key-ownership are real infrastructure that real systems need. None of it is wasted.

But it is step three in a flow that is being built as if it were step one. Identity tells you the agent is real. Credentials tell you the agent is relevant. Discovery systems that get the order wrong do not fail gracefully. They flood every participant with every verified agent in the registry and call it trust.

The credential is the filter. Identity is the handshake. Every discovery system in history has known this. Agent infrastructure should too.