DEV Community

Cover image for Add Wallet Auth from Claude Code in One Command
Douglas Borthwick
Douglas Borthwick

Posted on • Originally published at insumermodel.com

Add Wallet Auth from Claude Code in One Command

#ai #blockchain #agents #tutorial

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
Enter fullscreen mode Exit fullscreen mode

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": "..."
  }
}
Enter fullscreen mode Exit fullscreen mode

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"}'
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)