Smart custody vs. MPC
Both promise self-custody. Only one keeps enforcing when the vendor disappears, when the dashboard is tampered with, and when the signer is asked to sign the wrong message.
Smart custody
Smart custody is custody where the account itself enforces the rules. The signing scope, the spending limits, the allowlists, the role hierarchy — all of it lives in smart contracts on the chain the assets sit on. Every transaction is checked against those rules before any state changes.
The contrast is with key-centric custody — MPC, TEE, HSM, or any architecture that builds security around protecting the key. Key-centric custody puts the policy engine on a vendor’s server; smart custody puts it in the smart account.
Smart-contract accounts
Safe and ERC-4337 accounts as the substrate — battle-tested, open, and chain-native.
Onchain policy modules
Roles, allowances, multi-step routing, timelocks, recovery — composable extensions on top of the account.
Verifiable by anyone
The rule is bytecode on a public chain. Auditors, LPs, and token holders read it directly.
No vendor in the trust path
The chain enforces. We can disappear and the account keeps refusing what it was told to refuse.
Securing the key isn’t
securing the transaction.
Custody answers two separate questions: who is allowed to sign, and what they’re allowed to authorize. Key-centric custody — MPC, TEE, HSM — is built around the first. None of it answers the second.
Who can sign. MPC splits a private key across parties so no single party ever holds it whole; a multisig smart account keeps the same m-of-n guarantee as immutable bytecode on the chain the assets sit on. And because the account signs with ordinary keys, each signer can sit behind a hardware wallet or HSM — protection that stacks on top, where MPC’s custom threshold protocol can’t slot those in. Both are good answers to “don’t let one machine hold the key.” Neither one inspects the transaction: a compromised dashboard or RPC layer hands the signer a malicious payload, the signing rule clears, and the signature is valid. The keys were never the problem.
What they can authorize. Closing that gap takes a policy engine — allowlists, limits, approval rules. Every serious vendor ships one; the only question that matters is where it runs. Vendor engines run on the vendor’s own centrally hosted infrastructure — the same class of system that was tampered with to stage Bybit. Compromise the service, or the interface feeding it, and the policy falls with it. It’s a second lock on the same door.
Smart custody moves the check to the chain. The smart account evaluates the transaction’s destination, function, parameters, and conditions against an onchain policy before it can land. No off-chain coordinator, no enclave attestation, no compromised host can bypass that check. Define what’s allowed, not who signs — and enforce it where it can’t be bypassed.
On the dimensions you’re actually evaluating
MPC has a real advantage on non-EVM coverage today. For EVM-native institutional operations — where the vast majority of onchain value sits — smart custody is structurally stronger.
The operator can be compromised.
The bound cannot.
Built on Safe. Enforced by the chain. No vendor in the trust path.