Questions on confidential (SEV-SNP) subnets

Developers Rust
1

Context: we are building a vault canister that runs a full Mimblewimble wallet (Epic Cash) inside a canister, and we intend to deploy it on the confidential subnet re2t4. Every replica necessarily holds the whole wallet seed, and Mimblewimble has no scripts, so the confidentiality of that seed is the entire custody story. We need precise answers to the following before we put real value on the subnet.

A. What the hardware guarantees today

  1. Peer attestation. Do replicas on re2t4 / x4jtx now verify each other’s SEV-SNP attestation (measured GuestOS on an SNP-enabled platform) when they establish TLS sessions, or is the registry sev_enabled membership invariant (proposal 141264) currently the only guard? If peer attestation is not enforced yet, when will it be?

  2. Joining nodes. When a node is added to a confidential subnet (replacement or expansion), must it attest before it receives subnet state via state sync? Are state-encryption keys rotated when a node leaves?

  3. Plaintext exits. Is there any path by which canister state or execution data leaves the encrypted VM in plaintext: replica logs or metrics, checkpoints on disk, state sync, backups, or the read-only / recovery SSH paths enabled via SetSubnetOperationalLevel? Is disk and state encryption keyed to the measured VM so that a node provider cannot read checkpoints at rest?

  4. Recovery. If the NNS approves a recovery (read-only or recovery SSH keys, or an alternate root filesystem when the orchestrator is down), who can read canister state during that window, and what prevents a recovery from exposing secrets held by a canister on a confidential subnet?

B. Threat model

  1. Is there a written threat model for confidential subnets beyond the Learn Hub article? Specifically: is DRAM bus interposition by a node provider with physical access (Battering RAM on DDR4 Gen2 hardware, TEE.fail on DDR5) treated as in scope or explicitly out of scope? Same question for side channels and for AMD firmware / secure-processor compromise.

  2. Is long-lived, high-value key material that every replica holds in full (for example a wallet seed) an intended workload for confidential subnets today, or do you consider that premature? If premature, what would change the answer: peer attestation, Gen3 hardware, larger subnets, something else?

C. Verification

  1. Can a canister controller, or any third party, obtain and verify evidence (SNP attestation report, certified registry data, or equivalent) that a given subnet’s replicas are running a specific published GuestOS measurement under SEV-SNP? If not today, is this on the roadmap, and when?

  2. Beyond the dashboard’s “Confidential” label, how can a developer confirm their canister is executing under SEV on every replica and not on any non-SEV fallback?

D. Operations and economics

  1. Pricing. How are cycles priced on re2t4? We read SEV_REFERENCE_SUBNET_SIZE = 7 in the replica source as “a 7-node SEV subnet is billed at standard 13-node rates”. Is that right, and is it expected to hold?

  2. Migration. Will canister migration into a confidential subnet be supported, or is fresh deployment the only path? Will migration out be possible?

  3. Size and capacity. re2t4 is 7 nodes and currently has one node down. Are 13-node confidential subnets planned? What are the plans for opening x4jtx and for additional confidential subnets, given the roughly 44 TEE-active nodes currently unassigned? Is renting a dedicated confidential subnet an option for a funded team?

  4. Operational differences. Is there anything we should design around on confidential subnets that differs from ordinary application subnets: upgrade downtime characteristics, the 120k canister cap, state-size limits, HTTPS outcall behavior with 7 nodes?

E. Roadmap

  1. vetKeys. Is there any supported or planned way for a canister, not an end-user client, to use a vetKD-derived secret without exposing it to the executing replicas?

  2. Threshold primitives. Any plans to expose lower-level threshold secp256k1 operations (secret-shared scalar arithmetic, range-proof-compatible primitives)? A threshold Mimblewimble wallet would be new for Chain Fusion and we would be a willing test case.

  3. Who is the right engineering contact for a confidential-subnet workload like this?

Thanks ahead for any reply - even partial would be helpful. We’ve been unsuccessful in getting any response on the Discord.