Key use cases include identity resolution to prevent sybil attacks in governance systems, integration with existing web2 software and digital sovereignty.

Your Keys, Your Data - Without Storage

While it's acceptable practice across web3 to store a cached version of data for springy, streamlined client experiences, it's an anti-pattern to store non-public pii (personally identifiable information).

The design of web3 identity resolution systems should not look to store data points that can be correlated to validation, extensions (social, etc) or other identifiable data.

Message Generation

The hashed message should have as much context as possible. More context creates greater entropy. The message should be hashed and sent to the intermediary (server) and verified by reproducing the identical signature.

Some implementers/devs may choose not to generate the signing message entirely on the server, and have the client make a request for specific values, which adds a spectrum of risk.


While blindly accepting a signature as proof seems an obvious bad practice, it's important that isn't not overlooked. The server should validate that the received message signature matches.

Scope & Nonce

A nonce should be used to prevent replay attacks. While deterministic, the nonce should not be predictable. During the validation process, the nonce should be validated.


Context such as domain, dramatically improve security. Domain context can be used to prevent phishing attacks and cross site script (XXS) attacks.


Additional authentication protocols integrated into a solution can increase the fidelity of resolution, thus ensuring 1 human = 1 human, making it difficult for sybil attacks. The multi credentialed tree has characteristics which extend both domain & scope, subsequently maximizing security.


When using distributed identity resolution systems, security implementation is a shared responsibility between both the end user and the dApp developer. Implementers/devs should aim to reduce as many touch points as possible.