DEV Community: Douglas Borthwick

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.

What comes next

The session proves every agent was qualified. It does not prove what happened during the session. The natural extension is a co-signed interaction record — all participants sign a shared receipt of the session outcome. A co-signing layer that binds to the AgentTalk sessionId and conditionsHash would close this gap.

The pipeline would be: InsumerAPI attestation proves wallet state (before), AgentTalk session proves all agents met conditions (during), a co-signed record proves all agents agree on the outcome (after). Three layers, independently verifiable, composable.

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.

From AARP Cards to On-Chain Credentials: The Discount Economy Needs Wallet Auth

Douglas Borthwick — Fri, 27 Mar 2026 11:42:48 +0000

You flash your AARP card at Hertz and save 25%. You show your military ID at Home Depot and get 10% off. Your kid logs in with a .edu email and pays half price for Spotify. This is eligibility verification. It is a $300 billion economy built on plastic cards, manual checks, and databases that do not talk to each other. It works today because a human is standing at the counter. It breaks completely the moment an AI agent shops for you instead.

The discount economy is enormous and invisible

Eligibility-based discounts are everywhere. AARP has 38 million members with discounts at over 100,000 businesses. Home Depot, Lowe's, Under Armour, and Apple all offer military discounts verified through ID.me. Spotify, Amazon Prime, and Apple Music cut prices in half for students verified through UNiDAYS or SheerID. AAA members get preferred rates at Hertz, Hilton, and thousands of other merchants.

None of this runs on a shared standard. AARP has its own card. ID.me has its own database. UNiDAYS has its own verification flow. Every merchant integrates with each provider separately. Every customer carries a different set of credentials in their leather wallet, phone, or email inbox.

The system works because humans are flexible. You can pull out a card, show an app, recite a membership number, or forward a confirmation email. A cashier can look at it and make a judgment call. But flexibility is not scalability. And it is definitely not automatable. Today, there is no way to verify eligibility programmatically across providers. That is the gap.

Credentials are already moving on-chain

This is not a prediction. It is happening. Singapore's government issues real polytechnic diplomas and trade certificates through OpenCerts, anchored to Ethereum mainnet. Not a private chain. Not a pilot. Public, verifiable by anyone, no issuer cooperation needed. South Korea has gone further on scale: millions of citizens use mobile driver's licenses backed by a DID infrastructure. Real government IDs, used at real checkpoints, verified digitally. The EU has mandated digital identity wallets for every member state by 2027 under eIDAS 2.0.

Then there are the credentials that are already natively on-chain. Gitcoin Passport has over 2 million users and 35 million attestations. Binance issues soul-bound tokens to KYC-verified users. World ID has 18 million verified users and just launched AgentKit with Coinbase to let AI agents carry proof-of-human credentials into payment flows.

Credentials are moving from leather wallets to digital wallets to on-chain wallets. The question is what happens when a merchant needs to verify one of them.

Apple Wallet got halfway there

Apple Wallet and Google Wallet already hold digital versions of membership cards, loyalty passes, boarding passes, and in 21 US states, mobile driver's licenses. When you tap your phone at a TSA checkpoint, the agent sees your ID without you handing over a physical card.

But these systems are closed. Your Apple Wallet pass only works where Apple's infrastructure reaches. Your Google Wallet credential cannot be verified by a system that does not integrate with Google. The credentials are not portable, not composable, and not independently verifiable. If Apple's servers go down, your credential is useless. If a merchant does not support Apple's SDK, your membership might as well not exist.

On-chain credentials solve this by design. A soul-bound token proving AARP membership does not need AARP's server to be online for a merchant to verify it. An EAS attestation proving veteran status does not need ID.me to be in the loop. The credential is on a public chain, verifiable by anyone, portable to any platform that can read the chain.

The catch: reading a wallet to verify one credential risks exposing everything else in it. Checking for an AARP NFT should not reveal how much ETH you hold, what DeFi positions you have, or which other tokens are in there. That is the privacy problem.

Now add AI agents to the picture

Mastercard launched Agent Pay. Visa published the Trusted Agent Protocol. Coinbase built x402. Stripe is building the Machine Payments Protocol with Tempo. Every major payment rail is racing to let AI agents spend money on your behalf.

These systems solve authorization: can this agent pay? They do not solve eligibility: does the person behind this agent qualify for a discount?

Think about what happens when your AI agent goes shopping for you. It finds a hotel on Hilton's site. You are an AARP member, a AAA member, and a Hilton Honors Gold member. The agent should get the best available rate stacking all three. But how does it prove any of them?

