As asked here about tecdsa Subnets with heavy compute load: what can you do now & next steps - #18 by Jesse
I guess the same question could be asked of vetkeys. If you have to bail on a subnet and get a new canister ID, all those keys will be lost to you?
The vetKeys feature is designed such that, as also mentioned above, the calling canister’s principal is implicitly part of the derivation information. That means that if keys are derived with a different canister (meaning it has a different canister ID), then the derived keys will be different, even if the same derivation information is used.
So, if you want to manually “move” a canister to a different subnet so that it has a different=new canister ID, you first have to come up with a migration strategy for data that is encrypted with vetKeys you derived with the old canister. Once you delete the old canister, you loose the ability to derive vetKeys relative to its (old) canister ID.
How exactly the mentioned migration looks like very much depends on how the vetKeys were used.
Engineering has recently begun working on the system integration of vetKeys. The ETA of the production release is end of Q1/2025 - beginning Q2/2025.
You have been saying the same since early 2023
Hey @Catthew,
there have been multiple stages towards vetKeys that required different teams from R&D.
First stage was research which was done in 2023 and published here: vetKeys: How a Blockchain Can Keep Many Secrets
Second stage was implementing a developer preview to define the APIs, create a small SDK and allow developers to get experience working with the new primitive and provide feedback. We’ve sponsored this with bounties.
In both of these stages only individual R&D teams had needed to be involved. For the final stage, the system integration which now started, multiple R&D need to coordinate, and other work like general performance improvements as well as threshold Schnorr/EdDSA has been prioritized over vetKeys.
Is the proposed vetkey API with hard-coded key available in main net? Or only in a local replica?
Can it be called only by a canister or also by an external principal?
Yes, vetkeys API with a hard-coded key is implemented in the chainkey testing canister, which is available on mainnet (vrqyr-saaaa-aaaan-qzn4q-cai), i.e., the caller needs to call that canister instead of the management canister. The key ID supported there is insecure_test_key_1.
AFAICT, the chainkey testing canister currently allows calls by external principals, but maybe this will be changed in the future to keep the API as close as possible to the management canister API.
Where can I find an estimate of the cycles costs for the upcoming vetkd_public_key and vetkd_encrypted_key APIs?
Is it reasonable to expect a cost similar to the threshold ECDSA API?
We are currently in the process of determining the price, but didn’t make a final decision yet.
Yes. It is safe to assume that the API fees for threshold signatures (tECDSA/tSchnorr) are an upper bound for the fees for threshold key derivation (vetKD/vetKeys). It is a likely scenario that the fees for vetKD will be the same as for tECDSA/tSchnorr, at least initially.
Hello! Here is a quick update from the DFINITY team. As we are progressing in our integration of threshold key derivation (aka the vetKeys feature) into the Internet Computer Protocol, we also made some minor adaptions to the expected vetKD API (see this commit). In particular:
the IC method vetkd_encrypted_key was renamed to vetkd_derive_encrypted_key to better express the action that is done (key derivation) and to be more in line with names like sign_with_schnorr and sign_with_ecdsa .
the argument field public_key_derivation_path was renamed to public_key, so that both derivation path arguments (one per API) have the same name
the key_id’s curve was renamed from bls12_381 to bls12_381_g2 to be more precise, more future-proof, and to make it obvious that the master public key is in group G2
The various vetKD-related examples all have been updated accordingly (see examples/pull/1087). The chainkey-testing-canister was updated as well, (see chainkey-testing-canister/pull/9) and it was re-deployed.
Can the vetKey API be called from an external principal? Or only from canisters because it requires payment?
The vetKey APIs will only be callable by canisters. Last week, I also adapted the IC spec PR to explicitly mention this (“This method can only be called by canisters, i.e., it cannot be called by external users via ingress messages”).
I updated the file sending demo so that it uses the new VetKD system interface.
looking forward vetkey
Slowly catching up on this and drawn back to the conversation by the latest roadmap update. Do we have an estimated date for vetKeys release?
As we are getting closer to the release of the VetKeys feature we would like to share a preview of the tooling, and ask for your feedback.
We’re inviting the community to test, explore, and provide feedback on the API design and overall usability before we finalize these libraries.
Tools to help canister developers integrate VetKeys into their Internet Computer (ICP) applications.
Tools for frontend developers to interact with VetKD enabled canisters.
The VetKey Password Manager is an example application demonstrating how to use VetKeys and Encrypted Maps to build a secure, decentralized password manager on the Internet Computer (IC). This application allows users to create password vaults, store encrypted passwords, and share vaults with other users via their Internet Identity Principal.
The example application is available in two versions:
We want to ensure that VetKeys and these libraries are intuitive, secure, and developer-friendly. If you’re considering implementing VetKeys in your project or just want to try it out, your feedback is invaluable.
Here are some specific areas where we’d love to hear from you:
Ease of Use – Was it straightforward to integrate the libraries into your project?
API Clarity – Are the APIs well-designed, or do certain methods feel confusing or redundant?
Security Considerations – Do you see any potential risks or areas for improvement in key management and encryption?
Performance – How does the current implementation perform in real-world use cases? Are there any noticeable bottlenecks?
Missing Features – Are there any functionalities you expected but couldn’t find?
Developer Experience – How was the documentation? What could be improved in the examples or setup?
Management Canister API Feedback – If you’ve worked directly with the VetKeys management canister API, do you have any insights on its usability and effectiveness?
Try out the examples and explore the libraries.
Report issues or suggestions in this thread.
Share your experience—we’ll be using community feedback to refine the final release.
Looking forward to your feedback! 
Is there also a Motoko example available?
Thank you for the update. Quick question: what is the cost of each basic operation and wen for mainnet?
Is the CDK really meant for canisters or is it actually a Rust SDK analogous to the other (js) SDK?
Asking because it contains get_encrypted_vetkey which you don’t want to call from a canister because you don’t want to handle secrets in a canister. Same applies to EncryptedMaps.
