Why SEV is not enabled:
I should have been more clear about this. This is not yet a fully SEV-protected subnet, but a subnet that consists only of SEV-enabled nodes. For it to be fully SEV-protected, we need one more feature: mutual attestation among the SEV-enabled nodes. This means that the nodes always check whether the other node they are talking to is fully SEV-enabled and only connect in that case.
We are working on this and it will be the next step.
Why do we need a new subnet instead or repurposing an existing one:
This is a fair point. Since this is a big step and mainly used for testing, we prefer not to “carry” over old baggage. Even if the subnet has not been hosting any canisters, it still has been doing work and has some history.
Why is there no cap on the number of canisters?
This is an oversight on our end, but as @Zane highlighted, there is a default value that is set to 120_000.
Thank you for all your detailed responses, as of 2026-02-16, 11:09:01 AM UTC the proposal 140407 is Adopted and Executed at 2026-02-16, 11:16:10 AM UTC. Looking forward for feedback from testing.
Do we have a rough ETA for this? Is that also the moment we would allow deployments from the general public to this subnet or create a new one that allows that? (cc @dominicletz)
Are there estimates for cycle costs on these subnets? Will there be a modifier or adjustments for particular operations? I’d imagine that things like ingress and cross subnet calls would require more(maybe much more) maths. Although possibly this is optimized in silicon?
Hey @skilesare
There are no estimates yet. However, there will be an adjustment of the cycle costs due to the increased security compared to a normal subnet and the overhead of the full VM encryption that comes with SEV-SNP.
Hello everyone,
a quick update on the SEV subnet. So far, it has been running smoothly (without any load of course) and has undergone two successful upgrades: proposal 140513 and proposal 140534.
We are planning to submit a proposal to authorize principal owned by the node team to deploy test canisters on the subnet and run some tests with load. I will keep you updated as soon as the proposal is out.
Hello everyone,
The node team is currently planning the next steps towards public SEV-enabled subnets on the Internet Computer.
The SEV test subnet (re2t4) has been operational for nearly two weeks now and successfully completed two upgrades. However, there was no workload so far. It has just been idle.
This is what we aim to change in the next step: We have just submitted a proposal to authorize the node team to install canisters on the SEV test subnet (see proposal #140590). This will allow us to conduct further testing with a workload. As the SEV test subnet is a standard application subnet, we will be covering all associated cycle costs for our testing.
Let us know if you have any questions or feedback!
Thanks a lot for your support! Happy voting!
We were patiently waiting to see some testing done with subnet re2t4 with 0 canisters and only the blocks number going up with an average finalization rate of 2.3/s. felt like C'mon do smth meme.
- CO.DELTA △VOTE: YES
LGTM, payload checks out and I don’t see any problems with the proposal in general.
You may wish to follow the CO.DELTA known neuron if you found this analysis helpful.
We’re a verifiably decentralised collective who review IC deltas (changes applied by NNS proposals). We follow a common code:
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: It sets principal 2igsz-4cjfz-unvfj-s4d3u-ftcdb-6ibug-em6tf-nzm2h-6igks-spdus-rqe to be able to deploy canisters on re2t4 subnet.
Current → Proposed Public subnet count: 27 → 27
Current → Proposed Authorized subnet count: 22 → 22
You may wish to follow the CO.DELTA known neuron if you found this analysis helpful.
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.
@rbirkner is it possible that we deploy a couple of canisters to it? We want to test-benchmark our newly implemented quantum signatures, some of the tests would need max 3 canister
Hello everyone,
We’ve just submitted proposal 141264 to set the sev_enabled feature flag on the TEE subnet (re2t4).
To be clear, all 7 nodes in this subnet are already running as TEE-enabled nodes and have been running as TEE-enabled since the subnet was created. This proposal simply sets the sev_enabled field to true in the registry subnet record.
What does this flag do? It enforces a registry-level invariant that every node in the subnet must be a TEE-enabled node (specifically, each node must have a chip_id in its node record). With this flag set, if a future proposal tries to add a non-TEE node to this subnet, even if the proposal is adopted, the change will not take effect. This ensures the subnet always remains fully TEE-enabled.
Hey @MeneseProtocol, soon we will open the subnet up and you will be able to deploy your canister.
That’s really great thank you, it should enable very cool things.
VOTE: YES
TLDR: Enable SEV.
You may wish to follow the CO.DELTA known neuron if you found this analysis helpful.
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.
