> ## Documentation Index
> Fetch the complete documentation index at: https://docs.monad.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Wallet Infrastructure

## Summary

Monad features excellent support for developers looking to refine their users' experience
by utilizing modular wallet infrastructure.

These pages survey the supported infrastructure:

* [Embedded Wallets](/tooling-and-infra/wallet-infra/embedded-wallets)
* [Account Abstraction Providers](/tooling-and-infra/wallet-infra/account-abstraction)
* [Smart Account Implementations](/tooling-and-infra/wallet-infra/smart-accounts)

The landscape can be confusing, even to an experienced developer; therefore we include a
rough topology below.

## Background

Wallets allow users to store private keys and sign transactions. The basic setup involves
separation between the wallet and the application: the application presents a transaction
to the wallet for signing, and the wallet submits the transaction to the network, paying
for inclusion and execution with native tokens deducted from its balance.

However, increasingly, developers wish to customize their users' experience, for example by
sponsoring gas for their users or by allowing users to pay fees in an alternate currency. Other
developers want to embed the "wallet" into the app and give the app signing power over that
wallet, so that users don't have to sign a transaction with each action that they take.
Modular wallet infrastructure enables these and other features.

A number of providers are solving for this experience. To simplify understanding of the options,
we suggest the following two-dimensional matrix:

|                   | Freestanding                                                                                                                                                                                                                      | Embedded                                                                                                                                    |
| ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| **EOA**           | See [Simple Wallets](/tooling-and-infra/wallets)                                                                                                                                                                                  | See [Embedded Wallets](/tooling-and-infra/wallet-infra/embedded-wallets).<br />Typically utilizes key sharding, e.g. using MPC, SSS, or TEE |
| **Smart Account** | Utilizes Account Abstraction, i.e. developer needs to choose:<br /><ul><li>[AA Providers](/tooling-and-infra/wallet-infra/account-abstraction)</li><li>[Smart Accounts](/tooling-and-infra/wallet-infra/smart-accounts)</li></ul> | See [Embedded Wallets](/tooling-and-infra/wallet-infra/embedded-wallets) and look for "Embedded Smart Accounts"                             |

## EOA-based approach

**(EOA, freestanding)** is the traditional wallet experience powered by browser extension wallets,
mobile wallets, and hardware wallets. It involves a single private key stored within the wallet.
See [Wallets](/tooling-and-infra/wallets) for a survey.

**(EOA, embedded)**: typically uses cryptographic techniques (MPC, SSS, etc) to shard the
signing keys, implementing additional authorization or access control features off-chain, while
presenting to the blockchain as an ordinary EOA. See [Embedded Wallets](/tooling-and-infra/wallet-infra/embedded-wallets)
for a list of providers.

## Smart account (account abstraction) approach

Account Abstraction means using smart contracts in place of simple EOAs. The smart contract
implements the authorization / access control logic, i.e. the logic is on chain.

Historically, smart contracts could not pay for their own transaction costs (although EIP-7702
introduces an exception to this rule). Therefore, the account abstraction path requires
users to sign pseudo-transactions (UserOperations) and submit them to a custom mempool.
Then, a service called the Bundler/Relayer submits UserOperations in a normal Monad transaction
and pays for the execution.

Thus, there are at least two considerations for developers building with smart accounts:

* the Bundler/Relayer service; see [Account Abstraction Providers](/tooling-and-infra/wallet-infra/account-abstraction)
  for a list
* the [Smart Account Implementation](/tooling-and-infra/wallet-infra/smart-accounts)

Some embedded wallet providers support smart accounts. See [Embedded Wallets](/tooling-and-infra/wallet-infra/embedded-wallets)
and look out for "Embedded Smart Accounts".