What is Ed25519 and why do you use it?

RSA-2048 signatures are 256 bytes — 4x bigger. RSA-2048 verification is ~10x slower than Ed25519. RSA has known parameter sensitivities (small primes, side channels) that Ed25519 sidesteps by design. At receipt scale (billions of receipts), the size + speed difference compounds.

secp256k1 is fine but rougher around the edges: more subtle to implement correctly, susceptible to side-channel attacks if implemented naively. Ed25519 has constant-time implementations that are easier to verify-correct. Plus Ed25519 is implemented in essentially every cryptographic library (node:crypto, @noble/curves, OpenSSL ≥1.1.1, etc.). Less lift to integrate.

Ed25519 provides ~128 bits of security against classical attacks. Quantum-resistant? No — quantum computers will break it eventually. The mitigation: when post-quantum signatures (CRYSTALS-Dilithium, FALCON, SPHINCS+) mature, we add them as an alternative algorithm. Receipts already have an alg field; the schema accommodates multiple algorithms.

TypeScript: @noble/hashes for SHA-512 (the hash inside Ed25519) + @noble/curves/ed25519 for the curve operations. Python: cryptography library's ed25519 module. Both are constant-time, audited, widely deployed. We don't reinvent the cryptography; we use the standard libraries.

The private key is stored in ~/.genzagents-mcp-env mode 600 — readable only by the owning user. The bulletproof storage pattern: even if Claude Desktop's claude_desktop_config.json gets rewritten, the side file is untouchable. The MCP server reads it on boot regardless of what the LLM-host's config says.

Rotate immediately. /settings/keypair → Rotate generates a new keypair, publishes the new public key, marks the old one as compromised in your DID document. Receipts signed before the rotation date remain valid; receipts after must use the new key. Anyone verifying old receipts uses the old public key; new receipts use the new one. Standard key rotation pattern.