Skip to main content
Align Get started with this loop before you scale traffic. Use paths to pick a surface, billing for payers, LLM docs for assistants. Call GET /api/v1/proofs/check (or your own store of proofId) before prompting verification. Persist the receipt ID you get back. Reuse it for gates and policy. Proof receipts explains why you save proofId, not raw signatures.

​
Loop

  1. Check: eligibility with a saved proofId or GET /api/v1/proofs/check before showing a verify flow
  2. Verify: only when needed (Hosted Verify or SDK/API)
  3. Save: proofId on the user or session (same value as qHash; see Proof receipts)
  4. Reuse: UI, VerifyGate, server policy, MCP. Same ID everywhere

​
Visibility modes

Choose visibility once per proof. Full detail and storeOriginalContent guidance are in Security and trust.
ModeprivacyLevelpublicDisplayUse
Listed publicpublictruePublishing and attribution where the proof should be discoverable
Unlisted publicpublicfalseNon-sensitive reuse, gates, and checks without listing for discovery
Owner-onlyprivatefalseOwner-only access and owner-authenticated reuse
  • Raw SDK client.verify() defaults to private stored receipts (see SDK overview).
  • VerifyGate create mode defaults to unlisted public (public + publicDisplay: false) so the primary gating surface matches reuse-first flows.

​
Checklist

​
Verification strategies (SDK / API)

StrategyWhen
reuse-or-createDefault: reuse a valid proof if you have one; otherwise start verification
freshForce a new verification even when an older proof might still be valid
reuseNever create; require an existing proof or fail (read-only / display paths)

​
URLs

PurposeURL
Hosted Verifyhttps://neus.network/verify
APIhttps://api.neus.network
MCPhttps://mcp.neus.network/mcp

Get started

Onboarding and production checklist.

Hosted Verify

Hosted flows.

Receipts

Persist IDs.

Security and trust

Visibility.

API

HTTP.

Verifiers

Full list.

Billing

Payers, sponsors, x402.