Threshold ECDSA Signatures

Taproot and threshold Schnorr signatures could be a next step after threshold ECDSA, but there’s no firm decision on this yet. When implementing threshold Schnorr, we can definitely leverage synergies from the work on threshold ECDSA, however, we still would need to define the protocol specification incl. a key derivation scheme, proof it secure, create a system design (lots of synergies) and implement it. So this is not something that can be done quickly.
Threshold ECDSA will also have other use cases, e.g., letting the IC act as a CA to issue security certificates in a decentralized manner, so we want to get it done anyway.
So, the plan is to get threshold ECDSA out and then think about Taproot and threshold Schnorr if this fits the priorities.

Regarding FROST, I have not had the time to look into it and do not know whether it would fit our requirements in terms of threshold etc. At least the key derivation scheme we require for our setting to derive canister keys and further keys per canister would need to be added to the protocol I think.
Maybe @victorshoup can give you a response on the viability of FROST. In case it would fit our needs, the integration in consensus would be a decent-sized project that we could only launch after completing threshold ECDSA.

Hope that answers your question sufficiently.


I’ll repeat the question because I don’t think it got an answer yet. Is EdDsa on the agenda or is there something in chain key tech that makes it more difficult or impossible?

Use case: Investors/Projects question the IC and ask why we don’t integrate with other chains. We get to counter that soon “all the chains will be IC chains” and we explain the ECDSA tech…everyone gets excited once they understan…but Solona, Cardano, Monero, and a few others use EdDSA and then our friends are sad again. It would be nice to tell them the same story even if they have to wait a bit longer than the ECDSA chains.


Our current target is threshold ECDSA, so that’s what we focus on right now. Once threshold ECDSA is available, threshold Schnorr / EdDSA (which is essentially Schnorr) should be relatively simple, I imagine we could reuse a lot of the work we’re doing for ECDSA now. But I don’t think it’s clear how this would be prioritize against all the other plans, so I wouldn’t want to make claims wrt a possible timeline.


Great to know it is possible! Thanks for the quick reply.

1 Like

Status update:
We have set a new (aggressively timed) milestone for implementing the signing protocol creating ECDSA signatures and thereby consuming the quadruples we can compute already: December 22.
After that we need to “iron out” the shortcuts we still have in there in order to get towards the final protocol. We’ll keep you posted!


Hmm, nobody bit this bait, so maybe I should make it clearer:

With canisters performing ECDSA signatures, it will be possible for canisters to control neurons (with a little help to submit ingress messages signed by the canister), and thus make neurons transferable. I assume this is not a new observation to @dieter.sommer and the rest of the team, but I am curious what the consequences are. I can see four possible consequences; is is clear which way we are heading?

  1. The system somehow tries to recognize canister-owned ECDSA keys and will not allow them in ingress messages, to plug this hole.
  2. Accept that canisters can own neurons this way, but not do anything about. If people really want canister-own or transferable neurons, they’ll have to jump through these hoops.
  3. Remove the restriction that neuron owners can’t be canisters, because it can be worked around anyways, canisters can already own ICP, and it opens up interesting applications like autonomous neurons.
  4. Additionally, simply make neurons transferable, given that they can be transferred using this feature.

I am struggling with making the logical leap to the transfer functionality conceptually.

Given that canisters already can manage self-authenticating principals with ICPs in them , I suppose that it is (or would be) possible for canisters to create neurons through those principals and hence become owner of the neuron through the self authentication principals.

The controlling of the neuron; including disbursement; would be possible as well.

I get lost while thinking about the transfer functionality. Could you elaborate a little on what exactly is meant by a transfer?


What method are you thinking of here? Canister signatures as used by the Internet Identity? Yes, these lead to the same conclusions, once they are accepted from any subnet, not just the root subnet. This is not yet the case, as far as I know.

You can’t change the controller of a neuron; this is an intentional restriction related to long term incentives or accountability or something like that. But if you put a controlling canister in between, you can now easily transfer ownership of the canister (which is unrestricted and not tracked), thus circumvent the restriction.


Yes. We are still stuck here. ic/ at master · dfinity/ic · GitHub.

Either this restriction will be lifted OR the allow https calls. This restriction is easier in many perspectives to being amenable to being lifted, imo.

Thanks. That was the missing link for me.

1 Like

Hi. Just want to make sure I understand. It sounds like this would only work for new neurons created using a canister and not for existing neurons. Is that right?

Correct. (Existing neurons can be transferred as well, in away, if you find a way to transfer the controlling cryptographic key. Send the yubikey by mail. Let the receiver take over your Internet Identity. Somehow convince the receiver that you deleted all copies of the secret key. I guess it is just a matter of hassle…)



We are close to reaching our milestone of having signature generation working end-to-end (with shortcuts in the implementation still being there) that has been scheduled for Dec 22. Most of the functionality for reaching this milestone is there, but the system API still needs to be hooked up so that canisters can make signing requests and responses can find their way back to canisters. As the holiday season starts now, milestone achievement will likely slip into the first week of the new year.


Could I request the foundation releases a means of verifying signatures with Motoko. Even outside of its intended use with Bitcoin this is an incredibly useful feature.

1 Like

Which signature schemes are you interested in?

Maybe Relevant with use cases for needing to verify signatures: Tackling CertifiedData in Motoko

Just having a Motoko lib capable of verifying the generated ECDSA signatures would be all I need.

FWIW, I definitely think that neuron transfer implications need to be explicitly addressed sooner rather than later, given that it sounds like neuron transfer will soon be possible.

Perhaps the most foundational concern (among a number) is that liquid democracy can be frustrated in a world with transferable neurons.

Neurons follow other neurons. So if a followed neuron is transferred, its followers end up following an entity they didn’t choose (the transferred neuron’s new controller). Neurons can be transferred without any record of the transfer. So how does liquid democracy work when followers can’t know that they’re following who they chose in the first place?

NNS voting today depends on liquid democracy. So IMHO, it’s critical to determine, at the very least, how liquid democracy will work when neurons soon become transferable.

@jwiegley and @johan, given that you are working on IC tokenomics and have previously alluded to the risks of neuron transfer, I would be interested in what may be in the works to address.

1 Like

Neuron transfer is inevitable. Liquid democracy != equal democracy. The more voting power one has the greater is the right to be heard. So if some neurons are bought by someone else, they will have greater voting power.

Also coming soon to a theater near you is the ability to self-borrow from your future self some percentage of your neuron’s present value; by temporarily suspending your internet identity linked to the neuron; repaying that loan through time. Think a model similar to Alchemy.

1 Like

Agreed: it sounds like neuron transfer is inevitable. Hence why its biggest risks need to be addressed.

The concern above isn’t about those more invested in the IC getting more VP.

The concern is that untracked neuron transfer (to a new neuron controller) means that follower neurons can end up following new neuron controllers they don’t want to. So the idea of liquid democracy as currently implemented breaks down.

Have to say I agree with this, although even with the ECDSA I don’t think it’s 100% secure. Who knows whether Dfinity will suspend the chain-key api in future or unavailable. However, even if Dfinity puts in blocks on using the ECDSA signatures then some other org/chain whatever with the technology will make it possible. It’s inevitable imo.

1 Like