The agent cannot flash a card. It cannot forward a confirmation email. It cannot type in a promo code and hope the cashier accepts it. It needs to prove eligibility programmatically, in real-time, before checkout. And the merchant's system needs to verify that proof without seeing everything else in the agent's wallet.

This is not a hypothetical. The Universal Commerce Protocol, a Google and Shopify joint project for agent checkout flows, is actively designing how eligibility claims work at checkout. Their technical committee is right now debating how to handle multiple concurrent verification-based discounts: military, student, teacher, loyalty tier, each with different rules and seasonal availability. The payment rail exists. The credential layer is forming. The verification layer between them is the gap.

The credential gap

On-chain infrastructure can already prove you are a real person, that you passed KYC, or that an AI agent has a registered identity. But it cannot prove you are an AARP member, a veteran, a student, a Costco member, a union worker, or a Hilton Gold loyalty tier holder. The entire real-world credential layer, the memberships and eligibilities that drive hundreds of billions in preferential pricing, has zero on-chain representation.

Starbucks tried with Odyssey, NFT loyalty stamps on Polygon, and shut it down after 15 months. Shopify built native token-gating features and deprecated them. Both failed because they treated credentials as gamification instead of infrastructure. But the underlying need did not go away. A human can work around missing infrastructure. An agent cannot.

Wallet auth is the verification layer

When credentials do move on-chain, whether as soul-bound tokens, EAS attestations, or W3C Verifiable Credentials anchored to a chain, someone needs to verify them at the point of transaction. And that verification needs to be privacy-preserving. Boolean, not balance. "Does this wallet hold credential X?" Yes or no, cryptographically signed, independently verifiable, nothing else exposed.

That is what wallet auth does. An agent presents a wallet. The merchant's system queries whether the wallet holds specific credentials. The response comes back as a signed attestation: this wallet holds an AARP-equivalent NFT, or a veteran soul-bound token, or a loyalty tier credential. The signed result is verifiable offline via JWKS. No raw wallet contents are exposed. No other holdings are revealed.

The same call can stack. Military plus loyalty tier plus alumni credential, all verified in one request, each returned as a separate boolean. The agent gets the best available price. The merchant gets cryptographic proof of eligibility. Neither side sees anything they should not.

This is not new technology applied to a new problem. It is the same verification primitive that already works for token holdings, NFT ownership, and on-chain attestations, applied to the credential layer as it forms. The credentials will come. Token-gated commerce is already live at scale for fan tokens and NFTs. The next wave is memberships, eligibilities, and qualifications.

The cards in your leather wallet are going on-chain

Your AARP card will become a soul-bound token. Your military status will become an on-chain attestation. Your alumni credential will become a Verifiable Credential anchored to a public chain. This is not a question of if. Singapore is already doing it with diplomas. South Korea is already doing it with driver's licenses. The EU is mandating it by law.

These credentials will sit in your on-chain wallet next to your tokens and NFTs. Your AI agent will present them at checkout the same way you flash a card at the register today. The difference is that verification will be instant, private, composable, and signed. No calling a database. No trusting a third party. No exposing your wallet to check one credential.

The payment rails are being built. The credential layer is forming. The verification layer between them, the one that lets an agent prove "this person qualifies" without revealing anything else, is wallet auth. It will become the default way eligibility works. And it is live today.

Add Wallet Verification to a LangChain Agent in 5 Minutes

Douglas Borthwick — Thu, 26 Mar 2026 21:34:38 +0000

AI agents that interact with wallets need to verify what those wallets hold before making decisions. An agent approving a payment, granting access, or scoring trust needs a server-side signal, not a client-side read. This tutorial shows how to add wallet verification to a LangChain agent using the langchain-insumer package. Five minutes, working code, 33 chains.

Install the package

pip install langchain-insumer

Requires Python 3.9+ and a free InsumerAPI key. Get one here (10 free credits, no credit card).

Set up the tools

import os
from langchain_insumer import InsumerAPIWrapper, InsumerAttestTool, InsumerWalletTrustTool

os.environ["INSUMER_API_KEY"] = "insr_live_YOUR_KEY_HERE"

api = InsumerAPIWrapper()
attest_tool = InsumerAttestTool(api_wrapper=api)
trust_tool = InsumerWalletTrustTool(api_wrapper=api)

Two tools. attest_tool verifies specific conditions: token holdings, NFT ownership, EAS attestations, and Farcaster identity. trust_tool generates a full trust profile across 4 dimensions: stablecoins, governance, NFTs, and staking.

Add to your agent

from langchain_openai import ChatOpenAI
from langchain.agents import AgentExecutor, create_tool_calling_agent
from langchain_core.prompts import ChatPromptTemplate

