Names and sign-in: readable identity without assuming trust

Readable names reduce one kind of friction

A naming system can connect a human-readable name with addresses and other records. ENS uses a registry and resolver architecture to manage and retrieve such information. This makes an address easier to communicate, but it also creates configuration, renewal and control questions. The name’s appearance is not a guarantee about the entity behind it. Similar-looking characters or misleading labels can still cause confusion.

Resolution is a stateful claim

The record that a name resolves to can change under its control rules. A researcher should preserve the relevant record and block or timestamp when using it as evidence. A name associated with an address today does not establish that it pointed to the same address last year. Reverse resolution and display names also need care: a label shown by an application is not automatically verified identity.

Signing in is not sending money

Sign-In with Ethereum, specified by ERC-4361, defines a structured authentication message including context such as a domain, address, nonce and issue time. This can let a service authenticate control of an account without receiving its private key. A correctly implemented flow binds the signature to the expected context and prevents reuse through appropriate nonce handling. The service still controls its own session and account policies.

A signature has to be interpreted

A wallet prompt can ask for authentication, a spending permit or another authorisation. All may be described casually as signing a message, although their effects differ. Check the domain, chain, action and expiry where applicable. A readable message is helpful only if the user and application interpret the relevant fields correctly. A familiar name or a secure browser connection does not turn a malicious authorisation into a harmless sign-in.

Identity is a stack of assertions

Key control, name control, service login and real-world identity are separate relationships. They can be combined deliberately, but they should not be inferred from one another without evidence. This distinction matters for both user safety and investigations: public claims can establish useful connections, while assumptions about a pseudonym can also lead to false attribution.

Questions à retenir

• Check the resolved record at the relevant time.
• Read the signing domain and nonce.
• Separate key control from real-world identity.

Poursuivre la lecture

• A ticker is not an asset identifier
• Signed permits: a message can authorise spending
• Typed data: readable fields still need interpretation
• Session theft: account access without another password prompt