Wallet infrastructure
Lit Protocol vs Fireblocks
Control the permission to sign.
Look beyond the key shares. Compare who controls signing policy, approves software, and can withhold a signature.
Scope: Lit Chipotle in ChainSecured mode and Fireblocks Vault infrastructure. Fireblocks deployments and recovery arrangements vary.
Operator authority
Three questions about operator authority.
| Control | Lit · ChainSecured | Fireblocks |
|---|---|---|
| Who can change the permissions? | Your account wallet approves permission changes on Base. A usage API key can run authorized Actions but cannot change those permissions.[5][6] | Workspace policy and approval roles govern transactions alongside the signing threshold. Assess who administers those roles and co-signers, not just how many key shares exist.[4] |
| Who can approve replacement code? | The approvers authorized by the governance contracts can approve runtime releases. The key-management system checks on-chain approval and hardware attestation before releasing keys. Deploying new code is not enough.[7][8] | Software control depends on the deployed Fireblocks components and co-signers. The cited overview does not identify every authority that can approve replacement code; verify that authority for your deployment.[4] |
| Who can stop access? | The API operator or runtime host can interrupt normal signing. On-chain permissions remain inspectable, but execution still needs the runtime and key-management system. Recovery requires a separate plan.[3][7] | Normal signing needs enough participating shares. Fireblocks documents recovery for lost signing devices or suspended operations. Confirm the required backups and recovery materials are in place.[9] |
Who can change the permissions?
- Lit · ChainSecured
- Your account wallet approves permission changes on Base. A usage API key can run authorized Actions but cannot change those permissions.[5][6]
- Fireblocks
- Workspace policy and approval roles govern transactions alongside the signing threshold. Assess who administers those roles and co-signers, not just how many key shares exist.[4]
Who can approve replacement code?
- Lit · ChainSecured
- The approvers authorized by the governance contracts can approve runtime releases. The key-management system checks on-chain approval and hardware attestation before releasing keys. Deploying new code is not enough.[7][8]
- Fireblocks
- Software control depends on the deployed Fireblocks components and co-signers. The cited overview does not identify every authority that can approve replacement code; verify that authority for your deployment.[4]
Who can stop access?
- Lit · ChainSecured
- The API operator or runtime host can interrupt normal signing. On-chain permissions remain inspectable, but execution still needs the runtime and key-management system. Recovery requires a separate plan.[3][7]
- Fireblocks
- Normal signing needs enough participating shares. Fireblocks documents recovery for lost signing devices or suspended operations. Confirm the required backups and recovery materials are in place.[9]
The Lit advantage
Your on-chain rules govern signing
Use Lit to power hot wallets and vaults with signing rules expressed as code and governed on-chain. A permitted Action can evaluate external information before using a wallet. Authority follows the account’s contract permissions, rather than participation in an MPC signing threshold.[1][2][3]
How ChainSecured worksWhat custody means in practice
A party can lack enough shares to steal funds yet still be necessary for everyday access. Fireblocks’ documented recovery path matters here. Lit records on-chain which signing code your account authorizes. That does not by itself give it a stronger recovery path without a provider.[9][6]
Shared protections
Both combine key protection with transaction authorization. Fireblocks uses MPC and hardware-protected components. Chipotle uses keys inside an attested runtime; it is not an MPC wallet network.[4][3]
Sources and review scope
These comparisons use published documentation and the source code linked below. We have not audited or tested the providers’ live systems. Configurations vary, and source code alone does not establish who currently owns a deployed contract or how it is configured.
- Lit: Action runtime and code-bound permissions
- Lit: Groups and action permissions
- Lit: Architecture
- Fireblocks: Architecture and security layers
- Chipotle: account mutation authorization (reviewed source)
- Lit: Chain Secured
- Lit: On-Chain KMS
- Lit: Upgrade governance
- Fireblocks: Backup and disaster recovery
- Chipotle: contract owner upgrade authority (reviewed source)
- Lit: verification and contract administration