Skip to main content

​
Lifecycle Stages

StageMeaningWhere
Flow startsVerification is launchedHosted verify, SDK, or API
Request acceptedNEUS accepts the verificationSDK or POST /api/v1/verification
ProcessingAn async verifier is still runningStatus endpoint or SDK polling
CompleteThe proof receipt is readySDK result, widget callback, or status endpoint
ReusedAnother product check uses the saved proof receiptProof page, gate check, policy, MCP
Revoked or staleThe proof no longer meets the target policyRevocation route or freshness rule

​
Reuse Strategy

StrategyWhat it doesUse when
reuse-or-createReuse an existing eligible proof, otherwise create oneDefault in most hosted and SDK flows
reuseOnly check existing proofsRead-only access checks
freshAlways force new verificationHigh-stakes actions

​
Freshness Guidance

  • Use a recency window for point-in-time verifiers such as balances, risk, and ownership.
  • Treat status checks as cheap reads; only create new proofs when policy actually demands a fresh assertion.
  • Prefer since or sinceDays in gate checks instead of re-verifying on every request.

​
Revocation

If a user needs to invalidate a proof they own, use the self-revocation flow: 
POST /api/v1/proofs/revoke-self/{qHash}
The path parameter value is the same proof receipt ID returned as proofId in SDK responses. In the JavaScript SDK: 
await client.revokeOwnProof(proofId, wallet);

How Verification Works

Requests, signer strings, and hosted interaction.

Receipts & Results

Proof receipt structure and field semantics.

Verifier Catalog

Verifier pages and use cases.

API Overview

HTTP endpoints.