Two crypto wallets can look almost identical and still operate under very different trust models.
One may keep a private key on the user’s phone. Another may distribute signing across several MPC participants. A third may use a smart account with replaceable signers, spending limits, and recovery modules. The interface might show the same balance and the same Send button, but the systems underneath differ in who can authorize a transaction, recover access, change policies, or keep the wallet running during an outage.
Those are architecture decisions. They affect custody, security, portability, operating cost, and the user experience long after onboarding is complete.
This guide compares 4 common models:
It also explains how these models combine in production systems and what teams should check before choosing one.
If you need the fundamentals first, start with how crypto wallets work. For a classification of mobile, web, hardware, hot, cold, DeFi, and NFT wallets, see types of cryptocurrency wallets.
A production wallet usually contains at least five distinct layers.
The account layer defines what the blockchain recognizes as the source of authority.
An EOA is controlled through a valid signature for its address. A smart account uses code to decide whether an operation is valid. On Ethereum, an account and a wallet are not the same thing: the account exists onchain, while the wallet is the interface used to interact with it. The Ethereum account documentation distinguishes externally owned accounts from contract accounts on this basis.
This layer creates and protects the cryptographic material used to approve actions. It may use:
The signer model and the account model are separate choices. An MPC network can produce a signature for an EOA. The same MPC system can also act as a signer for a smart account.
Authentication establishes who is accessing the application. Authorization decides what that person or session may request.
A valid Google login, email OTP, or passkey does not automatically equal a valid blockchain signature. The login may only open an application session. A separate policy engine may then check the asset, amount, destination, contract, session limits, and approval requirements before a signing request is created.
This separation matters because a secure signer can still approve a malicious transaction if compromised frontend or backend code gives it the wrong data.
The application constructs the transaction, estimates fees, simulates the likely result, and presents the relevant details for approval. After signing, an RPC service, relayer, or bundler submits the request to the network.
Submission infrastructure does not necessarily have signing authority. A relayer can broadcast a signed transaction without being able to create one.
Recovery determines how control returns after a lost device, unavailable signer, or compromised credential. Operations cover monitoring, indexing, notifications, policy administration, incident response, and service replacement.
Recovery is part of the control model. A provider that cannot authorize routine transactions may still have significant authority if it can replace the user’s signer.
The layers can be represented as one transaction path:
Different wallet architectures change specific parts of this flow.
A local-key wallet puts most signing responsibility on the user’s device. MPC adds coordination between signing participants. Multisig requires several independent approvals. A smart account moves validation rules into onchain code and may add bundlers, paymasters, modules, or session keys.
UserThe visible interface can remain the same while these dependencies change underneath it.
The simplest model is an EOA controlled by one conventional private key. The wallet generates the key, derives the account address, and uses that key to sign transactions.
In a mobile or browser wallet, the key is normally encrypted at rest and unlocked inside the application when the user approves an action. Hardware-backed storage can reduce exposure where the device and operating system support it. A hardware wallet moves signing into a dedicated device and returns only the signature.
A local-key EOA has relatively few moving parts. Once the wallet can access its key and an RPC endpoint, it can sign and submit transactions without a policy server, signing coordinator, or smart-account service.
The account is also portable across compatible wallet applications when the user can export or restore the relevant seed or private key.
The key is a single point of authority. If an attacker obtains it, the blockchain cannot distinguish the attacker from the legitimate owner. If the key is lost and no valid backup exists, the account cannot replace it.
Recovery usually restores the same underlying secret through a seed phrase or backup. That keeps the model simple, but it places substantial responsibility on the user.
A local-key EOA also has limited native policy flexibility. Spending limits, contract allowlists, and step-up approval can be enforced in an application, but the EOA itself still accepts any valid signature from its key. If the key is compromised, offchain policy controls may no longer help.
This model fits straightforward self-custody, hardware-backed personal wallets, and systems where low infrastructure dependence matters more than configurable recovery or transaction policy.
Multiparty computation is a broad field of cryptography in which several participants compute a result without revealing their private inputs to one another. Wallet systems often use MPC together with a threshold signature scheme (TSS) so that a defined set of participants can jointly produce a blockchain-compatible signature.
A typical arrangement might place one share on a user device and another within provider infrastructure. A more complex institutional setup may distribute shares across operators, regions, hardware boundaries, or approval roles.
When the system uses distributed key generation and threshold signing, the participants can create signatures without assembling a conventional full private key in one location. This differs from basic secret sharing, where stored fragments may reconstruct the original secret before it is used.
Product descriptions do not always preserve that distinction. Teams evaluating an MPC wallet should trace the actual key ceremony and signing flow rather than rely on the label.
MPC removes a single signing key from the normal transaction path. Compromising one participant or share should not be sufficient when the threshold is configured and implemented correctly.
It can also support:
For an EOA, the network may see an ordinary signature even though several participants produced it. That makes MPC useful when a product needs distributed control without changing the account format.
MPC does not determine custody by itself.
Suppose a 2-of-3 system gives shares to the user, the wallet provider, and a recovery service. If the provider and recovery service can sign together, they may have unilateral practical control without the user. A system described as “user-controlled” therefore needs a complete threshold map, including routine signing, administrative combinations, and recovery.
Availability also becomes part of the design. A signer may be cryptographically safe but operationally unusable if the required coordinator, participant, authentication service, or policy engine is offline.
Teams should document:
MPC works well for institutional operations, embedded consumer experiences, and products that need policy-controlled signing across several chains. The trade-off is greater dependence on signing infrastructure and recovery procedures.
A multisig wallet requires approval from several independent keys. A 2-of-3 arrangement, for example, accepts an action when any two of three authorized signers approve it.
Unlike threshold signing, multisig participants generally retain complete independent keys. The account or blockchain logic verifies that the required signatures or approvals are present.
Implementation varies by network. Bitcoin can enforce multisignature rules through its scripting model. On EVM networks, multisig commonly uses a smart contract that records owners and the approval threshold.
Multisig makes shared authority explicit. It works well for treasury operations, protocol administration, partnerships, and organizations that need to show which roles approved an action.
Independent signers can also reduce dependence on one device or provider. A company might place one key with an operations lead, one with a finance lead, and one in protected recovery storage.
Every signer needs its own key-management process. Adding or removing a signer may require an onchain action, depending on the implementation. Approvals can also be slower when people work across time zones or when a hardware signer is held offline.
Multisig support is chain-specific. A configuration that works well on one network may not transfer cleanly to another. Smart-contract multisig also introduces contract, module, upgrade, and transaction-cost considerations.
| Dimension | MPC/TSS | Multisig |
|---|---|---|
| Signing material | Distributed shares | Independent complete keys |
| Threshold enforcement | Cryptographic signing protocol | Blockchain script or smart-contract rules |
| Onchain result | Often one standard signature | Several signatures or contract approvals |
| Chain support | Can cover several compatible signature schemes | Depends on network or contract support |
| Recovery | Share replacement or recovery quorum | Remaining signers or account recovery rules |
| Main operational dependency | MPC participants and coordinator | Independent signer availability |
Neither model is automatically better. MPC can provide a smoother cross-chain transaction flow. Multisig often provides clearer governance and onchain accountability.
A smart account uses onchain code to decide which actions are valid. The account can accept different signer types and apply rules that a conventional EOA cannot enforce on its own.
Those rules may cover:
On Ethereum, ERC-4337 implements account abstraction through a higher-layer flow. Users create UserOperation objects, bundlers package them into transactions, and an EntryPoint contract coordinates validation and execution. Paymasters can agree to cover network fees under defined conditions.
A “gasless” transaction still consumes network resources. The user simply does not pay the fee directly; a paymaster, application, or another party covers it.
EIP-7702 adds another path by allowing an EOA to delegate execution to code. This can bring batching, sponsorship, and programmable execution to an existing EOA address, but it also creates new security requirements around delegation, replay protection, initialization, and the code receiving that authority.
For a broader Ethereum-specific explanation, see Ethereum wallets, EOAs, and ERC-4337.
A smart account does not remove signing credentials. It changes what the account can verify.
One smart account may accept a passkey. Another may require two hardware signers. A third may treat an MPC-produced signature as one of several authorized credentials. The smart account defines the validation rules, while the signer layer supplies the proofs those rules accept.
Programmability makes recovery and policy enforcement more flexible, but the account code becomes part of the security boundary. Teams need to review:
A smart account can remain usable with a different bundler or paymaster if the implementation and ecosystem support replacement. A product that depends on one proprietary service may be far less portable in practice.
Smart accounts fit consumer applications, games, DeFi interfaces, agent-controlled accounts, and products that need programmable permissions. They require more onchain and operational analysis than a simple EOA.
The main architecture models are not mutually exclusive.
A wallet may use MPC to control an EOA. Another may use the same MPC signer behind a smart account. A passkey can authorize an MPC signing request without being the credential the blockchain ultimately verifies. A TEE can hold one MPC share. A hardware wallet can act as one owner of a smart-contract multisig.
A consumer wallet might use:
Calling that product an “MPC wallet” explains only part of the system.
This is why architecture reviews should map layers and authority paths before comparing vendors. The product name rarely tells you enough.
| Dimension | Local-key EOA | MPC/TSS | Multisig | Smart account |
| Signing authority | One conventional key | Threshold of distributed shares | Several independent keys | Rules defined by account code |
| Typical account | EOA | EOA or smart account | Native multisig or contract account | Smart contract or delegated account |
| Recovery | Restore the key or seed | Restore or replace a share | Use remaining signers or recovery rules | Replace signers through account logic |
| Policy enforcement | Mainly offchain | Offchain policy and signing quorum | Signer and threshold rules | Programmable onchain validation |
| Infrastructure dependence | Low | Medium to high | Medium | Medium to high |
| Chain portability | Broad where the signature scheme is supported | Often broad, depending on implementation | Chain-specific | Ecosystem- and implementation-specific |
| Main failure concern | Key theft or permanent loss | Participant, coordinator, or recovery failure | Signer coordination and governance | Contract, module, upgrade, or service failure |
| Typical fit | Direct self-custody | Consumer UX and institutional operations | Team and treasury control | Programmable consumer and application accounts |
The table is a starting point. A real assessment must include the specific implementation, signer combinations, recovery flow, administrative powers, and operational dependencies.
These concepts are often grouped together, but they describe different properties.
Recovery explains how control returns after a credential, device, or participant becomes unavailable.
Depending on the architecture, recovery may:
The recovery method can be more powerful than the normal signing flow. A wallet that requires user approval for every transaction may still give a provider or administrator the power to replace the user during recovery.
Custody follows actual control, not marketing terminology.
The practical test is whether the application, provider, administrator, or recovery operator can move assets or replace signing authority without the user. Answering it requires every routine, emergency, and recovery path.
For a deeper treatment, see the non-custodial wallet control model.
Portability describes whether users and product teams can leave the original implementation.
Key export may solve portability for a conventional EOA. It may not be enough for a smart account, where the user also needs a way to appoint a new signer or continue using the account without the original provider.
A portability review should cover:
A wallet can be non-custodial yet operationally dependent on one provider.
A generic list of wallet threats is useful, but an architecture review needs to identify which component can cause a loss in this particular system.
Start with transaction intent. Where is the destination, amount, contract call, or permission created? If compromised frontend code can replace that data before signing, protecting the key alone will not prevent a malicious transaction.
Then follow the request through each control point:
The strongest control in one layer cannot compensate for an unexamined path in another.
A local-key EOA concentrates risk around one credential. MPC distributes signing risk but adds participant and coordination boundaries. Multisig distributes authority while creating governance and signer-management requirements. Smart accounts enforce richer rules but add contract and module risk.
For phishing, supply-chain attacks, authentication controls, secure development, and operational mitigations, see the separate guide to crypto wallet security threats and best practices.
Architecture should follow the product’s authority and failure requirements. Starting with a fashionable technology usually produces a less useful discussion.
A consumer product often needs familiar authentication, simple recovery, low-friction transactions, and support for new devices.
MPC, smart accounts, and hybrid models can provide those features without asking every user to manage a seed phrase. The team still needs to decide who can complete recovery, which services are required for signing, and how users leave the provider.
An embedded product connects wallet access to an existing account and keeps blockchain actions inside the application.
The architecture review should separate authentication from signing and determine whether the host application, wallet provider, or recovery operator can replace user authority. Provider availability, transaction previews, policy limits, and infrastructure replacement deserve the same attention as the key-management method.
See embedded wallet architecture and integration for the complete product flow.
Shared funds usually need visible roles, separation of duties, and a clear process for changing approvers.
Multisig is often a natural fit because the authorization structure is explicit. A smart account may add role-specific permissions, spending policies, or automated execution. MPC may be appropriate where cross-chain support and operational privacy matter more than showing every signer onchain.
Institutions commonly need approval workflows, policy enforcement, audit logs, disaster recovery, and separation between operational and high-value assets.
MPC/TSS can support distributed signing across teams and infrastructure boundaries. Multisig or smart accounts may add onchain governance. Hardware or HSM-protected signers can anchor high-assurance recovery and administrative actions.
The architecture must be tested against insider risk, regional outages, lost approvers, policy misconfiguration, and provider failure.
A hardware-backed EOA keeps the design relatively simple and isolates the key from a general-purpose device. A multisig arrangement can reduce dependence on one device or backup.
Convenience should not dictate the recovery model. A recovery process that is easy to trigger can weaken the protection provided by an offline signer. See how hardware wallets isolate signing for a closer look at that model.
Before selecting an implementation or provider, document the following.
Wallet features are easy to demonstrate. Authority paths are harder to see.
Before deciding between EOA, MPC, multisig, or a smart account, map who can sign, who can recover, who can change policy, and which systems must remain available. Then test the design against device loss, compromised credentials, unavailable providers, and signer migration.
That work determines whether the wallet will remain controllable when normal assumptions fail.
ND Labs designs custom crypto wallet architectures for consumer applications, fintech products, Web3 platforms, and institutional workflows. The scope can include signer design, custody and recovery mapping, smart accounts, MPC integrations, transaction policy, multichain infrastructure, and operational controls.
