Short answer: Not directly today it is not possible to use betKeys with a cloud Engine. Cloud engine subnets are not provisioned with a vetKD threshold key. A relay-based workaround will become available soon.
Symptom
Calls to the vetKD API from a canister on your engine fail with:
unknown threshold key: vetkd:Bls12_381_G2:key_1, existing keys: []
Why this happens
An engine is a dedicated subnet. vetKD requires a threshold key to be provisioned on the subnet that serves the request. Cloud engine subnets are created without any vetKD key, so there is no key_1 (or any vetKD key) to call against — existing keys: [] confirms the subnet has zero threshold keys. This is independent of node count: a higher-replication engine does not change it.
Workaround: relay via a proxy canister
Starting with our next release, cross-chain calls are supported. The recommended pattern:
- Deploy a small proxy canister on the fiduciary subnet
pzp6e, which holds a vetKD key. - Have your engine canisters send their vetKeys requests to that proxy.
- The proxy performs the vetKD call on
pzp6eand returns the result to your canister.
Your application logic stays on the engine; only the vetKeys operations are relayed.
Not supported yet
- Provisioning a vetKD key directly on an individual engine subnet.
- A native, no-relay vetKeys path on engines (longer-term solution still being decided).
FAQ
- Does a higher-replication engine enable vetKeys? No. The key isn't a function of node count; engine subnets aren't provisioned with one regardless of size.
- Which key name do I use? With the relay pattern, your calls target the key on
pzp6e, not a key on your engine.