MASTR · CRYPTO & WEB3
Names and sign-in: readable identity without assuming trust
A name can resolve an address and a signature can prove key control. Neither alone establishes a trustworthy person or business.
Kapiteltexte und technische Grafiken sind auf Englisch. Die Navigation ist in sieben Sprachen verfügbar.
What does a wallet sign-in authenticate, and to whom?
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.
Erklärendes Beispiel
A user signs an authentication message for example.com containing a fresh nonce. That can authenticate key control to that service. It does not authorise a different domain to use the signature, prove the user’s legal identity or grant a token allowance by itself.
Fragen zum Mitnehmen
- Check the resolved record at the relevant time.
- Read the signing domain and nonce.
- Separate key control from real-world identity.