TrustGraph

Browse conceptsGlossaryHow TrustGraph worksPersonas and devicesReachability and proofsSigned content and membershipVouches and scoresWhat a proof tells you

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.

Scroll diagram horizontally

Binding: two distinct proofs meet at finalizationApp + key storeTrustGraph serverAuthenSee hostedinitiationProofHeld by the appCallback relaycompletionProofReturned to the appFinalizeBoth proofs + local key
The app keeps initiationProof; the callback returns completionProof. Finalization requires both and the matching local key.

Continue with identity and devices.

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.

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.

Scroll diagram horizontally

One signed public statement, two different kinds of evidenceSigned public statementSource · target · policy · evaluation timeVerdict · path length · graph commitmentPositive answerZK path proof + issuer signatureNegative answerNo proof · issuer-signed reportPrivate witnessIntermediate nodes + edgesVisible to the serviceVerify the issuer signatureNo proof of non-existence
Both outcomes sign the public statement. A positive adds a proof over a private path witness; a negative is an issuer-signed report with no path proof.
Does not establishThe 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 can carry evidence of its signing device and persona. The recipient separately queries reachability from their own persona to that sender. Trust-gated features use the same query-and-verify flow with an application-specific acceptance policy.

Follow the quickstart to build that flow on staging.

Checked against server 9f47f2d · SDK 12053abLast updated 2026-11-04Edit on GitHub