Ed25519 / EdDSA

EdDSA (Edwards-curve Digital Signature Algorithm) is a family of digital signature schemes; Ed25519 is the specific, now near-universal instance of it, built over a curve called Curve25519. Together they're the signature scheme quietly underneath an enormous share of the internet's security: SSH keys, TLS 1.3, Signal's message authentication, and the validator signatures in most modern blockchains.

What a signature scheme actually needs to do is simple to state: given a private key, produce a signature over a message that anyone holding the matching public key can verify, and that nobody without the private key can forge. EdDSA's specific contribution over older schemes (like ECDSA or RSA signatures) is mostly about implementation safety and speed: it's deterministic, meaning the same message and key always produce the same signature, which removes an entire class of catastrophic bugs caused by bad random-number generation that has broken real ECDSA deployments in the past. It's also fast to sign and verify, even on constrained hardware.

Concretely: a Solidus DID's authentication key is an Ed25519 public key; when the SDK signs a JWT or a chain transaction, it's an EdDSA signature underneath.

Where it comes from

EdDSA was designed by Daniel J. Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, and Bo-Yin Yang, published in 2011. Ed25519 specifically runs over Curve25519, an earlier Bernstein design (2006) chosen for its resistance to several classes of implementation bugs that plague other curves. The scheme was standardized by the IETF as RFC 8032 (Simon Josefsson and Ilari Liusvaara). None of this is Solidus's work: it is a decade-plus-old, extremely well-studied public standard.

Solidus status

Shipped, and used throughout: @solidus/jwt signs identity tokens with it, did:solidus DID documents carry Ed25519 verification keys, and the chain signs transactions with it. On the implementation layer, Solidus deliberately uses @noble/ed25519, Paul Miller's dependency-free, widely used TypeScript implementation, directly, rather than pulling in a general-purpose JOSE library, specifically to avoid dependency bloat and keep the signing path auditable. The Rust side uses the ed25519-dalek crate.

The primitive itself isn't the risk, Ed25519 is about as scrutinized as public-key cryptography gets. What hasn't been independently audited is Solidus's own assembly of it: the JWT signing code, the DID key-encoding conventions, the transaction-signing path. That audit hasn't happened. And as with everything else in this Lexicon: this runs on Solidus's public testnet, not a mainnet, there isn't one yet.

Proof you can run yourself: resolve any did:solidus DID against rpc.solidus.network and inspect its authentication verification method: it's a plain Ed25519 public key, checkable with any standard DID-resolution or JOSE library, no Solidus-specific tooling required.