ECDSA and EdDSA Side by Side

Two signature schemes cover most of the chains I care about. ECDSA over secp256k1 is used by Bitcoin and Ethereum, and EdDSA over edwards25519, known as Ed25519, is used by Solana and Stellar. They solve the same problem with different equations.

Shared setup

Both pair a private scalar d with a public point Q = d·G, and both use a hash of the message and a per-signature secret value, the nonce. Let n be the group order and z the message hash.

ECDSA

Sign with private key d:

\begin{aligned} k &\xleftarrow{\$} [1, n-1] \\ R &= kG \\ r &= R_x \bmod n \\ s &= k^{-1}(z + r d) \bmod n \end{aligned} \qquad \text{signature} = (r, s)

Verify with public key Q:

\begin{aligned} w &= s^{-1} \bmod n \\ u_1 &= z w \bmod n, \quad u_2 = r w \bmod n \\ P &= u_1 G + u_2 Q \end{aligned} \qquad \text{accept if } P_x \bmod n = r

Why it works. Substitute Q = d·G and w = s⁻¹:

\begin{aligned} P &= u_1 G + u_2 d G \\ &= (z + r d)\, s^{-1} G \\ &= (z + r d)\,\bigl(k^{-1}(z + r d)\bigr)^{-1} G \\ &= kG = R \end{aligned}

so P.x = r. The verifier never needed k or d.

Some details that show up in practice:

Malleability. If (r, s) is valid then so is (r, n - s). Bitcoin and Ethereum require the "low-s" form so a signature can't be tweaked into a different valid one with a different transaction ID.
Public key recovery. Given (r, s) and the message, there are at most a few candidate public keys. Ethereum adds a recovery value v to the signature, so ecrecover returns the signer's address without the public key being sent.
The nonce is dangerous. It must be unique and unbiased, as covered in Why ECDSA Nonces Must Never Repeat. Deterministic derivation per RFC 6979 is the common mitigation.

EdDSA (Ed25519)

Ed25519 works on the twisted Edwards curve birationally equivalent to Curve25519, with base point B of prime order ℓ ≈ 2^252. It removes the random nonce and avoids the modular inverse.

Key generation:

\begin{aligned} h &= \text{SHA-512}(\text{seed}) \quad \text{(seed is 32 random bytes)} \\ a &= \text{clamp}(h[0..32]) \quad \text{(the secret scalar)} \\ \text{prefix} &= h[32..64] \\ A &= aB \quad \text{(public key, 32 bytes)} \end{aligned}

Sign message M:

\begin{aligned} r &= \text{SHA-512}(\text{prefix} \parallel M) \bmod \ell \quad \text{(deterministic nonce)} \\ R &= rB \\ k &= \text{SHA-512}(R \parallel A \parallel M) \bmod \ell \\ S &= r + k a \bmod \ell \end{aligned} \qquad \text{signature} = (R, S)

Verify:

k = \text{SHA-512}(R \parallel A \parallel M) \bmod \ell, \qquad \text{accept if } SB = R + kA

Why it works:

SB = (r + k a)B = rB + k(aB) = R + kA

Nothing here needs an inverse, and the nonce r is derived from a secret prefix and the message, so the same message always gives the same signature and two different messages can't collide on r unless a hash does.

Comparison

	ECDSA (secp256k1)	Ed25519
Used by	Bitcoin, Ethereum	Solana, Stellar
Nonce	Random, or RFC 6979	Deterministic by design
Signature	`(r, s)`, 64 bytes plus recovery id	`(R, S)`, 64 bytes
Public key	33 bytes compressed	32 bytes
Verify equation	`u1·G + u2·Q` has x-coordinate `r`	`S·B = R + k·A`
Malleability	`s` and `n-s` both valid	Fixed by checking `S < ℓ`
Public key recovery	Possible with a recovery id	Not possible

Why this matters for threshold signing

Ed25519's equation is linear in the secret, like Schnorr's, so splitting a among parties is relatively direct. ECDSA's k⁻¹ forces extra protocol machinery, which is why threshold ECDSA is more complicated, as worked through in How Threshold ECDSA Signs.

Takeaways

Both schemes prove knowledge of a private scalar without revealing it, using a hash of the message and a one-time secret.
ECDSA's verification equation is derived from an inverse, and its main hazard is the nonce. Ed25519 trades that for a deterministic nonce and a linear equation.
The choice isn't made by developers on their own. It's decided by whichever chain you're integrating with, so a multi-chain system ends up supporting both.