All comparisons

Wallet infrastructure

Lit Protocol vs Turnkey

Write your signing policy in code and govern permissions on-chain.

Compare how verified wallet infrastructure connects custom policy, customer authority, and release approval.

By Lit Protocol · Sources reviewed September 15, 2026

Scope: Turnkey enclave wallet infrastructure and Lit in ChainSecured mode.

Lit assessment

Why choose Lit

Lit brings custom signing logic and customer-owned, on-chain permissions into one execution model. Read an API or chain state inside a Lit Action, then sign only when your conditions hold. Choose Lit when counterparties need to verify which code is authorized for a wallet from shared contract state.[1][2][3]

Tradeoffs to weigh

Turnkey provides hardware-backed verification and publishes release manifests and approvals. Its Verifiable Cloud also supports custom workloads. Its service-initialization shares are distinct from per-wallet MPC signing shares. Lit’s published hosted configuration also entrusts runtime approvals to a Lit-controlled 2-of-4 Safe without a timelock. Public approval records make that authority inspectable; they do not make either system immune to a compromised release quorum.[4][5][6]

Architecture, side by side

Architecture of Turnkey compared with Lit Protocol in ChainSecured mode
DimensionTurnkeyLit (ChainSecured mode)
Runtime verificationAs documented in September 2026, Turnkey Verified exposes Boot Proofs for enclave software and App Proofs for supported operations, including policy outcomes.[7]Attestation lets a verifier compare the running environment’s measurements with expected software and on-chain approvals.[8]
Runtime authorizationQuorumOS operators verify enclave measurements and provision shares of a service secret. Initial provisioning requires a share threshold; approved enclaves can also receive the secret through key forwarding.[9][10]Smart-contract whitelists govern which measured deployments receive runtime keys. The hosted approval authority is documented as a Lit-controlled 2-of-4 Safe without a timelock.[11][6]
Wallet permissionsThe enclave policy engine evaluates organization policies; policy-outcome proofs can verify those decisions.[7]Customer-owned contract state associates usage credentials, wallets, and immutable action identifiers. Permission changes are on-chain transactions.[3][2]

Runtime verification

Turnkey
As documented in September 2026, Turnkey Verified exposes Boot Proofs for enclave software and App Proofs for supported operations, including policy outcomes.[7]
Lit (ChainSecured mode)
Attestation lets a verifier compare the running environment’s measurements with expected software and on-chain approvals.[8]

Runtime authorization

Turnkey
QuorumOS operators verify enclave measurements and provision shares of a service secret. Initial provisioning requires a share threshold; approved enclaves can also receive the secret through key forwarding.[9][10]
Lit (ChainSecured mode)
Smart-contract whitelists govern which measured deployments receive runtime keys. The hosted approval authority is documented as a Lit-controlled 2-of-4 Safe without a timelock.[11][6]

Wallet permissions

Turnkey
The enclave policy engine evaluates organization policies; policy-outcome proofs can verify those decisions.[7]
Lit (ChainSecured mode)
Customer-owned contract state associates usage credentials, wallets, and immutable action identifiers. Permission changes are on-chain transactions.[3][2]

Security analysis

What the guarantees depend on

Turnkey has substantive cryptographic protections. Those protections do not remove trust in release authorities or make every integration’s “verified” result a code-identity check. The evidence below identifies concrete boundaries; it does not establish a live compromise.

Basic verification does not establish trusted code identity

Confirmed in SDK source

The reviewed TypeScript verify() checks signatures and proof linkage, but does not check expected enclave measurements or a trusted manifest. Its own warning says another AWS account’s enclave can pass. verifyWithQosPolicy() adds measurement and manifest allowlists. An integration using only the basic helper has a narrower guarantee; this is not evidence that Turnkey’s production signing authorization can be bypassed.[12]

Release approval and secret sharing have different thresholds

Published configuration + architectural inference

The published 2026.9.0 signer manifest specifies 2-of-11 manifest approvers and 3-of-10 secret-share holders. These are separate controls, not a single wallet-signing quorum. Key forwarding validates release approvals and an attested destination instead of collecting fresh operator shares. Consequently, assess compromise of the release-approval threshold together with access to the permitted AWS environment; counting secret shares alone overstates the upgrade barrier.[5][13]

Revoking approvers requires retiring old enclaves

Documented failure condition

QuorumOS explicitly records a rotation hazard: an old enclave still trusting compromised manifest approvers can provision another enclave they approve. Forwarding also enforces namespace, version, attestation, and AWS-role checks. The missing guarantee is automatic fleet-wide revocation: containment depends on retiring old instances. We have not established that this condition exists in Turnkey’s live deployment.[10][13]

Fresh state needs more than a valid signature

Unresolved production parameter

The whitepaper describes timestamped notarizations and Merkle proofs to reject stale organization data. It does not specify the production freshness window there. To establish revocation speed, request that bound and evidence that previously valid state cannot authorize a request after a credential or policy change. The published design alone does not establish immediate revocation or prove an exploitable rollback.[14]

A proof must be tied to the decision being relied on

Integration responsibility

An App Proof attests to a typed claim from measured code. The consuming application must check its meaning: the intended organization, request, state, and result. It must also choose trusted measurements independently. A valid proof is not proof that every operation was disclosed, that the code is correct, or that an operator-approved upgrade was acceptable to the customer.[15]

Provider recovery and customer exit are different

Documented dependency

Turnkey documents replicated data and offline backups for its service secrets. Its export design involves the Signer enclave. Those are useful mechanisms, but the cited recovery page does not establish a customer-operated exit during a prolonged provider outage. Confirm an independently usable recovery arrangement if provider-independent availability is required.[16][14]

Read-only review of public documentation, pinned SDK and QuorumOS source, and a published signer manifest. We did not audit the full signing application, reproduce production binaries, or test the live service. The manifest’s patch-set mechanism was not analyzed. Source snapshots and a release manifest do not establish what every production instance runs.

Primary sources

  1. Lit: Action runtime and code-bound permissions
  2. Lit: Chain Secured
  3. Lit: Groups and action permissions
  4. Turnkey Verifiable Cloud: Building custom applications
  5. Turnkey published signer manifest: release 2026.9.0
  6. Lit: Upgrade governance
  7. Turnkey Verified
  8. Lit: What is attestation?
  9. Turnkey: Quorum deployments
  10. QuorumOS: key-forwarding design and revocation caveat
  11. Lit: On-Chain KMS
  12. Turnkey TypeScript verifier: reviewed source snapshot
  13. QuorumOS key-forwarding validation: reviewed source snapshot
  14. Turnkey whitepaper: authorization, state freshness, and signing
  15. Turnkey: Proofs and independent verification
  16. Turnkey: Disaster recovery