feat: always-on fiduciary/test-threshold-keys subnets; split base topology from --subnet

[marc0olo]

Summary

• Enable fiduciary and TestThresholdKeys subnets unconditionally (alongside NNS) so they are always present regardless of flags
• Split subnets into two explicit categories:
  • Always-on base topology — nns, fiduciary, test-threshold-keys, created unconditionally
  • User-selectable workload subnets — application, system, verified-application, bitcoin, sns, selected via --subnet
• --subnet now controls only workload subnets. nns and fiduciary remain accepted as --subnet values for backward compatibility but have no effect; test-threshold-keys is not a --subnet value (it is always-on only)
• Remove the implicit II subnet enablement for --bitcoind-addr/--dogecoind-addr — it was only there to provide threshold keys, which are now always available via fiduciary and TestThresholdKeys
• Fix stale code comment and docs that incorrectly attributed threshold key hosting to the II subnet
• Update README and SPEC to describe the two categories and correct threshold key ownership

Background: pocket-ic versioning findings

This change is necessitated by a breaking behavior shift in pocket-ic that is already present in the v13.0.0-2026-05-21-04-45 release of this launcher — even though the pocket-ic standalone CHANGELOG only formally documents it under version 14.0.0 (2026-05-26).

Why the mismatch? The pocket-ic Rust client library lives in the IC monorepo (dfinity/ic) and is versioned independently from the standalone pocketic server (dfinity/pocketic). The IC monorepo rev pinned in v13.0.0-2026-05-21-04-45 (8115fd2) already carries pocket-ic crate version 13.0.0 with SubnetKind::TestThresholdKeys, SubnetConfigSet::test_threshold_keys, and PocketIcBuilder::with_test_threshold_keys_subnet() — meaning the bundled server binary from that date already implements the new key distribution, several days before the pocketic CHANGELOG documented it.

What changed in pocket-ic: test_key_1 and dfx_test_key (for ECDSA, Schnorr, and VetKd) are no longer held by the II or fiduciary subnets. They are now exclusively held by the new TestThresholdKeys subnet. Any workflow that relied on --ii to get threshold signing capability (including Bitcoin/Dogecoin integration) silently broke with this release.

What this fixes

• test_key_1 was unavailable in the local network even with --ii enabled, because the II subnet no longer holds threshold keys
• The README and code comment actively mislead: "II subnet provides threshold signature keys (tECDSA) needed for Bitcoin/Dogecoin signing" — this was already inaccurate (it was the fiduciary subnet on mainnet), and is now completely wrong in pocket-ic too

Design decisions

• TestThresholdKeys always on: restores the threshold key availability that users previously got implicitly via --ii, without requiring any flag changes from existing users
• Fiduciary always on: mirrors mainnet topology. Note pocket-ic models fiduciary as a singleton Option<SubnetSpec> (same as nns), so it can only ever be present once — grouping it with the always-on singletons matches what the API can express
• Base topology vs. workload split: nns/fiduciary/test-threshold-keys are created unconditionally and are not meaningful --subnet selections (selecting them is either a no-op or redundant). Keeping them in the --subnet enum conflated "always-on infrastructure" with "subnets the user picks" and produced contradictory docs. --subnet now means exactly one thing: which workload subnets to add
• nns/fiduciary kept as accepted-but-ignored --subnet values for backward compatibility; test-threshold-keys is new here so it was never exposed as a --subnet value
• II no longer implied by --bitcoind-addr/--dogecoind-addr: the only reason II was implicitly enabled for Bitcoin/Dogecoin was to provide test_key_1 for threshold ECDSA signing. Since TestThresholdKeys is now always on, that implicit is no longer needed. Users who also want the II canister for Bitcoin/Dogecoin testing can still pass --ii explicitly

Test plan

• Start the network with no flags — verify test_key_1 is accessible
• Start the network with --subnet=system (no application subnet) — verify test_key_1 is still accessible (threshold keys are independent of --subnet)
• Start the network with --ii — verify II canister installs and threshold keys are accessible
• Start the network with --bitcoind-addr=... — verify no II subnet is created and threshold signing still works
• Verify --subnet=nns / --subnet=fiduciary are accepted (no error) and --subnet=test-threshold-keys is rejected
• Confirm cargo check passes (already verified locally)

🤖 Generated with Claude Code