Skip to main content
Every TVC app is controlled by two groups of operators. They have the same shape in the API, and their members can even overlap, but they answer two different questions:
  • The manifest set is the set of operators authorized to approve QOS manifests. It answers: what code and configuration is allowed to run?
  • The share set is the set of operators authorized to provision Quorum Key shares to an enclave during boot. It answers: which enclaves are allowed to receive the Quorum Key?

Operator sets

Both sets are instances of the same building block, an operator set:
  • A name, so you can identify the set on the dashboard.
  • A list of operators, up to 50 per set. Each operator has a name and public keys for signing and encryption. tvc login generates a local operator key for you; tvc operator create creates a Turnkey-hosted operator instead.
  • A threshold: the number of operators whose signatures are required before the set’s authority takes effect. The threshold can’t exceed the number of members.
You define both sets when creating an app, via manifestSetParams and shareSetParams on the create_tvc_app activity. If you already have an operator set from a previous app, reuse it by passing its ID (manifestSetId or shareSetId) instead. TVC also deduplicates automatically: defining a set with the exact same name, threshold, and members as an existing one reuses the existing set. The manifest set ID and its operator IDs are printed when you create an app:
The share set ID is not part of this output. To find both the manifest set and the share set, along with their IDs and each operator’s ID, open the app’s page in the dashboard. The same person can be an operator in both sets. Whether they should be depends on your security model; see Choosing your sets below.

The manifest set: who approves what runs

Every TVC deployment is specified by a QOS manifest: the container image, expected binary digest, executable arguments, ports, the operator sets themselves, and everything else QOS uses to boot your application. Nothing is deployed onto TVC infrastructure until the manifest is cryptographically approved by a threshold of manifest set members. When you create a deployment, TVC generates the manifest and the deployment shows as Approval Required on the dashboard. Each manifest set member reviews and signs the manifest with their operator key via the TVC CLI:
The CLI walks the operator through the manifest section by section: the namespace and Quorum Key, the enclave PCR measurements, the pivot binary digest and arguments, and the membership and thresholds of both operator sets. The signature is posted via the create_tvc_manifest_approvals activity. Once approvals from distinct operators reach the manifest set’s threshold, TVC infrastructure proceeds with the deployment (and, if the app has no live deployment yet, promotes it to live). Below the threshold, nothing runs: a single compromised or careless operator cannot ship code on their own if your threshold is at least 2. This threshold is enforced by QuorumOS, the software the enclave itself runs, not by TVC infrastructure. An enclave refuses to boot a manifest unless it carries a threshold of valid manifest set signatures, so the guarantee holds even if the surrounding infrastructure is compromised. Approvals are recorded in the manifest envelope, so they travel with the deployment as an audit trail. Anyone verifying your app can see exactly which operators approved the manifest as part of its Boot Proof. The manifest set acts on every new deployment. Upgrading your app to a new image, changing its arguments, or modifying its configuration all produce a new manifest that must be approved again.

The share set: who guards the Quorum Key

Your app’s Quorum Key is its long-lived identity: it is the same across all enclaves and across deployments, and it can encrypt or sign state that must survive application upgrades. That durability is exactly why it needs stronger custody than any single machine or person can provide. The Quorum Key is never stored whole. It is split into shares using Shamir’s Secret Sharing, each share is encrypted to one share set member’s key, and reassembly requires the share set’s threshold to be met. By design this only ever happens inside an enclave. Share set thresholds must be at least 2.
To create a custom Quorum Key with hosted operators, follow the worked example below.

Side by side

How they fit together

The two sets act at different points in a deployment’s life. The manifest set gates the boot; the share set gates the key injection that follows it. Note the chain of trust between the two sets: share set members only release their shares to an enclave whose attestation proves it booted from a manifest the manifest set approved. The manifest set’s review is what makes the share set’s verification meaningful.

Worked example