llm = ChatOpenAI(model="gpt-4o")
tools = [attest_tool, trust_tool]

prompt = ChatPromptTemplate.from_messages([
    ("system", "You are a helpful assistant that can verify wallet holdings on-chain."),
    ("human", "{input}"),
    ("placeholder", "{agent_scratchpad}"),
])

agent = create_tool_calling_agent(llm, tools, prompt)
executor = AgentExecutor(agent=agent, tools=tools)

The agent now has access to both wallet verification tools. It will decide which tool to call based on the user's request.

Verify token holdings

result = executor.invoke({
    "input": "Does wallet 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045 hold at least 1000 USDC on Ethereum?"
})
print(result["output"])

The agent calls attest_tool with the right parameters. Under the hood, it hits POST /v1/attest with type: "token_balance", contractAddress: "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48", chainId: 1, threshold: 1000, and decimals: 6.

The response is ECDSA-signed. The agent gets a boolean, not a balance. Privacy preserved by design.

Generate a trust profile

result = executor.invoke({
    "input": "Generate a trust profile for wallet 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045"
})
print(result["output"])

trust_tool hits POST /v1/trust. It returns 36 checks across 4 dimensions: stablecoins (USDC and USDT), governance, NFTs, and staking. The agent gets a structured summary with totalPassed, totalFailed, and dimensionsWithActivity.

This is the "does this wallet hold real assets?" verification, useful for cold-start reputation. A wallet that holds governance tokens on multiple chains, stablecoins across several networks, and NFTs from established collections is more credible than an empty wallet created yesterday.

Using the tools directly (without an agent)

You do not need a full agent to use the tools. Call them directly for programmatic workflows:

import json

# Verify specific condition
result = attest_tool.invoke({
    "wallet": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045",
    "conditions": json.dumps([
        {
            "type": "nft_ownership",
            "contractAddress": "0xBC4CA0EdA7647A8aB7C2061c2E118A18a936f13D",
            "chainId": 1,
            "label": "BAYC holder"
        }
    ])
})

# Trust profile
trust = trust_tool.invoke({
    "wallet": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045"
})

Same ECDSA-signed responses. Same 32-chain coverage. The tools work identically whether called by an agent or by your code.

MCP server alternative

For agents that use MCP (Model Context Protocol), there is an MCP server that exposes the same capabilities:

npx -y mcp-server-insumer

This exposes the same verify and trust tools as MCP resources. Works with Claude, Cursor, and any MCP-compatible client. No Python needed.

Set the INSUMER_API_KEY environment variable before starting the server, and any connected agent can call verify_wallet and check_trust directly.

What the agent sees

Every verification returns ECDSA-signed results. The agent, or any downstream service, can verify the signature against the public key at GET /v1/jwks. This means the verification is trustworthy even if the agent itself is untrusted.

The response also supports format: "jwt". Pass that parameter to POST /v1/attest and you get an ES256-signed JWT alongside the standard response. Any service with a standard JWT library (Kong, Nginx, Cloudflare Access, AWS API Gateway) can verify it via the JWKS endpoint without any custom code.

Key insight: Wallet Auth for agents works like OAuth for users. OAuth proves who you are. Wallet Auth proves what you hold.

Use cases for agent wallet verification

        - **Pre-transaction trust.** Before an agent sends funds, verify the counterparty holds real assets. A wallet with governance tokens and stablecoins across multiple chains is a stronger counterparty than an empty wallet.
        - **Token-gated API access.** Require proof of token holdings to access premium agent capabilities. Verify once, cache the signed attestation, and check it on every request.
        - **Compliance gates.** Verify Coinbase KYC attestations (via EAS) before processing regulated transactions. The agent verifies the on-chain attestation exists without seeing any personal data.
        - **Agent-to-agent trust.** One agent can verify another agent's wallet as a trust signal. If Agent B claims to represent a DAO, Agent A can verify that Agent B's wallet holds the DAO's governance token.


