Hey @kristofer, in your example, you use the package via .tgz file. I’m trying to figure out if I can do it some other way. Because if I wanted to just launch the frontend without dfx, lets say to make some UI changes, having a .tgz file as a dependency won’t allow me to do that. So I’ll have to do dfx deploy and that just takes too long for quick UI changes.
If using the demo I created, you would just start the Vite development server to get hot module reloading of all UI changes during development.
pnpm run dev
1 Like
Hey @kristofer, yeah checked that, were some differences between your and my project config so had to adjust that to make the hot reloading work. Just for anyone wondering I’ll also post the working vite config below.
import { sveltekit } from "@sveltejs/kit/vite";
import type { UserConfig } from "vite";
import { defineConfig, loadEnv } from "vite";
import {
host,
iiUrl,
network,
readCanisterIds,
} from "./scripts/readCanisterIds";
import path from "path";
import wasm from "vite-plugin-wasm";
import topLevelAwait from "vite-plugin-top-level-await";
// Import the new polyfill plugin
import { nodePolyfills } from 'vite-plugin-node-polyfills';
const config: UserConfig = {
// Add nodePolyfills plugin here
plugins: [wasm(), topLevelAwait(), sveltekit(), nodePolyfills()], // Moved wasm() and topLevelAwait() first
resolve: {
alias: {
$lib: path.resolve("./src/frontend/src/lib"),
// Removed alias for ic-vetkd-utils to let Vite handle it
},
},
// Remove optimizeDeps polyfill config, let the plugin handle it
optimizeDeps: {
esbuildOptions: {
// Node.js global to browser globalThis - Still might be needed depending on dependencies
define: {
global: "globalThis",
},
},
},
// Keep single build config
build: {
target: "es2020",
rollupOptions: {}, // Remove the polyfill plugin from here
},
// Add SSR configuration to process ic-vetkd-utils
ssr: {
noExternal: ['ic-vetkd-utils'],
},
};
export default defineConfig(({ mode }: UserConfig): UserConfig => {
// Expand environment - .env files - with canister IDs
process.env = {
...process.env,
...loadEnv(mode ?? "development", process.cwd()),
...readCanisterIds({ prefix: "VITE_" }),
VITE_DFX_NETWORK: network,
VITE_HOST: host,
VITE_II_URL: iiUrl,
};
return {
...config,
// Backwards compatibility for auto generated types of dfx that are meant for webpack and process.env
define: {
"process.env": {
...readCanisterIds({}),
DFX_NETWORK: network,
},
},
};
});
3 Likes
Great! Also note that as part of the final VetKey release, there will be a JS based utils library.
4 Likes
We’re excited to share that the vetKeys feature is now code complete and ready to be enabled on mainnet for testing purposes! 
In line with the release process used for previous cryptographic features like threshold ECDSA and Schnorr signatures, we are proposing to create a test vetKD master key on a 13-node application subnet. This will allow us to:
-
Conduct extended testing of vetKeys functionality on mainnet.
-
Build confidence with operational procedures, including key backup and recovery workflows.
-
Enable developers to experiment with the full vetKeys derivation functionality in their dApps.
-
Identify edge cases and gather insights into performance and system behavior.
Important Note: The test vetKey is strictly intended for testing purposes and should not be used in production environments. The vetKeys feature is still undergoing internal security reviews and audits, and as such, we strongly recommend limiting its use to non-critical testing scenarios only.
Next steps
If this proposal is approved, we will submit follow-up proposals to:
-
Back up the test key on an additional application subnet.
-
Enable vetKeys derivation functionality to support end-to-end testing.
Following a successful testing phase—and assuming everything proceeds smoothly—we plan to propose the creation of the production key in later governance proposals. The earliest expected timeline for this would be mid-June.
26 Likes
Thanks @andrea, I have a few questions before voting if that’s okay. My understanding is that 2fq7c is currently the backup test key subnet (whereas it used to be the signing subnet, prior to 131449). In prior test key deployments the procedure has been to:
- Generate the test key on the signing subnet
- Enable the key afterwards
- Reshare the key to the backup subnet (using a set of halt, apply CUP, unhalt proposals)
In this case it seems the approach planned is to:
- Generate the test key on the backup subnet
- Reshare the key with the signing subnet (using a set of halt, apply CUP, unhalt proposals)
- Enable the key afterwards (on the signing subnet? Is there a plan to enable and test it on the backup subnet too?)
Have I understood this more or less correctly? If so would you be able to elaborate on the choice to deviate from previous procedure (including resharing to the signing subnet, instead of to the backup subnet, despite the downtime implications).
I’m also curious about a couple of the parameters.
"max_queue_size": 10,
"pre_signatures_to_create_in_advance": 0
max_queue_sizeis 20 for the other 3 keys, on both the signing and the backup subnet. Could I ask what the reasoning is for setting it to 10 in this case?pre_signatures_to_create_in_advanceis set to 1 for the other 3 keys on this backup subnet (and 7 on the signing subnet). Can I ask why it’s being initialised with 0 here?
Thanks in advance 
3 Likes
Proposal 136589 Review | Lorimer - CO.DELTA △
VOTE: YES
TLDR: See questions above, and answers below. LGTM
You may wish to follow the CO.DELTA known neuron if you found this analysis helpful.
CO.DELTA △
We’re a verifiably decentralised collective who review IC deltas (changes applied by NNS proposals). We follow a common code:
- Look: We observe the details and context of NNS proposals
- Test: We test and verify the claims made by those proposals
- Automate: We automate as much as possible by building increasingly sophisticated tools that streamline and strengthen the reviewal process.
Every vote cast by CO.DELTA is the result of consensus among diligent, skilled and experienced team members acting independently. The CO.DELTA neuron follows the vote of D-QUORUM on NNS topics that the CO.DELTA team does not handle directly. You can therefore follow CO.DELTA on all topics and rely on the highest quality of vote.
2 Likes
Yes, that’s exactly the plan. We plan to propose enabling the signing subnet once the key is reshared there. The reason we are proposing to start with the backup subnet is that 2fq7c seems busier and has a considerably larger state, so it seems less disruptive to halt the other one for resharing. Note that we proposed to swap signing and backup subnets a few months for the same reason, i.e. have signing enabled on the less busy subnet.
6 Likes
Good questions! It should be fine to set max_queue_size to 20 and higher values, however we have not done enough load testing yet on realistic scenarios, especially with larger subnet sizes. So we are proposing some conservative value here with the intention of increasing it later on.
Regarding pre_signatures_to_create_in_advance, this parameters does not affect vetkd, as the scheme does not use presginatures, differently than ECDSA and Schnorr. However since vetkeys reuses the same chain key config record as ECDSA and Schnorr, this value has to be set currently. Note that until recently it was not possible to set it to 0, so 1 was the minimum, see here for more details: feat: CRP-2618 Allow zero `pre_signatures_to_create_in_advance` in vetKD `ChainKeyConfig` by eichhorl · Pull Request #5014 · dfinity/ic · GitHub
5 Likes
Proposal #136589 — Zack | CodeGov
Vote: Pending, probably YES
Reason: Checking some related commits from the latest replica updates.
About CodeGov
CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these technical topics. We also have a group of Followees who vote independently on the Governance and the SNS & Neuron’s Fund topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralization of SNS projects such as WaterNeuron, KongSwap, and Alice with a known neuron and credible Followees.
Learn more about CodeGov and its mission at codegov.org.
1 Like
Thanks for clarifying @andrea, sounds good. I’ve voted to adopt
2 Likes
Proposal 136589 Review | aligatorr - CO.DELTA △
VOTE: YES
TLDR: It is a testing subnet. Proposal adds chain key configuration for Vet keys.
- Rest of chain key config remain unchanged
- Replica version of a subnet f195ba756bc3bf170a2888699e5e74101fdac6ba
- set_gossip_config_to_default is supposed to be deprecated, is there a plan to remove it @andrea ?
0 Warnings
1 Improvements
-
Configuration for VetKeys
-
Subnet has been set gossip config to FALSE.
You may wish to follow the CO.DELTA known neuron if you found this analysis helpful.
CO.DELTA
We’re a verifiably decentralised collective who review IC deltas (changes applied by NNS proposals). We follow a common code:
-
Look: We observe the details and context of NNS proposals.
-
Test: We test and verify the claims made by those proposals.
-
Automate: We automate as much as possible by building increasingly sophisticated tools that streamline and strengthen the reviewal process.
Every vote cast by CO.DELTA is the result of consensus among diligent, skilled and experienced team members acting independently. The CO.DELTA neuron follows the vote of D-QUORUM on NNS topics that the CO.DELTA team does not handle directly. You can therefore follow CO.DELTA on all topics and rely on the highest quality of vote.
4 Likes
Proposal 136589 | Tim - CodeGov
Vote: Adopt
This proposal generates a vetKD master key for testing purposes on subnet 2fq7c. Thanks @Lorimer and @andrea for the very helpful discussion above clarifying details of the payload parameters.
About CodeGov
CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these technical topics. We also have a group of Followees who vote independently on the Governance and the SNS & Neurons’ Fund topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralisation of SNS projects such as WaterNeuron, KongSwap, and Alice with a known neuron and credible Followees.
Learn more about CodeGov and its mission at codegov.org.
1 Like
Hello everyone! With the execution of proposal 136589, the test key for the vetKeys feature was generated on 2fq7c. As announced above we plan to submit follow-up proposals to reshare the test key to subnet fuqsr. See also here for more information about the process.
4 Likes
Does this mean key derivation has also been activated?
1 Like
Proposal 136589 Review | Malith H - CO.DELTA △
VOTE: YES
TLDR:
The following proposal introduces Vet keys for subnet configuration for testing purposes 2fq7c. Diff change config only introduces Vetkeys, no other change has been made. As mentioned by @aligatorr89 set gossip config to FALSE, or is it say no change is been made ?
Context
| Item | Notes |
|---|---|
| Subnet ID | 2fq7c |
| Replica version currently live | |
| Proposal’s stated reason | Generate a vetKD master key for testing purposes on subnet 2fq7c, with key ID Bls12_381_G2:test_key_1. |
| Forum discussion reviewed | YES |
You may wish to follow the CO.DELTA known neuron if you found this analysis helpful.
CO.DELTA
We’re a verifiably decentralised collective who review IC deltas (changes applied by NNS proposals). We follow a common code:
-
Look: We observe the details and context of NNS proposals
-
Test: We test and verify the claims made by those proposals
-
Automate: We automate as much as possible by building increasingly sophisticated tools that streamline and strengthen the reviewal process.
Every vote cast by CO.DELTA is the result of consensus among diligent, skilled and experienced team members acting independently. The CO.DELTA neuron follows the vote of D-QUORUM on NNS topics that the CO.DELTA team does not handle directly. You can therefore follow CO.DELTA on all topics and rely on the highest quality of vote.
Not yet, as discussed above it was generated on the subnet we plan to use as backup. Enabling the key will require a separate proposal that will be submitted later on.
2 Likes
Hi @andrea
This is super cool. Have been following with interest. Am I correct that vetSigs are not part of this rollout but coming later this year?
2 Likes
With vetSigs do you mean BLS signatures? If so, you can use the vetkeys API to compute them, we are working on an example to show how. Do you have a concrete example in mind for this?
1 Like
Yep that’s exactly what I mean. The example is the plan I have for our decentralised publishing app:
We’re going to issue users with a BBS+ credential (so they can do selective reveal and have pseudonyms linked to their main ID via ZK). We were thinking of having an ICP canister as a trusted issuer of these credentials. However if the canister held the key all the replicas could see it. That’s not workable. With vetKeys replicas would only ever have a shard and could issue credentials with threshold BLS.
3 Likes