Acme runs a price oracle on TVC. The oracle derives its signing identity from the app’s Quorum Key, so key custody matters. Acme sets up:
  • Manifest set "Acme Deploy Reviewers": three platform engineers (Alice, Bob, Carol), threshold 2. Any production deployment needs two engineers to independently review the manifest.
  • Share set "Acme Key Custodians": three members of the security team (Dana, Erin, Frank), threshold 2. No single custodian can reconstruct the oracle’s signing key.
Acme uses hosted operators. Turnkey performs hosted key generation, signing, and share re-encryption inside its enclaves without returning private keys or plaintext shares to the CLI.

Create the operators and Quorum Key

Log in, then keep the same organization and local profile active throughout setup. Create Alice’s hosted operator:
Repeat for Bob, Carol, Dana, Erin, and Frank, using their names. Retain each returned Operator ID; the CLI saves the operators’ IDs and public-key metadata locally. You can also use an existing wallet with --wallet-id and specify a derivation path with --account-path. Run tvc operator create --help for the available options. Create the Quorum Key with a share encrypted to each custodian’s operator:
Use the returned Quorum Public Key as <ACME_QUORUM_PUBLIC_KEY> below.

Create the app

Save this configuration as app.json, replacing the placeholders with the public key and operator IDs from setup:
The share set’s operators and threshold must match those used to create the Quorum Key. Set them explicitly: omitting the share set selects the CLI’s development share set. The manifest set’s membership and threshold are independent. See create_tvc_app for all configuration fields.

Shipping the first deployment

  1. An Acme engineer follows the quickstart’s deployment creation steps, using the returned App ID for appId. TVC generates the QOS manifest and the deployment sits at Approval Required. Use the returned Deployment ID in the commands below.
  2. Alice and Bob each run tvc deploy approve with their operator ID, review the manifest, and sign it. Carol is on vacation; with a 2-of-3 threshold, that’s fine. The threshold is met and TVC boots the enclaves.
  3. Wait for an enclave to produce an attestation document. Check that verified provisioning details are available before provisioning shares:
  4. Dana and Erin provision their shares through Turnkey:
    Each command verifies the attestation and manifest approvals, then requests re-encryption of that operator’s share to the enclave’s Ephemeral Key. At 2 shares, the enclave reconstructs the Quorum Key and launches the oracle.
  5. Check deployment readiness:
    Once all desired replicas are ready, the oracle is live at https://app-<APP_UUID>.turnkey.cloud, signing responses with keys derived from the Quorum Key.

Shipping an upgrade

Acme releases v2 of the oracle. The new image produces a new manifest, so two of Alice, Bob, and Carol review and approve it. Once the replacement deployment is ready, Acme can direct traffic to it. The Quorum Key itself stays the same across deployments, which is the point: state encrypted by v1 remains readable by v2, and consumers see a continuous signing identity.

What the thresholds bought Acme

  • Alice’s laptop is compromised. The attacker can sign manifests as Alice, but cannot reach the 2-approval threshold alone: no unauthorized code ships.
  • Frank’s Quorum Key share leaks. One share reveals nothing about the key, and an attacker cannot get a second share released to anything but a verified enclave running manifest-set-approved code.

Choosing your sets

  • Manifest set membership should mirror who reviews production changes today. Treat a manifest approval like a code review with teeth: members are expected to actually inspect the image digest, arguments, and configuration they sign.
  • Share set membership is key custody. Prefer people (or systems) with strong operational security. The role is distinct from the manifest set: approving a manifest authorizes what code runs, while holding a share governs whether the Quorum Key can be reconstructed for a verified enclave.
  • Thresholds: share set thresholds must be at least 2, and for production a threshold of at least 2 on the manifest set too means no single actor can ship code or expose the key. Keep thresholds comfortably below the member count so vacations and lost keys don’t halt deployments.
  • Reuse: operator sets can be shared across apps by passing manifestSetId / shareSetId at app creation, so a platform team can maintain one reviewed set of operators for many apps.
  • Demos and prototypes: the quickstart flow, with a 1-of-1 manifest set (just your login key) and the well-known development quorum key, is the fastest way to a running app. Graduate to real sets before handling anything sensitive.

See also