Reference
proveWalletOwnership(params)
Promise<{ proofToken, expiresInSec?, error? }>
Proves the person present controls the wallet, not just that an address was supplied. Requests a one-time challenge, has the wallet sign it (EIP-191 personal_sign: free, gasless, no transaction; smart wallets verify on-chain via EIP-1271/6492), and returns a session-scoped proof token. The signature goes from the visitor's browser to the proof endpoint directly and never touches your server.
Required params: address, plus provider (e.g. window.ethereum) or a signMessage callback (wagmi's signMessageAsync, viem wallet clients, Privy). Prove once per visit; pass the token as walletProof below. EVM wallets in this wave.
verifyConditions(params)
Promise<{ pass, jwt, pqJwt, raw, error? }>
Low-level imperative call. The React hook + component use this internally; reach for it in non-React contexts (server actions, API routes, Node scripts).
Required params: address, conditions[], licenseKey, and walletProof (from proveWalletOwnership; the proxy rejects licensed EVM calls without it). Optional: walletType ('evm' | 'solana'), endpoint, domain.
validateContentToken(jwt, options?)
Promise<{ valid, pass, payload?, pq?, error? }>
Server-side JWT validation. Verifies the ECDSA P-256 signature against InsumerAPI's JWKS, checks issuer + expiry via jose, and (if you pass expectedConditions) confirms the signed conditions match what the route requires.
Since September 2026 InsumerAPI returns an ML-DSA-65 post-quantum companion (pqJwt) beside the ES256 jwt. Pass it as options.pqJwt and the result carries pq: verified, refuted, absent, or unverifiable, on every outcome once the JWT verified. A refuted companion always rejects; an absent or unverifiable one rejects only past your own pqRequiredFrom cutoff. Install the optional peer @noble/post-quantum to verify companions.
Trust the math, not a company, including us. Every result is independently verifiable by any third party using the public JWKS.
If you cache the result, key it on the JWT
Nothing here caches a verdict: every call re-verifies the signature, so a route that
follows the examples above is checking cryptographic proof on every request. Caching that
away is a reasonable optimisation, and it is where this goes wrong.
Key any cache on something only the person who passed could produce
— the JWT itself, or a session you issued them. Never on the wallet address, and never
on a content or product id. Both are public. A cached “yes” filed under a public
value can be claimed by anyone who knows it, and because a cache hit returns before your
validation runs, the signature you were relying on is never checked.
A wallet address feels like an identifier for a person. It is not a secret, it is a
name anyone can read off a block explorer, and anyone can send you one.
useSkyeGate(options)
{ status, pass, jwt, pqJwt, error, refetch }
React hook. Same options as verifyConditions (including walletProof), plus enabled to gate the call. status cycles through 'idle' → 'verifying' → 'pass' | 'fail' | 'error'.
<GatedContent />
JSX.Element
Declarative wrapper. Renders children on pass, fallback otherwise, loading while verifying. Optional onPass(jwt, pqJwt?) callback fires once when the gate first passes; forward both tokens to your server. Use it to fetch gated content from your server.
Full API reference on GitHub →
