VerifyGate: check to hosted verify when needed to unlock. Create defaults private, matching raw client.verify(). Security and trust | Get started
Default create behavior
WhenproofOptions is omitted, create mode merges:
| Field | Default |
|---|---|
privacyLevel | private |
publicDisplay | false |
proofOptions only when you intentionally need unlisted public or listed public.
Basic usage
Key props
| Prop | What it does |
|---|---|
requiredVerifiers | Sets the verification policy |
verifierData | Supplies verifier-specific inputs |
strategy | Chooses reuse, reuse-or-create, or fresh |
proofOptions | Overrides privacy and content storage (defaults are private) |
mode | Chooses create vs access behavior |
proofId | Existing id for access mode |
appId | Sends public app attribution; usage bills the linked app owner profile |
hostedCheckoutUrl | Overrides the hosted verify URL when needed |
oauthProvider | Pre-selects the OAuth provider when the user already chose one in your app |
Best use cases
- gating paid or premium content
- checking NFT or token access
- launching hosted social or org verification
- requiring fresh proof creation for high-stakes actions
Hosted OAuth
Interactive verifiers (ownership-social, ownership-org-oauth, proof-of-human) use Hosted Verify. Set oauthProvider when the user already picked a provider in your app.
- Social:
x,twitter,github,discord,facebook,linkedin,telegram,farcaster - Org:
google,microsoft
neus_checkout_done. oauthProvider only picks which sign-in opens first; proof payload and your handling stay the same.
Direct-sign vs hosted
ownership-basicand other wallet-creatable verifiers can run in-widget with a connected wallet.- Social, org, and human flows route through hosted verify. Start from Hosted Verify when you are unsure.