Choosing the right wallet infrastructure is critical for crypto applications. Whether you’re launching a DeFi app, trading platform, or consumer-facing crypto wallet, your decision impacts security, UX, and scalability.
The choice can be complex: Should you use standard private key signing or programmable wallets? Should you secure private keys through Multi-Party Computation (MPC), Trusted Execution Environments (TEEs), or rely entirely on blockchain-native paradigms like Account Abstraction (AA)? And how do you ensure your approach works seamlessly across chains?
While MPC, TEEs, and AA each play a role in wallet functionality, these technologies operate at different architectural layers that can be complementary rather than competitive. Understanding how these approaches intersect and differ can help developers choose the right combination for their specific needs.
In this post we'll break down these different wallet paradigms – MPC, TEEs, and AA – take a look at the technical tradeoffs, explain their implications for UX and security, and provide a framework for evaluating which approach is best for your use case.
Private Key Management and Transaction Signing
At the base of every wallet implementation are private keys, which control the funds associated with an account. Private keys are what sign transactions to approve the sending of tokens, granting permissions to smart contracts, and more.
MPC and TEEs are two different ways of storing and using these private keys, as opposed to the traditional methods of storing a seed phrase somewhere and signing transactions manually.
AA acts almost as a separate layer to this which we’ll explore later, and can sit on top of different private key management strategies.
Let’s first take a look at how MPC and TEEs work in more detail, and how they are used for private key management and transaction signing.
Multi-Party Computation (MPC)
MPC refers to splitting apart a private key into multiple pieces, which are distributed across different devices or trusted parties.
When a transaction needs to be signed, each party creates a partial signature which is constructed into a full signature to approve a transaction. The private key itself is never recombined in one place; the pieces stay entirely separate.
MPC is often combined with Threshold Signature Schemes (TSS) in order to simulate the effects of a multisig - for example, requiring 3 out of 5 partial signatures for a transaction to take place.
These properties make MPC popular for institutional-facing solutions, such as custodians and exchanges. Customer funds can be moved and accessed with a higher level of security without risking a complete failure due to a single compromised party.
MPC solutions do however come with a performance overhead, as requiring multiple parties to compute signatures or complex signing patterns can introduce significant latency and bandwidth issues.
Trusted Execution Environments (TEEs)
TEEs, on the other hand, don’t split apart a private key at all.
Instead, they ensure that any actions involving a private key (e.g. generation, or transaction signing) occurs inside of a completely isolated area of a computer processor, or a “Trusted Execution Environment” (not to be confused with Hardware Security Modules).
Code and data inside of a TEE are not exposed to the outside world and cannot be tampered with from outside of the TEE. Hardware-enforced isolation reduces a lot of attack vectors, though there are still vulnerabilities targeted at TEEs to be aware of, depending on the implementation used).
TEEs can run on hardware devices, such as android phones with Ledger’s BOLOS, and can also run in the cloud such as with AWS Nitro Enclaves — which is what we use at Turnkey.
Operations inside of TEEs aren't computed across multiple parties, typically making them much more performant than MPC solutions. This is crucial for developers building applications which require a tight feedback loop, such as purchasing tokens and submitting trades.
TEEs also improve the user experience. Take a look at Flashbots, for example, who are researching and utilizing TEEs to prevent frontrunning on Ethereum. Or wallet tooling like Dynamic, using TEEs and embedded wallets to improve onboarding. Better UX is better for everyone.
MPC vs TEEs
The major differences between MPC and TEEs are to do with performance.
MPC, by definition, introduces extra latency/bandwidth issues and computation into the mix. Operations inside of TEEs aren't computed across multiple parties, typically making them much more performant.
However, TEEs also come with the tradeoff of being able to decentralize key storage. MPC doesn’t have a single point of failure, whereas key storage in TEEs is more centralized (although hardware protected).
Both MPC and TEEs are offchain solutions, and can easily generate accounts for different networks.
It’s also worth noting that MPC and TEEs can both be used together - for example, a key could be split into shares, and each part could be stored in a TEE. Everything is a tradeoff, and whether the combination is worth it depends on the use case.
Here’s a comparison table for summary.
How does Account Abstraction (AA) work?
Account Abstraction (AA) can be tricky to define, but generally refers to what we call “programmable wallets”.
Traditional wallets are accounts most users have. You have a private key, typically in the format of a seed phrase, and you sign transactions with it. On Ethereum, these are referred to as Externally Owned Accounts (EOAs).
Account Abstraction, instead of being a traditional EOA, runs all user actions through a “Smart Account”, which is a smart contract which grants users more flexibility, and ideally security, than a standard EOA.
The Smart Account can implement a multisig functionality, or set up programmable actions to occur onchain.
AA is flexible and can typically be implemented with any kind of private key management and transaction signing strategy. Safe and Argent offer a more onchain-focused and programmable experience, or wallets can be built on top of MPC or TEEs to further security guarantees to the account and signing process.
AA is also mostly popular within the EVM ecosystem, and doesn’t apply as much to Bitcoin/Solana or other blockchains.
How AA fits in with MPC and TEEs
Let’s take a look at how the AA approach compares with MPC and TEEs.
Crypto wallets: One solution to rule them all?
As with most things in crypto, everything is about tradeoffs.
There isn't "one solution to rule them all", but rather different choices and tradeoffs based on the needs of the developer, organization, or users. There is also no rule which says that MPC, TEEs, and Account Abstraction can't be combined or used together.
Many MPC solutions have parties execute sensitive actions within a TEE, and as mentioned above, many AA solutions build on TEEs with embedded wallet infrastructure.
If you're building an exchange or custody, you may want to think about using MPC or combining MPC and TEEs. If you're building a trading app, MPC might be too slow and provide worse UX compared to TEEs and embedded wallets. If your application logic must happen completely onchain, you might lean towards certain AA solutions. It will often depend on the problem being solved at hand.
Wallet security at Turnkey
At Turnkey we use AWS Nitro Enclaves, a type of TEE, to run sensitive workloads related to crypto wallets. Private keys are never decrypted outside these enclaves, and only end users can authorize key usage with your credentials. We’ve also implemented stringent protocols to prevent individual engineers from altering enclave code, ensuring a secure end-to-end deployment process.
As a result, organizations can generate millions of custodial or non-custodial embedded wallets for users, with private keys that are generated, stored, and accessed within secure enclaves. This makes Turnkey-generated wallets highly performant and scalable, while ensuring a smooth UX and top-notch security for teams building trading platforms (Azura, Moonshot), payments tools (Mural Pay), and internal onchain tooling (Polymarket).
In addition, AA solutions like Alchemy and Dynamic have also built on top of our TEE and embedded wallet primitives to create developer-ready wallets-as-a-service (WaaS) tools. Using offchain solutions also makes multichain support a lot easier to implement, especially for teams who aren’t building on EVM.
Related articles
