Does Resolving Your DID Notify Anyone?

The problem the question is really about

In a great many identity systems, checking something about you contacts the party who issued it. That is the phone-home problem, and it is a privacy failure hiding inside a correctness feature: the issuer ends up with a log of every place you used what they gave you.

A holder-controlled credential is supposed to break that link. So: does ours?

Answer one, resolving a DID does not notify its subject

No callback reaches you. A did:solidus resolves against chain state, not against a service the subject operates. Nobody pings your device, and no notification is generated.

You can watch a resolution happen:

$ curl -s -X POST https://rpc.solidus.network -H 'Content-Type: application/json' \
    -d '{"jsonrpc":"2.0","method":"solidus_didResolve","params":["did:solidus:testnet:1111111111111111111111zz"],"id":1}'
{"jsonrpc":"2.0","id":1,"result":null}

Live, 2026-07-31. And so the answer is not a generic fallback, the control: a made-up method returns -32601 Method not found. Different responses, so the resolution method is genuinely there.

Answer two: the resolver sees the query, and today the resolver is us

Here is the part the title's question tends to skip. Resolution is a request to a node. Whoever runs that node sees which DID was asked about, when, and from where.

The public RPC endpoint above is ours. So "resolving a DID does not notify anyone" is true about the subject and false about the operator, and pointing at a decentralised data model does not change who answered the request.

The mitigation is real and is not something we can do for you: run your own node, or use one you trust. Chain state is public and replicable; that is the property that makes the mitigation possible. Until you do that, you are trusting us with your resolution pattern, and we would rather write that sentence than let "decentralised" imply it away.

And a related honesty point: per-verifier identifiers are deliberately never anchored, they resolve to nothing on the public chain. That means the identifiers you use most are not the ones anybody resolves, which materially reduces how much a resolver can learn. It is a genuine mitigation, and it is not a substitute for controlling the node.

Answer three, revocation checking, where the two credential formats differ

We run two credential paths with two honestly different answers. There is no single story here.

The SD-JWT path uses status-list-style checking. A verifier fetches a list covering many credentials and reads your slot, rather than asking about your credential specifically. That reduces exposure (the issuer does not learn which credential was checked) but it does not eliminate it: fetching a list still tells whoever serves it roughly which cohort is being checked, and when.

The endpoint is live, at /status-lists/:id, signing and returning a status-list token. Our own lexicon said otherwise until today: a 2026-07-17 probe used the right prefix without the :id segment and read the route-miss as an absence. Corrected in the same pass as this page. The real remaining limitation is narrower, no published list id is discoverable, so a stranger cannot fetch a list even though the route works.

The BBS+ path uses epoch-based revocation rather than a per-credential lookup. The BBS+ implementation referenced here is unaudited.

What to take away