Over the past few weeks, we’ve been testing the vetKeys protocol on subnets 2fq7c and fuqsr. These tests successfully exercised operational tasks such as master key generation and backup, as well as validated the full end-to-end flow of key derivation.
We’re now proposing to move vetKeys to the next phase by generating the production key, which will proceed in the following stages:
June 20 – Propose key generation: We will submit an NNS proposal to generate a production vetKD key on subnet pzp6e, the fiduciary subnet that also holds the production ECDSA and Schnorr keys. The key will use key ID Bls12_381_G2:key_1.
June 26 (8AM UTC) – Backup the key: The production key will be backed up to a second subnet, uzr34, which also serves as the backup for ECDSA and Schnorr keys.
June 27 – Propose enabling the production key: After successful backup, a final proposal will be submitted to enable the vetKey for public use, making it available to canisters via the vetKD API.
Internet Identity scheduled Downtime - June 26, 8AM UTC
The backup step on June 26 requires temporarily pausing subnet uzr34 while the key is being reshared. This operation is not yet fully automated and involves a sequence of three NNS proposals submitted and executed in order. The same process was exercised recently to backup the vetKD test key to subnet fuqsr.
As a result, subnet uzr34, which hosts the Internet Identity (II) canister, will be unresponsive for approximately 5–10 minutes. During this brief downtime:
New II sessions cannot be initiated
Existing sessions remain unaffected
Dapps using II will continue to operate normally for logged-in users
We recognize the inconvenience this may cause and will work to minimize the impact.
We’ll continue to share updates as each step progresses. In the meantime, feedback and discussion are welcome!
TLDR: The last time chain_key_config was updated on this subnet was Proposal: 131474. This proposal (Proposal: 137075) maintains the existing config, and appends an entry for Bls12_381_G2:key_1, as described in the announcement above.
Here’s a diff of the payloads. Other than difference in case (for case insensitive fields), and the removal of deprecated fields, the only change is the one described in the proposal summary.
max_queue_size was set to 10 on the test subnets first before increasing to 20 (matching the other keys). Unlike the test subnets which have 13 nodes, this signing subnet (and the backup subnet) have 34 nodes. @andreapreviously mentioned the need to test queue size on larger subnets before increasing (this proposal sets it to 10).
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.
The max_queue_size value 10 follows the same direction from previous proposals. This was the same sequence for subnet fuqsr where in proposal 136899 it’s max_queue_size was increased to 20 since it was deemed that the subnet could sustain a higher number of parallel requests as explained here.
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.
This proposal generates the vetKD production key on subnet pzp6e. Using the ic-admin tool (link to documentation no longer works; the relevant command is ic-admin --nns-url=https://ic0.app get-subnet <SUBNET_ID>) I verified that the current chain_key_config settings for this subnet match the proposal payload with the exception that details for the bls12_381_g2 key are being added anew by this proposal, with settings matching those initially used for the test key in proposal 136589.
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, API Boundary Node 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.
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.
VOTE: YES TLDR:
This proposal adds key config for Vetkeys for subnet pzp6e. This was after a successful test on subnet fuqsr on previous proposals.
As mention here on the forum post pzp6e will hold proudction ECDSA and Schnorr keys. The key will use key ID Bls12_381_G2:key_1 .
Property
Details
Subnet
pzp6e
Keys Secured
ECDSA Production Key Schnorr Production Key Upcoming: vetKD → Bls12_381_G2
Next step: Backup to uzr34 (June 26) → enabling the production key(June 27)
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.
Reason:
In line with the ongoing discussion and detailed information about all the steps, the proposal generates the production key Bls12_381_G2:key_1 for vetKD by adding to the config:
Reason:
The proposals are correct and are inline with the steps highlighted following adopted proposal 137075.
Halts subnet uzr34 at the next CUP height by setting halt_at_cup_height to true.
Reshares the vetKD master key Bls12_381_G2:key_1 to subnet uzr34 by updating the recovery CUP.
Unhalts subnet uzr34 by setting is_halted to false.
And last one enables subnet pzp6e to use the vetKD production key Bls12_381_G2:key_1.
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.
As announced, tomorrow we will proceed with the backup of the vetKeys production key to the II subnet. The first proposal (137123) is already out for review and once executed will pause the II subnet at a CUP height.
TLDR: This proposal will halt the subnet at the next catch up package after it executes. This is intentional, and has been announced above.
I’ve adopted early given that it will take significantly more VP to push this over the execution threshold (scheduled for tomorrow). I’m looking forward to verifying the catch up package on the follow up proposal to unhalt this subnet
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.
The second proposal (out of three) for the backup of the vetKeys production key on subnet uzr34 is 137131. This proposal replaces the recovery CUP in the registry, and reshares all the production threshold keys to subnet uzr34, including the vetKD key Bls12_381_G2:key_1.
As described in this forum post, the following instructions may be used to verify the subnet’s latest CUP and the recovery proposal:
bazel run //rs/cup_explorer:cup_explorer_bin -- verify-cup-of-halted-subnet --cup-path /ic/uzr34_cup.pb
The output should include the following message:
"Confirmed that subnet uzr34 was halted on this CUP."
"This means that the CUP represents the latest state of the subnet while the subnet remains halted."
"The subnet may ONLY be restarted via a recovery proposal using the same state hash as listed above."
TLDR: This proposal applied a CUP to the II subnet while it was halted. I’ve used the new tool to verify the specified CUP hash is correct and was produced by halting this subnet. Proposal 137130 also supplied the key material that was generated by Proposal 137075 on the Fiduciary subnet (the signing subnet). The II subnet acts as the backup subnet.
Note that the key isn’t enabled yet. This is scheduled for the Fiduciary subnet tomorrow based on the announcement here.
The last time key material was reshared to the II subnet was August last year, by Proposal 131510. Below is a diff of the payloads. Aside for changes in case for case insensitive fields, the CUP hash and height, we see the Bls12_381_G2:key_1 details are appended to the key config.
We also see that the CUP hash matches the output from the verification tool, which also confirms the origin of the CUP.
Reading CUP file at "/ic/uzr34_cup.pb"
CUP integrity verified!
Checking CUP signature for subnet uzr34-akd3s-xrdag-3ql62-ocgoh-ld2ao-tamcv-54e7j-krwgb-2gm4z-oqe...
Getting registry value of key catch_up_package_contents_uzr34-akd3s-xrdag-3ql62-ocgoh-ld2ao-tamcv-54e7j-krwgb-2gm4z-oqe at version 51509...
CUP signature verification successful!
Latest subnet state according to CUP:
TIME: 1750924730644446051, (2025-06-26 07:58:50.644446051 UTC)
HEIGHT: 100596000
HASH: e45b2b3f06469a1199487a582e7d5bd5076a917f46fcbf68656b6b55ad87f33f
REGISTRY VERSION: 51509
Verifying that the subnet was halted on this CUP...
Getting registry value of key subnet_record_uzr34-akd3s-xrdag-3ql62-ocgoh-ld2ao-tamcv-54e7j-krwgb-2gm4z-oqe at version 51509...
Confirmed that subnet uzr34-akd3s-xrdag-3ql62-ocgoh-ld2ao-tamcv-54e7j-krwgb-2gm4z-oqe was halted on this CUP as of 2025-06-26 07:58:50.644446051 UTC.
This means that the CUP represents the latest state of the subnet while the subnet remains halted.
The subnet may ONLY be restarted via a recovery proposal using the same state hash as listed above.
Searching for a recovery proposal...
Getting registry value of key catch_up_package_contents_uzr34-akd3s-xrdag-3ql62-ocgoh-ld2ao-tamcv-54e7j-krwgb-2gm4z-oqe at version 51510...
Found Recovery proposal at version 51510:
TIME: 1750924816209467626
HEIGHT: 100597000
HASH: e45b2b3f06469a1199487a582e7d5bd5076a917f46fcbf68656b6b55ad87f33f
Ensuring recovery time is greater than CUP time...
Success!
Ensuring recovery height is greater than CUP height...
Success!
Ensuring recovery state hash is equal to CUP state hash...
Success!
The subnet was correctly recovered without modifications to the state!
We also see that the specified recovery height is larger than the halting height. My understanding is that the exact amount is arbitrary (in this case 1000).
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.
TLDR: Simply unhalts the subnet following adoption of the key resharing proposal described above. LGTM
Looking forward to the key being enabled on the signing subnet tomorrow (Fiduciary subnet).
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.
II subnet was recovered with same state as it was halted, time and were greater as well.
Do we know how was the recovery height 100597000 selected? Halt was at 100596000 which is 1000 less.
Latest subnet state according to CUP:
TIME: 1750924730644446051, (2025-06-26 07:58:50.644446051 UTC)
HEIGHT: 100596000
HASH: e45b2b3f06469a1199487a582e7d5bd5076a917f46fcbf68656b6b55ad87f33f
REGISTRY VERSION: 51509
Verifying that the subnet was halted on this CUP...
Getting registry value of key subnet_record_uzr34-akd3s-xrdag-3ql62-ocgoh-ld2ao-tamcv-54e7j-krwgb-2gm4z-oqe at version 51509...
Confirmed that subnet uzr34-akd3s-xrdag-3ql62-ocgoh-ld2ao-tamcv-54e7j-krwgb-2gm4z-oqe was halted on this CUP as of 2025-06-26 07:58:50.644446051 UTC.
This means that the CUP represents the latest state of the subnet while the subnet remains halted.
The subnet may ONLY be restarted via a recovery proposal using the same state hash as listed above.
Searching for a recovery proposal...
Getting registry value of key catch_up_package_contents_uzr34-akd3s-xrdag-3ql62-ocgoh-ld2ao-tamcv-54e7j-krwgb-2gm4z-oqe at version 51510...
Found Recovery proposal at version 51510:
TIME: 1750924816209467626
HEIGHT: 100597000
HASH: e45b2b3f06469a1199487a582e7d5bd5076a917f46fcbf68656b6b55ad87f33f
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.
Halt Verification: Confirmed the subnet was halted at height 100 596 000 as of 07:58:50 UTC.
Recovery Proposal Checks: Found the recovery proposal at height 100 597 000 with the same state hash, recovery time > CUP time, and recovery height > CUP height—all marked “Success!”
TLDR:
Halts subnet uzr34 at the next Catch-Up Package so the vetKD production key (Bls12_381_G2:key_1) can be securely reshared. Downtime was pre-announced by DFINITY
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.
Upcoming: 
