The primitive behind token gating, wallet-verified commerce, and agent-to-agent authentication.
Wallet verification is the process of reading what a blockchain wallet holds and returning a verified answer. Does this wallet hold 100 USDC? Does it own a specific NFT? Does it have a balance above a threshold on a particular chain?
The wallet connects. The verification engine reads on-chain state. It returns pass or fail. That result can then be used to control access to content, products, discounts, APIs, or anything else.
This is the primitive behind token gating, wallet-verified commerce, and agent-to-agent authentication. All of them are applications of the same underlying operation: verify what a wallet holds, then decide what happens next.
A blockchain wallet is a publicly verifiable record of economic behavior. Unlike a username or email address, a wallet address maps to on-chain state that anyone can read:
The key insight is that these are not claims — they are facts. They exist on a public ledger that anyone can verify. Wallet verification simply reads this state and turns it into an authorization decision.
Traditional access control relies on identity: usernames, passwords, API keys, OAuth tokens. These systems answer the question "who are you?"
Wallet verification answers a different question: "what do you hold?"
This distinction matters because:
At a technical level, wallet verification follows a simple flow:
The verification engine handles the complexity — RPC calls, contract ABIs, chain-specific logic, multi-chain routing. The application just receives a signed answer.
// Example: verify a wallet with InsumerAPI
POST https://api.insumermodel.com/v1/attest
{
"wallet": "0xd8dA6BF26964aF9D7eEd9e03E...",
"conditions": [
{
"contractAddress": "0xA0b86991...",
"chainId": 1,
"threshold": 100,
"decimals": 6
}
]
}
// Response
{
"ok": true,
"data": {
"attestation": { "pass": true },
"jwt": "eyJhbGciOiJFUzI1NiI..."
}
}
Wallet verification is a primitive — a single operation that enables many different use cases:
A WordPress site verifies that a visitor's wallet holds a governance token before showing a research report. The content stays on the server until the wallet passes. This is what SkyeGate does — wallet-verified content for WordPress across 31 blockchains.
A WooCommerce store verifies that a customer's wallet holds an NFT before showing a product or applying a discount. No coupon codes to leak — the discount is tied to on-chain state. This is what SkyeWoo does — wallet-verified commerce for WooCommerce.
Two AI agents verify that each other's wallets meet the same conditions before exchanging data. Not identity — qualification. This is what AgentTalk does — wallet-qualified sessions for AI agents.
A DAO restricts governance documentation to wallets holding the governance token. No member database, no invitation codes. Token holders are members automatically.
A developer builds a service that only responds to wallets holding a specific token. The wallet is the API key. Sell the token, lose access to the API.
Simple wallet verification checks one thing: does this wallet hold X? But real-world access control often requires multiple conditions:
Composable verification evaluates multiple conditions against one or more wallets (including different wallet types like MetaMask and Phantom) and returns a single pass/fail result. All Skye Meta products support up to 10 composable conditions per verification.
Token gating is one application of wallet verification. It specifically means restricting access to content or products based on token ownership.
Wallet verification is the broader primitive. It includes token gating, but also covers:
If you hear "token gating," think of it as a specific use case. Wallet verification is the infrastructure that makes it possible.
Skye Meta builds wallet verification tools for different platforms:
| Tool | Platform | What it verifies |
|---|---|---|
| SkyeGate | WordPress | Wallets before showing content (posts, pages, downloads) |
| SkyeWoo | WooCommerce | Wallets before allowing purchases or applying discounts |
| AgentTalk | API | Agent wallets before issuing session tokens |
| InsumerAPI | Any backend | Any wallet against composable conditions (the verification engine) |
All four products use the same underlying verification engine: InsumerAPI, built on The Insumer Model™. It supports 31 blockchains (30 EVM + Solana), composable conditions, ECDSA-signed attestations, and returns privacy-preserving pass/fail results.
The full stack looks like this:
Wallet verification infrastructure
|
InsumerAPI (verification engine)
|
+---------+---------+---------+
| | | |
SkyeGate SkyeWoo AgentTalk Your app
(content) (commerce) (agents) (API)
InsumerAPI is the primitive. Everything else is a distribution layer that makes wallet verification accessible to different audiences — WordPress publishers, WooCommerce merchants, AI developers, or anyone with an API call.
Choose the right tool for your use case:
Wallet verification is a single primitive that works across content, commerce, and agents. Verify what a wallet holds. Then decide what happens next.