# How TrustGraph works

Bind a device, declare directed trust, then ask and verify from your own persona.


TrustGraph lets an application ask whether one persona's trust reaches another under a chosen policy. A positive answer includes a path-existence proof that the application can verify locally.

## Bind a device to a persona

Your application generates a P-256 key on the device. The user completes an AuthenSee ceremony. The initiating app finalizes the bind using two separate one-time capabilities and retains the returned device and persona identifiers.

The stable persona is `graphNodeId`; its signing device is `graphKeyId`. A persona can have independently keyed devices. On a persona with a device chain, joining the persona and being approved to act are separate steps.

App retains initiationProof; callback returns completionProof. Both proofs converge at finalize with the matching local key.

Continue with [identity and devices](/concepts/identity).

## Declare a vouch

A usable authorized device signs a directed trust declaration from its persona to another persona. The score is 0–100. The declaration becomes active immediately; the recipient does not accept it. The opposite direction is a separate choice.

Connections belong to personas. A device's revocation does not itself remove its persona's active connections. The source can update or revoke its declaration.

Continue with [vouches and scores](/concepts/vouches).

## Ask from your own node

The user's device signs a query naming its own node, a target node, and a policy. `minTrust` sets the minimum score and `maxHops` bounds the path to 1–3 hops. The current scope is `identity`.

The service searches its graph and returns a signed attestation. For a positive answer, it also generates a zero-knowledge proof of a qualifying path. Your app checks the exact question, independent issuer pins, the pinned circuit key, and the proof bytes locally.

Private witness: intermediate path nodes and edges. Public: endpoints, policy, time, path length and epoch commitment. Positive: ZK path proof. Negative: signed report.


**Establishes**
A verified positive establishes a qualifying path in the cited graph commitment without disclosing its intermediate nodes and edges to the verifier.


**Does not establish**
The service knows the graph and query. A proof does not establish that the committed graph is complete or latest. A negative answer is a signed server report, not a proof of nonexistence.

## Build around the result

A [signed message](/build/signed-messages) can carry evidence of its signing device and persona. The recipient separately queries reachability from their own persona to that sender. [Trust-gated features](/build/trust-gated-features) use the same query-and-verify flow with an application-specific acceptance policy.

Follow the [quickstart](/quickstart) to build that flow on staging.