, before CTA) -->

    Share this article

        [

            Share on X
        ](#)
        [

            LinkedIn
        ](#)
        [

            Reddit
        ](#)


            Discord



            Copy Link

InsumerAPI is free to start. Get an API key and try it. View API Docs

How to Verify an AI Agent's Wallet Before You Pay It

Douglas Borthwick — Thu, 26 Mar 2026 21:34:23 +0000

An AI agent wants to pay for an API call. The facilitator needs to decide: should I settle this payment? The wallet might be brand new. It might have a long history of completed transactions. It might have been rated by other services. Each scenario requires a different trust signal. This article describes the three layers and shows how they compose in a single middleware hook.

The problem: one signal is not enough

Coinbase's x402 protocol adds native payments to HTTP. An agent sends a payment header with its request, and a facilitator settles the transaction. But the facilitator has a decision to make before settlement: is this wallet trustworthy?

A single trust signal breaks down at the edges. Behavioral scoring requires history, so it fails on day-zero wallets. On-chain reputation requires prior interactions with the specific service. Credential checks can verify holdings but say nothing about past behavior. Each layer covers a different phase of the wallet lifecycle.

Layer 1: On-chain credentials (pre-history)

A wallet has never transacted with any x402 service. No behavioral history exists. No reputation has been accumulated. But the wallet might hold governance tokens on multiple chains, staked ETH, and stablecoins across several networks. That presence is a meaningful signal.

InsumerAPI's trust endpoint runs 36 checks across 4 dimensions in a single call:

curl -X POST https://api.insumermodel.com/v1/trust \
  -H "X-API-Key: insr_live_YOUR_KEY_HERE" \
  -H "Content-Type: application/json" \
  -d '{
    "wallet": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045"
  }'

The response includes per-dimension results and an overall summary:

{
  "ok": true,
  "data": {
    "trust": {
      "id": "TRST-D4F6A",
      "wallet": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045",
      "conditionSetVersion": "v1",
      "dimensions": {
        "stablecoins": { "passCount": 3, "failCount": 4, "total": 7 },
        "governance": { "passCount": 2, "failCount": 2, "total": 4 },
        "nfts": { "passCount": 0, "failCount": 3, "total": 3 },
        "staking": { "passCount": 1, "failCount": 2, "total": 3 }
      },
      "summary": {
        "totalChecks": 17,
        "totalPassed": 6,
        "totalFailed": 11,
        "dimensionsWithActivity": 3,
        "dimensionsChecked": 4
      },
      "profiledAt": "2026-03-06T10:00:01.000Z",
      "expiresAt": "2026-03-06T10:30:01.000Z"
    },
    "sig": "...",
    "kid": "insumer-attest-v1"
  },
  "meta": { "creditsRemaining": 94, "creditsCharged": 3, "version": "1.0", "timestamp": "2026-03-06T10:00:01.000Z" }
}

The 4 dimensions cover stablecoins (USDC on 7 chains), governance tokens (UNI, AAVE, ARB, OP), NFTs (BAYC, CryptoPunks, Pudgy Penguins), and staking (stETH, rETH, cbETH). Each check returns a boolean. No balance amounts are ever exposed.

A wallet with activity in 3 or more dimensions is a very different counterparty than an empty wallet created five minutes ago. For the cold-start case, this is the only meaningful signal available.

Layer 2: Behavioral scoring (transaction history)

Once a wallet has on-chain transaction history, behavioral analysis becomes possible. DJD Agent Score, part of the Coinbase x402 ecosystem, evaluates wallets across multiple dimensions: transaction patterns, wash trading detection, interaction diversity, and identity signals.

DJD already integrates InsumerAPI for its Identity dimension. When a wallet has no behavioral data, the on-chain credential check provides the fallback signal. When behavioral data is available, DJD's scoring engine provides a richer picture.

The two signals are complementary. A wallet might hold governance tokens (Layer 1) but have suspicious transaction patterns (Layer 2). Or a wallet might have healthy behavioral scores but hold no real assets. Neither signal alone tells the full story.

Layer 3: On-chain reputation (post-interaction)

After a wallet has actually completed x402 payments, a third signal becomes available: reputation from real economic interactions. The ERC-8004 Reputation Registry standard, implemented by projects like Azeth, allows wallets to accumulate reputation scores on-chain based on completed service interactions.

The key design property: only wallets that have completed a payment to a service can rate that service. Opinions are weighted by cumulative USDC volume between the rater and the service. This makes sybil attacks economically expensive rather than just rate-limited.

Scores live on-chain, so any facilitator can read them directly from contract state without trusting a centralized API. This is the highest-fidelity signal, but it requires the most history to accumulate.

How the three layers compose

The x402 protocol provides a beforeSettle hook where facilitators can inject trust logic before settling a payment. The three layers map to different phases of the wallet lifecycle:

        - **Pre-history** (Layer 1): wallet has never transacted with any x402 service. On-chain credentials are the only signal.
        - **Behavioral** (Layer 2): wallet has on-chain transaction history that can be scored, but has not interacted with this specific service.
        - **Post-interaction** (Layer 3): wallet has completed x402 payments and accumulated on-chain reputation from real economic interactions.

Signal fidelity increases across the phases. Asset holdings are a useful proxy. Behavioral patterns are stronger but gameable with enough volume. Payment-weighted on-chain feedback is the hardest to fake, because manipulation cost scales with the reputation being built.

The beforeSettle hook

Here is how the three layers compose in a single beforeSettle hook. Each layer is independently opt-in. A facilitator can start with one and add others as needed.

beforeSettle: async (payerWallet) => {
  // Layer 1: On-chain credentials via InsumerAPI
  const trust = await fetch("https://api.insumermodel.com/v1/trust", {
    method: "POST",
    headers: {
      "X-API-Key": process.env.INSUMER_API_KEY,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ wallet: payerWallet }),
  }).then((r) => r.json());

  const hasCredentials =
    trust.data.trust.summary.dimensionsWithActivity >= 2;

  // Layer 2: Behavioral scoring via DJD Agent Score
  const djd = await fetch(
    `https://djd-agent-score.fly.dev/v1/score/basic?wallet=${payerWallet}`
  ).then((r) => r.json());

  const hasBehavior = djd.score >= 25;

  // Layer 3: On-chain reputation (ERC-8004)
  // Read directly from contract state on Base
  // const reputation = await readReputationScore(payerWallet);
  // const hasReputation = reputation.averageScore >= 25;

  // Gate: require at least one signal
  if (!hasCredentials && !hasBehavior) {
    throw new Error(
      "Wallet has no on-chain credentials and no behavioral history"
    );
  }
}

Layer 1 and Layer 2 run in parallel. The facilitator requires at least one positive signal before settling. A cold-start wallet passes on credentials alone. An established wallet passes on behavioral score alone. A wallet with both signals is the strongest counterparty.

Why each layer matters

Layer 1 solves cold start. Every wallet starts with zero behavioral history. On-chain credentials are the only signal available at time zero. A wallet holding stablecoins across 3 chains, governance tokens, and staking positions carries evidence of legitimacy that no behavioral model can produce before the first interaction.

Layer 2 adds pattern detection. Behavioral scoring catches things that static holdings cannot: wash trading, interaction diversity, transaction frequency patterns. A wallet might hold real assets but behave suspiciously. Behavioral analysis catches that.

Layer 3 closes the loop. Once enough agents rate services on-chain, new agents can route payments by reputation score rather than hardcoded URL. The trust layer becomes a routing layer. This is where the system gets interesting, but it requires a critical mass of interactions to become useful.

Verifying the credential signal

The trust profile from InsumerAPI is ECDSA-signed. A facilitator can verify the signature independently using the public key from the JWKS endpoint at /.well-known/jwks.json or GET /v1/jwks. The insumer-verify npm package handles this automatically:

import { verifyAttestation } from "insumer-verify";

// Pass the full API response envelope, not trust.data
const result = await verifyAttestation(trust);
if (!result.valid) {
  throw new Error("Trust profile signature verification failed");
}

This means the facilitator does not need to trust InsumerAPI as a black box. The same pattern DJD Agent Score uses in production: call the API, then verify the response cryptographically before acting on it.

Where this is headed

The three-layer model is not theoretical. DJD Agent Score already runs Layer 1 and Layer 2 in production for Coinbase x402 wallets. ERC-8004 is live on Base Sepolia. The pieces exist. What is missing is a standard interface that lets facilitators plug in trust providers without coupling to any single source.

A composable beforeSettle that accepts pluggable trust providers, each returning a score and confidence level, would let facilitators mix signals without custom integration work for each provider. The x402 protocol already has the hook. The trust layers already have the data. The composition layer is next.

, before CTA) -->

    Share this article

        [

            Share on X
        ](#)
        [

            LinkedIn
        ](#)
        [

            Reddit
        ](#)


            Discord



            Copy Link

InsumerAPI is free to start. Get an API key and try it. View API Docs

How Two AI Agents Verify Each Other Before Sharing Data

Douglas Borthwick — Thu, 26 Mar 2026 21:33:51 +0000

AI agents are starting to transact with each other. They negotiate deals, exchange data, and move money. But how does one agent know the other is worth talking to? AgentTalk, built by Skye Meta, answers that question with on-chain wallet conditions verified by InsumerAPI.

The Problem: Agents Need Trust Before Communication

When two AI agents meet on a network, they face a fundamental question. Should I talk to this thing? Passwords prove you know a secret. API keys prove you have access. Neither proves financial capacity, community membership, or on-chain reputation.

An agent negotiating a supply chain deal needs to know its counterpart controls real assets. An agent operating inside a DAO needs to verify the other agent actually holds governance tokens. A compliance-gated data exchange needs proof that EAS credentials are on-chain, not just claimed.

Static credentials do not solve this. A password issued yesterday says nothing about what the agent holds today. On-chain state changes continuously. The trust primitive has to be dynamic, verifiable, and composable.

How AgentTalk Works

AgentTalk is a condition-gated communication protocol for AI agents. Every channel has wallet conditions. Every session is verified on-chain. The flow has five steps.

        - **Declare.** The channel creator defines conditions: which tokens, which chains, what thresholds. Up to 10 conditions per channel across 33 chains (30 EVM + Solana + XRPL).
        - **Connect.** An agent joins the channel and presents its wallet address.
        - **Attest.** AgentTalk calls InsumerAPI (`POST /v1/attest`) to verify both wallets against the channel conditions. Boolean results. Pass or fail.
        - **Session.** If both wallets pass, each agent receives an ECDSA-signed attestation JWT. The agents can now communicate.
        - **Verify.** At any point during the session, either agent can request re-verification. AgentTalk calls the attest endpoint again. If the wallet no longer meets the conditions, the session ends immediately.

This is the key principle: sell the token, lose the session. Access is not static. It is continuously tied to on-chain state. The moment an agent's wallet no longer meets the conditions, the communication channel closes. No revocation lists, no admin intervention. The blockchain is the authority.

AgentTalk exposes this flow through four endpoints on skyemeta.com: POST /api/agenttalk/declare (create a channel with conditions), POST /api/agenttalk/join (join and receive per-agent attestation JWTs), GET /api/agenttalk/session (check session status), and POST /api/agenttalk/buy-key (purchase an InsumerAPI key with USDC). Under the hood, each session call hits InsumerAPI's POST /v1/attest for on-chain verification.

What Makes This Different

Traditional agent communication protocols rely on identity. You authenticate once, and you are in. AgentTalk replaces identity with verifiable state.

        - **Composable conditions.** A single channel can require holdings across multiple chains and token types. Hold 1,000 USDC on Ethereum and an NFT on Base and a governance token on Arbitrum. All verified in one attestation call.
        - **Boolean results, not raw amounts.** InsumerAPI returns pass or fail for each condition. The other agent never learns how much you hold. Only whether you meet the threshold.
        - **Privacy-preserving.** No wallet contents are exposed. No transaction history is shared. The attestation confirms specific conditions without revealing anything beyond the yes-or-no answer.
        - **Independently verifiable.** Every attestation is ECDSA-signed by InsumerAPI. Any agent can verify the signature offline using the public JWKS endpoint. You do not need to trust AgentTalk. You trust the cryptography.

The API Behind It

AgentTalk calls POST /v1/attest for every session establishment and every re-verification. The request includes the wallet address and an array of conditions. The response includes a boolean result for each condition, a condition hash for tamper detection, and an ECDSA signature over the entire payload.

Agents that want additional assurance can request format: "jwt" in the attest call. This returns an ES256-signed JWT alongside the standard response. The JWT is verifiable by any standard library (Kong, Nginx, Cloudflare Access, AWS API Gateway) via the JWKS endpoint at /.well-known/jwks.json.

The verification chain is simple. You send conditions in. You get cryptographically verifiable results out. No trust in the intermediary required. The attestation is signed, the signature is public-key verifiable, and the condition hash lets you confirm the conditions were not altered in transit.

Autonomous Key Purchase

Agents that use AgentTalk start with 10 free InsumerAPI calls. After that, they need their own API key. The purchase is fully autonomous.

The agent sends USDC, USDT, or BTC to the InsumerAPI payment address on any supported chain (EVM, Solana, or Bitcoin). Then it calls POST /v1/keys/buy with the transaction hash. The key is issued automatically. No human in the loop. No credit cards. No signup forms.

This matters because the whole point of agent-to-agent communication is autonomy. If an agent has to wait for a human to purchase an API key, the system is not truly autonomous. AgentTalk agents buy their own verification capacity with on-chain payments, the same way they verify each other with on-chain state.

Use Cases

        - **Supply chain negotiation.** Agent A wants to negotiate a bulk purchase. Agent B requires proof that Agent A's wallet holds sufficient USDC before opening the channel. The condition is verified on-chain. No bank statements, no credit checks.
        - **DAO-to-DAO workflows.** Two DAOs want to coordinate on a joint proposal. Each DAO's agent must prove it holds governance tokens from both organizations. Conditions are composable, so this is a single attestation call.
        - **Compliance-gated data exchange.** An agent needs to share sensitive data but only with counterparts that hold specific EAS credentials on-chain. AgentTalk verifies the credential holdings before the session opens.
        - **AI agent marketplaces.** A marketplace of AI services requires agents to hold the marketplace's service token to participate. Sell the token, lose access to the marketplace. Dynamic, not static.

Wallet Identity as a Primitive

AgentTalk treats the wallet as the agent's fingerprint. Not an identity document, not a login credential, but a verifiable state container. What the wallet holds right now determines what the agent can do right now.

For more on wallet identity as a primitive, see Your Wallet Is Your Fingerprint on the Skye Meta blog.

The pattern is straightforward. AgentTalk defines the conditions. InsumerAPI verifies them on-chain. The attestation is cryptographically signed. Any participant can verify it independently. No centralized authority decides who gets access. The blockchain decides.

Built on InsumerAPI

    Share this article

        [

            Share on X
        ](#)
        [

            LinkedIn
        ](#)
        [

            Reddit
        ](#)


            Discord



            Copy Link

InsumerAPI is free to start. Get an API key and try it. View API Docs

Verify a Wallet Before Your AI Agent Transacts (Python Tutorial)

Douglas Borthwick — Thu, 26 Mar 2026 21:33:31 +0000

AI agents are starting to shop autonomously. They browse product catalogs, compare prices, and complete purchases. But how does a merchant verify that the agent's user actually holds the tokens that qualify for a discount? This tutorial walks through the full flow: discover a merchant, verify on-chain eligibility, get a UCP discount, and validate the code at checkout.

The Problem

An AI shopping agent finds a merchant that offers 15% off to UNI holders. The agent knows the user's wallet address. But how does it prove the user holds UNI without exposing the wallet's full portfolio? And how does the merchant trust the discount code the agent presents?

This is where on-chain verification fits into agent commerce. An attestation authority like InsumerAPI sits between the agent and the blockchain. It verifies holdings on-chain, returns a signed boolean result (eligible or not), and issues a time-limited discount code. The merchant validates the code at checkout without needing blockchain access.

Step 1: Discover Available Merchants

The agent starts by browsing the merchant directory. This is a free, public endpoint:

import requests

BASE = "https://api.insumermodel.com"
KEY  = "insr_live_YOUR_KEY_HERE"

# List merchants that recognize UNI token
merchants = requests.get(
    f"{BASE}/v1/merchants",
    params={"token": "UNI", "verified": "true"},
    headers={"X-API-Key": KEY},
).json()

for m in merchants["data"]:
    print(f"{m['companyName']} ({m['id']})")
    for token in m.get("tokens", []):
        print(f"  {token['symbol']}: up to {token['maxDiscount']}% off")

The agent now has a list of merchants, their IDs, and the token tiers they offer. It can choose the best deal for the user.

Step 2: Check Discount Eligibility

Before requesting a formal discount code, the agent can do a free eligibility check:

# Free check, no credits consumed
eligibility = requests.get(
    f"{BASE}/v1/discount/check",
    params={
        "merchant": "demo-coffee-shop",
        "wallet": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045",
    },
).json()

if eligibility["data"]["eligible"]:
    print(f"Eligible for {eligibility['data']['totalDiscount']}% off")
else:
    print("Not eligible for this merchant")

This costs nothing. The agent can check multiple merchants before committing to a verification.

Step 3: Request a UCP Discount

The user qualifies. Now the agent requests a formal discount in Google UCP format. This consumes 1 merchant credit and triggers the on-chain verification:

ucp = requests.post(
    f"{BASE}/v1/ucp/discount",
    headers={"X-API-Key": KEY, "Content-Type": "application/json"},
    json={
        "merchantId": "demo-coffee-shop",
        "wallet": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045",
        "items": [
            {"path": "cart/espresso", "amount": 450},
            {"path": "cart/pastry", "amount": 350},
        ],
    },
).json()

print(ucp)

The UCP response:

{
  "ok": true,
  "data": {
    "protocol": "ucp",
    "version": "2026-01-11",
    "extension": "dev.ucp.shopping.discount",
    "discounts": {
      "codes": ["INSR-B9M2K"],
      "applied": [
        {
          "code": "INSR-B9M2K",
          "title": "Token Holder Discount — 15% Off",
          "amount": 120,
          "automatic": false,
          "method": "across",
          "priority": 10,
          "allocations": [
            {"path": "cart/espresso", "amount": 68},
            {"path": "cart/pastry", "amount": 52}
          ]
        }
      ]
    },
    "verification": {
      "code": "INSR-B9M2K",
      "expiresAt": "2026-02-27T12:30:00.000Z",
      "sig": "MEYCIQDx...base64...",
      "kid": "insumer-attest-v1"
    }
  },
  "meta": {
    "version": "1.0",
    "timestamp": "2026-02-27T12:00:01.000Z",
    "creditsCharged": 1,
    "creditsRemaining": 94
  }
}

Key UCP-specific fields:

        - **`extension`**: `dev.ucp.shopping.discount` identifies this as a UCP shopping discount for Google's commerce routing.
        - **`title`**: A human-readable discount description (UCP uses this instead of ACP's coupon object).
        - **`allocations`**: Per-item discount amounts, calculated from the `items` array you sent.
        - **`verification.sig`**: ECDSA P-256 signature. The merchant can verify this against the public key at `/.well-known/jwks.json`.

Step 4: Agent Applies the Discount

The agent now has everything it needs to apply the discount in the checkout flow:

if ucp["ok"] and ucp["data"]["discounts"]["applied"]:
    discount = ucp["data"]["discounts"]["applied"][0]
    code     = discount["code"]
    title    = discount["title"]
    amount   = discount.get("amount", 0)
    expiry   = ucp["data"]["verification"]["expiresAt"]

    print(f"Applying: {title}")
    print(f"Discount code: {code}")
    print(f"Savings: ${amount / 100:.2f}")
    print(f"Valid until: {expiry}")

    # Agent presents code to merchant checkout
    checkout_payload = {
        "discount_code": code,
        "cart_items": [
            {"path": "cart/espresso", "amount": 450},
            {"path": "cart/pastry", "amount": 350},
        ],
    }
else:
    print("No discount available")

Step 5: Merchant Validates the Code

On the merchant side, the backend validates the code before applying the discount. This endpoint is public. No API key required:

# Merchant backend (server-side)
validation = requests.get(f"{BASE}/v1/codes/INSR-B9M2K").json()

if validation["data"]["valid"]:
    pct = validation["data"]["discountPercent"]
    mid = validation["data"]["merchantId"]
    exp = validation["data"]["expiresAt"]

    print(f"Code valid: {pct}% off for merchant {mid}")
    print(f"Expires: {exp}")
    # Apply discount to order
else:
    reason = validation["data"]["reason"]
    print(f"Code rejected: {reason}")
    # reason is "expired", "already_used", or "not_found"

The merchant should verify three things:

        - **`valid` is `true`**
        - **`merchantId` matches their own ID** (prevents code reuse across merchants)
        - **`expiresAt` is in the future** (codes are valid for 30 minutes)

UCP Discovery for Automated Agents

Google UCP agents can discover InsumerAPI automatically via the UCP discovery file:

GET https://insumermodel.com/.well-known/ucp.json

This returns the endpoint URL, authentication method, and capabilities:

{
  "name": "InsumerAPI",
  "capabilities": ["dev.ucp.shopping.discount"],
  "endpoints": {
    "discount": {
      "method": "POST",
      "path": "/v1/ucp/discount",
      "authentication": {
        "type": "custom",
        "header": "X-API-Key"
      }
    },
    "validate_code": {
      "method": "GET",
      "path": "/v1/codes/{code}",
      "authentication": { "type": "none" }
    }
  },
  "signing": {
    "algorithm": "ES256",
    "kid": "insumer-attest-v1",
    "jwks_uri": "https://insumermodel.com/.well-known/jwks.json"
  }
}

An agent using UCP discovery can find the endpoint, call it, and validate codes without any hardcoded URLs.

For the complete commerce integration surface, including ACP and UCP endpoints, code validation, and merchant configuration, see the AI Agent Verification API overview, the commerce developer guide, and the full OpenAPI 3.1 spec.

Why This Matters for Agent Commerce

Privacy by default. The agent sends a wallet address. InsumerAPI verifies holdings on-chain and returns a boolean result with a discount percentage. No token quantities, no portfolio composition, no PII. The merchant learns "this wallet qualifies for 15% off" and nothing else.

Cryptographic trust. Every discount code is ECDSA-signed. The merchant does not need to trust the agent. They verify the signature against a public key. The on-chain state is the ground truth. The signature proves the attestation authority checked it.

Protocol-native output. Agents built on Google's commerce stack consume UCP responses directly. Agents built on OpenAI's stack use the ACP endpoint instead. Same verification, different response shape.

30-minute codes. Discount codes expire after 30 minutes. They cannot be stockpiled, shared, or replayed. Each code is single-use and tied to a specific merchant.

A forkable reference repository with all examples is available at acp-ucp-onchain-eligibility-example on GitHub.

, before CTA) -->

    Share this article

        [

            Share on X
        ](#)
        [

            LinkedIn
        ](#)
        [

            Reddit
        ](#)


            Discord



            Copy Link

InsumerAPI is free to start. Get an API key and try it. View API Docs