Safe vs MPC wallets: which model fits your treasury?
Understand how Safe smart accounts and MPC wallets differ, what they can share, and which governance questions to ask before choosing.
· 7 min read
On this page
The short answer
Safe and MPC are not two brands of the same product. Safe is an account: a smart contract on the chain that holds the funds and enforces its own rules, starting with a threshold of owner signatures. MPC is a signing technique: a private key is split into shares held by different parties, who cooperate to produce an ordinary signature without ever assembling the key. When an MPC key directly controls an address, the blockchain sees an ordinary externally owned account, and every rule about who may sign is enforced by the provider's software, usually inside a secure enclave. The same MPC key can also be an owner of a smart account, which is why the two are layers rather than rivals.
That difference in where the rules live drives everything else: what you can verify, which chains you can use, how you automate, how you recover, and what breaks when something goes wrong.
| Choose | When |
|---|---|
| A Safe account | You operate on EVM networks, you want rules anyone can verify onchain without trusting a vendor, and your team is prepared to assemble the operating model from Safe's core threshold, its optional extensions, and its managed tooling |
| An MPC platform | You need non-EVM chains such as Bitcoin, Solana, or Cosmos, you want a vendor-run console and policy engine, or exchange connectivity matters more than onchain verifiability |
| A policy-enforcing smart account such as Den | You want rules richer than a signature threshold enforced onchain as part of the account, plus a managed approval workflow, and EVM coverage is sufficient |
Den publishes this blog and builds the third option. We try to be fair to the first two.
What a Safe actually is
Safe's smart account documentation describes a contract with multi-signature functionality at its core. Owners can be externally owned accounts, other contracts, or passkeys, and a threshold sets how many must confirm a transaction. Each Safe is a lightweight proxy that delegates to a shared singleton implementation, which keeps deployment cheap. Three extension points change the account's behaviour. Modules can execute transactions without owner confirmations, which is how spending allowances, recurring payments, and social recovery are implemented. A transaction guard checks owner-signed Safe transactions before and after execution, and a separate module guard checks transactions initiated by modules where the deployed contract version supports it. Fallback handlers add functions the core contract does not have.
On top of the contracts, Safe Wallet layers optional tooling. Spending limits use the Allowance module. Safe Shield adds human-readable previews and risk insights to signing, and its optional Guardian by Hypernative installs a transaction guard that Safe describes as approving low-risk transactions, flagging suspicious ones, and blocking high-risk ones, with policies for transfer limits and approved counterparties. Safe's teams page describes owner, admin, and contributor roles, proposers, and spending limits for team members.
The important property is that the account's core state is public. Anyone can read the owners, the threshold, the enabled modules, and the guard address from the chain. There is no vendor between you and the account, and the account keeps working if every company involved disappears. The optional tooling is a different matter: a managed guard or a Workspace role is a service relationship with its own trust and availability.
What an MPC wallet actually is
In a threshold-MPC wallet the private key never exists in one place. Fireblocks direct custody uses a 3-of-3 scheme with shares across its cloud and your device or API co-signer. Fordefi splits each key into two shares, one on your device or API Signer and one in an AWS Nitro enclave it operates. Utila states that control of the key is divided between the customer and Utila. The signature that comes out is a standard one, so when the key controls an address directly the chain sees an ordinary account.
Two providers often grouped with MPC use different cryptography and belong in the same comparison for a different reason. Turnkey keeps whole keys inside AWS Nitro enclaves and never splits them. Privy uses Shamir secret sharing and reconstructs the key inside a Nitro enclave for each signature. Neither is threshold MPC. What they share with MPC platforms is the property that matters here: the chain cannot see any rules, so the provider's infrastructure enforces them. Fireblocks says its policy engine runs inside Intel SGX enclaves and that rules are signed by an admin quorum. Turnkey and Privy evaluate policies inside their enclaves. Enclaves are a real security boundary. They are also a trust decision: you are relying on the vendor's code, the vendor's operations, and the hardware vendor's attestation.
The consequences, side by side
The right-hand column below covers vendor-enforced wallets generally. The cryptography differs between threshold MPC, enclave-held keys, and Shamir reconstruction, but the operational consequences are largely the same.
| Dimension | Safe account | Vendor-enforced wallet (MPC or enclave) |
|---|---|---|
| Where rules are enforced | In the account contract onchain, plus any guard or module you enable | In the provider's servers or enclaves |
| What you can verify | Owners, threshold, modules, and guard are public state | Vendor audits, and for some enclave providers attestation proofs such as Turnkey Verified |
| Chain coverage | EVM networks where the contracts are deployed, currently hundreds | Any chain the vendor supports, including Bitcoin, Solana, and Cosmos |
| One key, many chains | Each network needs its own account deployment | One key can sign on every chain that uses the same curve |
| Rule richness | Threshold in the core contract, richer rules through the Allowance module, Safe Shield's optional guard, or modules and guards you choose | Vendor policy engine with amounts, allowlists, time windows, and contract-call conditions |
| Automation | Modules such as the Allowance module, or a delegated key with a spending limit | Vendor co-signer or API signer holding a key share or an API key |
| Recovery | Recovery modules with a review delay, or simply keeping enough owners | Vendor-documented key backup and export procedures |
| Privacy | Multisig configuration is visible to anyone | Looks like a normal address when the key controls it directly |
| Cost | Deployment gas plus contract overhead on each execution | Ordinary transaction cost |
| Characteristic failure modes | A malicious module, a broken guard, or a compromised signing interface | Vendor outage or compromise, lost backup shares, weak policy configuration |
Where the rules live decides what breaks
The 2025 Bybit theft is the clearest lesson on the Safe side. The Safe Ecosystem Foundation's statement reports that the attack was achieved through a compromised Safe Wallet developer machine that resulted in the proposal of a disguised malicious transaction, and that the review found no vulnerabilities in the Safe smart contracts or in the source code of the frontend and services. The contract did exactly what it was built to do: it executed a transaction that the required number of owners had signed. The rule enforced onchain was the threshold, and the threshold was met.
Safe itself now says this out loud. Its Dappcon 2026 talk, summarized on the Safe blog, is titled "why approval isn't enough anymore" and lays out plans for policies, timelocks, and spend limits on top of the multisig. Today, rules richer than the threshold come from extensions rather than the core contract: the Allowance module, Safe Shield's optional Guardian by Hypernative guard, Workspace roles and spending policies in Safe Wallet, or guards and modules you deploy. Each carries its own trust. Safe warns that a malicious module can take over a Safe and that a broken guard can cause a denial of service, and a managed guard is a service you depend on.
On the vendor-enforced side the failure mode is different. The rules can be rich, but they live with the vendor. If the vendor's policy service is bypassed, misconfigured, or compromised, nothing on the chain notices. Fireblocks' answer is enclave enforcement and an admin quorum on rule changes. Fordefi's answer is the same plus simulation in review. Both are sound engineering. Neither gives you a rule you can independently verify by reading the chain.
They can be combined
The two models are layers, and teams combine them more often than vendor marketing suggests.
An MPC-held key produces an ordinary signature, so it can be a Safe owner. A treasury might use hardware wallets and an MPC platform's keys as owners of the same Safe, gaining vendor-managed signing on one side and public threshold enforcement on the other. Safe modules can hand a delegated key a spending allowance, which is how Safe's own agent quickstart gives an automated signer a daily budget without making it an owner.
Den's architecture is another combination. Den accounts are smart contracts with a policy engine that runs onchain, so the rules about recipients, amounts, functions, and approval thresholds are enforced by the contract, not only by a server. The same policy is also checked by the signing client and by Den's Guardian service before anything is submitted. And under the hood, the Guardian and the admin authority are themselves implemented as Safe multisigs, as the open-source contracts document. We use Safe where it is the right tool and build the policy layer into the account rather than adding it as an extension.
Questions that separate the options
- Do you need non-EVM chains? If yes, Safe is out for those assets and an MPC platform or a mix is required. Den is also EVM-only.
- Who must be able to verify the rules? If auditors, counterparties, or your own security team want to check controls without trusting a vendor, onchain enforcement wins. Remember that a managed guard on a Safe is verifiable as an address, but the logic behind it is the provider's.
- Who maintains the operating model? A Safe with extensions is a system you assemble, from Safe's managed options or your own modules and guards. An MPC platform is a service you configure. Den is a service whose enforcement you can also read onchain.
- What is the recovery story? A Safe recovers by keeping enough owners or by a recovery module with a review window, as in Safe's RecoveryHub. MPC vendors document backup procedures such as Fordefi's five backup methods. Den documents two timelocked recovery paths. Test whichever one you choose before you need it.
- What happens when the interface lies? Ask how each option protects a signer who is shown one transaction and asked to sign another. Onchain rules that constrain destination and function help. Decoded review on an independent device helps. A threshold alone does not.
For a deeper look at the Safe side, read our Safe wallet review. For the practical steps if you decide to move, see how to plan a migration from Safe to a policy-based wallet. For the MPC vendors themselves, start with Fireblocks alternatives.
