Emergency recovery works for EdDSA keys (Ed25519 and Ed448) exactly as it works for ECDSA keys described in the [previous](https://builder-vault-tsm.docs.blockdaemon.com/docs/emergency-recovery-ecdsa) section.

The only difference, compared to the ECDSA example in the previous section, is that we now use the `node.EdDSA()` instead of `node.ECDSA()`, and when generating the key, we should use e.g., `ec.Edwards25519.Name()` instead of `ec.Secp256k1.Name()`.

# Using the Recovered Key

As described in our [key derivation](https://builder-vault-tsm.docs.blockdaemon.com/docs/key-derivation-eddsa) section, the TSM works with raw scalar keys and does not take into account the key derivation specified in [RFC-8032](https://www.rfc-editor.org/rfc/rfc8032). So the recovered EdDSA key is also a raw scalar value and not an RFC-8032 seed.

You can [import](https://builder-vault-tsm.docs.blockdaemon.com/docs/key-import-external-eddsa) the recovered scalar key into a new TSM and continue to generate signatures. But if you try to use the recovered (raw) key to generate signatures using 3rd party libraries, such as [Noble](https://www.npmjs.com/package/@noble/ed25519), that follows RFC-8032, it will not work.

If you want to use the EdDSA key recovered from our ERS directly for signing, you must instead use a library that allows signing using the raw scalar private key.

You can find a full example in our demo repository ( [Go](https://gitlab.com/Blockdaemon/tsm-demo/-/blob/main/sdk/golang/schnorr_ers_sign.go)) that shows how a recovered Ed25519 key can be used to sign messages, using a 3rd party library that lets us work with the raw scalar private key.