Web3 Identity

“Identity in web3” reduces to a simple cryptographic claim: a wallet is just a public/private key pair, and authentication is that key signing a piece of data. None of it inherently requires a blockchain — but blockchains make real-world use cases (name services, recovery, marketplaces) much easier.

The cryptographic substrate

  • Curves. All major chains use elliptic-curve cryptography: Bitcoin and Ethereum use secp256k1; Solana uses the more conventional Curve25519 (Ed25519). A private key is literally any integer in a defined 256-bit space; the public key is a fixed generator point on the curve scalar-multiplied by that integer. Deriving the public key is fast; recovering the scalar from the public key is the elliptic-curve discrete-log problem.
  • Hashes. Bitcoin and Solana use SHA-256; Ethereum uses Keccak-256 (the pre-NIST-standard SHA-3 variant — a historical quirk with real interop consequences).
  • Addresses ≠ public keys. Pre-2017 Bitcoin addresses were public keys; modern Bitcoin addresses are hashes of the pubkey (base58 or bech32-encoded). Ethereum addresses are the last 20 bytes of the Keccak-256 hash of the public key, rendered as 0x-prefixed hex. Solana still uses the raw public key (base58). Base58 encoding (alphanumeric minus 0, O, I, l) is arguably Bitcoin’s most enduring legacy.

Wallets and key derivation

Wallet apps are hierarchical deterministic (HD) — a BIP-39 seed phrase (initial secret + checksum) feeds PBKDF2 into a 512-bit seed, from which a BIP-32 tree of key pairs is deterministically derived along a path like m/44'/60'/0'/0/n. This is why a single seed phrase restores an entire wallet fleet in MetaMask, Phantom, Ledger, or Trezor. See hd-wallet-derivation-paths for the path anatomy and per-chain conventions.

Authentication: sign-in with a wallet

Proving control of an identity means signing site-provided data with the wallet’s private key. Ethereum’s signature format (ECDSA with recovery, EIP-191 personal_sign) embeds the signer’s public key via a recovery ID, so a verifying site can recover the signer’s address from the signature alone — no extra round-trip. This self-certifying property likely gave Ethereum a leg up for non-payment applications.

  • MetaMask-style injection — the wallet extension injects a window.ethereum provider; sites detect it and request signatures.
  • WalletConnect — removes the injection assumption: the site posts an encrypted payload to a relay/proxy; the wallet (desktop or mobile) learns the relay location + shared secret (typically via QR code), fetches, decrypts, signs, and pushes the response back. v2 hardens the encryption and drops Ethereum-specific signature assumptions.

This sits between older centralized client-certificate login (Firefox) and the deliberately ephemeral client certificates of Project Gemini.

Naming, safety, and the DID fight

  • Name services — wallet addresses are unfriendly, so blockchain “DNS” layers map human names to addresses: ENS (.eth, Ethereum Name Service), Solana Name Service (.sol), Unstoppable Domains (.crypto). ENS is the most widely integrated and can resolve to multisig vaults like Safe (formerly Gnosis Safe).
  • Multisig identity vaults — a single private key is a fragile identity root; an m-of-n smart-contract wallet (e.g. 1-of-2 MetaMask + hardware key for recoverability, 2-of-3 for high security) makes key loss survivable and key theft non-catastrophic.
  • W3C DIDs (Decentralized Identifiers) — an attempt to abstract the “wallet” idea into a portable spec bridging Web2 identity providers and web3. Objected to by Google, Apple, and Mozilla during the W3C process — likely fatal without browser support, and notably the objectors are themselves the largest centralized identity providers. DIDs remain the underpinnings of W3C Verifiable Credentials.

Sources