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; Solana, Sui and Tron wallets sign with their own message signature), 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, Solana, Sui and Tron wallets. For a non-EVM wallet, pass walletType and a signMessage callback that returns the wallet's own signature.
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 calls without it). Optional: walletType ('evm' | 'solana' | 'sui' | 'tron'), 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. The companion is bound to the JWT by the full claim set, every claim compared as parsed JSON, so verified vouches for the results that expectedConditions is matched against, not only for pass. 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 →
