Timeline for EdDSA?


Is there a timeline for the incorporation of threshold EdDSA signatures in a similar way to ECDSA signatures are currently supported in the IC?



Hi @eugaia! We don’t have a concrete timeline for threshold EdDSA yet, it’s definitely on the wish list but we’re not actively working on this yet. Out of curiosity, do you have any specific plans of what you’d want to use tEdDSA for?


Hi @Manu. Thanks for your reply.

Yes, I plan to have wallet integrates with lots of other blockchains, including some that don’t use ECDSA but do use EdDSA.

1 Like

Can you give a list of some EdDSA-only blockchains?

Here’s a list of the top 100 coins / tokens by market cap, compiled in Feb 2021.


There are some differences now because at least one of the chains have added ECDSA to their platforms now, but I don’t believe every chain has (yet).

Cardano added ECDSA and Schnorr signature support in Feb 2023.

1 Like

Hi Manu, what is the timeline for Schnorr? This is more important for the Bitcoin ecosystem, as many of the Bitcoin tokens are now using Schnorr signatures.

1 Like

Same as EdDSA, on the wishlist but not yet in progress so no clear timeline yet.

Could you elaborate on that? I didn’t really look into BRC-20 yet, is every token transfer there a new inscription (meaning you need schnorr to do transfers)?

That’s right. Every token transfer is a new inscription.

Double this.

L2 of Bitcoin wars coming, taproot aware and schnorr will help IC win it all.

First Ordinals and BRC, then RGB and others.

I think it is inevitable


You know, if the IC had a feature where each node could do its own private computation, it would probably be even possible for the community to implement new threshold signature schemes by incorporating existing libraries.

It would not even require too many changes to the protocol - just hacking the http outcalls feature. Allow nodes to combine the results of their custom resolvers instead of discarding them if they disagree; also allow them to store their own private variables, such as key-shares etc. This would enable users to write their own threshold signing schemes.

On a separate note, this would also help with making http outcalls more robust.

I know we would really like to have Schnorr signatures ASAP on the IC. Maybe a community call would help. @bob11 @Manu @dieter.sommer @neeboo ?

1 Like

Thanks for the input, I’ll look into it in a bit more detail and see what we can do.

Could you elaborate on this? How could a modification to the HTTP outcalls allow for threshold schnorr?

To do custom signatures, we need to basically have a system where:

  1. (Each node signs independently) This is achieved by allowing private variables to be used by nodes on the IC.
  2. A way for the nodes to communicate and combine the results of the signing. This could be achieved by allowing nodes to perform an http outcall to another node on the IC that aggregates the indiidually signed signatures.

I think it would be better to have a generic framework that lets others build the key-signing if necessary. This would allow the community to prototype and develop the feature faster, as the community could leverage open-source libraries for key-signing such as GitHub - Trust-Machines/frost: Rust implementation of Flexible Round Optimized Schnorr Threshold signatures

1 Like

I think this is a pretty drastic oversimplification :).

1 Like

We have to leave it to you clever cryptographers :). We all are very excited about this feature and want to push it forward.

@Manu Has the topic of threshold EdDSA / Schnorr moved forward yet within Dfinity, or are they still just ‘for the future’?


1 Like