Reachability asks whether a directed path connects your persona to a target under the policy you choose. The query is authorized by a device belonging to your source node.
Scroll diagram horizontally
Choose a policy
| Field | Meaning | Accepted values for new queries |
|---|---|---|
scope | Circuit compatibility scope | identity |
minTrust | Minimum score on the path | 0–100 |
maxHops | Maximum path length | 1–3 |
currentTime | Optional future horizon that narrows eligibility | A parseable future timestamp |
Out-of-range values are rejected, not silently clamped. The service controls evaluation time. A requested future horizon can only narrow the result: edges must be active now and at that horizon. A path is non-empty; a query from a node to itself still needs qualifying edges.
Sign the question you submit
Sign the exact query, including the policy fields you provide. Do not apply defaults after signing or reuse an authorization for another target. Generate a fresh read signature on a retry.
The source and target fields use node IDs despite their legacy names, sourceGraphKeyId and targetGraphKeyId. Authorization identifies the signing device separately.
Scroll diagram horizontally
Verify the attestation
Use the SDK's /zk entry with your independently pinned attestation JWKS and wotPathVerificationKey(). The verifier checks the issuer signature, expected question, pinned circuit-key hash, correspondence of the circuit inputs, and proof bytes.
Use the verified result rather than the response's unsigned convenience fields. A failed check must remain a verification failure; it is not a negative reachability result.
Scroll diagram horizontally
Does not establish
The proof does not establish that the service published the complete graph. Endpoints, policy, evaluation time and path length remain public. The service sees the graph and query. A valid proof does not establish that the server committed the complete or latest graph.Treat a negative differently
A negative attestation has null proof bytes, circuit inputs and verification-key hash. Its signature can be verified, but it reports the server's answer without a proof of nonexistence. Label it “No path reported under this policy”, rather than “proved unconnected”.
A positive proving failure is an error. There is no signature-only positive fallback.
Commitments and history
The current-epoch endpoint exposes graph and event-log commitments, including a Poseidon epoch root. A saved event-log size and root are useful continuity inputs. Growth alone does not prove that the old log is an unchanged prefix, and the current-epoch endpoint itself returns unsigned server claims.
Read what a proof tells you before turning a result into a user-facing badge or an access decision.
Positive answers use the UltraHonk ultrahonk-wot-path-v2 proof scheme; negative answers remain signed reports.