Verifying…}
fallback={Connect a Farcaster-linked wallet.
}
onPass={async (jwt, pqJwt) => {
const res = await fetch('/api/gated', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ jwt, pqJwt }),
});
// render res.json().secret …
}}
>
Welcome, Farcaster user.
);
}
```
app/api/gated/route.ts
```javascript
import { validateContentToken } from '@skyemeta/skyegate';
export const runtime = 'nodejs';
export async function POST(req: Request) {
const { jwt, pqJwt } = await req.json();
const result = await validateContentToken(jwt, {
pqJwt, // post-quantum companion; reported as result.pq
expectedConditions: [{ type: 'farcaster_id' }],
});
if (!result.pass) {
return Response.json(
{ error: result.error },
{ status: 403 },
);
}
return Response.json({
secret: 'Real gated content here.',
});
}
```
[Clone the full starter app →](https://github.com/skyemeta/skyegate-nextjs-starter)
## Four Condition Types
Same vocabulary as the WordPress plugin. Stack up to 10 per gate; `pass=true` requires all of them to be met.
### Token balance
ERC-20, SPL, native ETH/SOL/MATIC, plus Tron & Sui. 34 chains.
```json
{
type: 'token_balance',
contractAddress: '0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48',
chainId: 1,
threshold: '100', // decimal string: keeps full precision; decimals are read from the chain
}
```
### NFT ownership
ERC-721 and Solana NFTs. Match a whole collection: its contract on EVM chains, its verified collection address on Solana.
```json
{
type: 'nft_ownership',
contractAddress: '0x57f1887a8BF19b14fC0dF6Fd9B2acc9Af147eA85',
chainId: 1, // ENS .eth
}
```
### EAS attestation
Ethereum Attestation Service templates: Coinbase Verified, Gitcoin Passport, more.
```json
{
type: 'eas_attestation',
template: 'coinbase_verified_account',
}
```
### Farcaster identity
Wallet linked to a Farcaster account (FID present). New in Pro 1.4.0.
```json
{
type: 'farcaster_id',
}
```
Match the same conditions in `validateContentToken`'s `expectedConditions` on the server side. That's how a JWT earned for one route can't unlock another.
## API at a Glance
### `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'`.
### `