> ## Documentation Index
> Fetch the complete documentation index at: https://docs.safefoundation.org/llms.txt
> Use this file to discover all available pages before exploring further.
# Overview
> How Safe Smart Accounts work
## Externally-Owned Accounts (EOAs)
[Externally-Owned Accounts (EOAs)](/more/glossary#externally-owned-account) are the traditional type of Ethereum account. They are controlled by a single private key, which is used to sign transactions and messages.
Anyone with access to this private key has **full control** over the account. As a result, EOAs have a **single point of failure**: if the private key is lost or compromised, the funds and permissions associated with the account are lost as well.
## Smart Accounts
The second type of Ethereum account is the [Smart Account](/more/glossary#smart-account), also referred to as a smart contract account.
Like EOAs, smart accounts:
* have a unique Ethereum address
* can receive funds
* can interact with other contracts
From the outside, smart accounts are indistinguishable from EOAs based on their address alone.
The key difference is **how transactions are authorized**.\
Smart accounts do not rely on a single private key. Instead, **on-chain smart contract logic** defines who can execute transactions, under which conditions, and how they are validated.
Because this logic is programmable, smart accounts can support advanced features such as:
* multi-signature authorization
* fine-grained access control
* transaction batching
* account recovery mechanisms
* custom execution rules
## EOAs vs. Smart Accounts
## Safe Smart Account
A **Safe Smart Account** is a smart account with **multi-signature security** at its core. It is designed to be both secure by default and highly extensible, making it suitable for managing funds and executing transactions across Ethereum and other EVM-compatible networks.
The long-term vision for Safe Smart Accounts is to serve as the **standard account abstraction layer** for smart contract–based wallets, making the benefits of Account Abstraction accessible to both users and developers.
### Design Principles
The architecture of Safe Smart Accounts follows two core principles:
#### Secure by default
Safe uses a multi-signature model where a configurable threshold of owners must approve a transaction before it can be executed. This provides strong security guarantees without requiring trust in additional components such as modules, guards, or fallback handlers.
#### Maximum flexibility
Safe supports:
* **Modules**, which enable alternative execution patterns beyond multi-signature
* **`delegatecall`**, allowing Safe to execute logic defined in external contracts
This design enables advanced workflows while keeping the core contract minimal and secure.
## Features
### High security
Safe’s **multi-signature** functionality allows you to define:
* a list of owner accounts
* a threshold number of approvals required to execute a transaction
Owners can be:
* EOAs
* other smart accounts
* passkeys or other authentication mechanisms
Once the required number of approvals is collected, the transaction can be executed on-chain.
### Advanced execution logic
Safe supports complex execution patterns through **Safe library contracts**.
A common example is **batched transactions**, where multiple Ethereum transactions are grouped and executed together. This allows users to approve a single transaction instead of signing many individual ones.
### Advanced access management
Safe can be extended using **Safe Modules**, which enable fine-grained access control.
Examples include:
* **Recovery modules** that restore access under predefined conditions
* **Allowance modules** that grant limited execution rights, such as daily spending limits for external accounts
Modules are optional and can be added or removed through owner confirmations.
### Token callback support
Many token standards require wallet contracts to implement callbacks.\
Safe supports token callbacks for standards such as:
* **ERC-721**
* **ERC-1155**
This allows Safe to react to incoming token transfers and, if necessary, reject them.
### Sponsored and token-paid transactions
Normally, Ethereum transactions require ETH to pay gas fees. Safe enables alternative payment models, including:
* paying gas fees with supported ERC-20 tokens
* fully gasless transactions where a third party sponsors the fees
This is implemented via transaction relay services that submit transactions on behalf of the Safe and handle gas payment in ETH.
## Architecture
### Safe Singleton Factory
The **Safe Singleton Factory** deploys Safe-related contracts and enables deterministic contract addresses across different networks.
This allows Safe Smart Accounts and their proxies to be deployed at the same address on multiple chains.
See also:
* [Safe Singleton Factory repository](https://github.com/safe-fndn/safe-singleton-factory)
### Safe Proxy Factory
The **Safe Proxy Factory** provides a convenient way to:
* deploy a Safe proxy
* point it to a Safe singleton
* execute the initial setup
All of this happens within a single transaction.
### Safe (Singleton)
The **Safe** contract is a singleton that contains the core logic for:
* signature verification
* transaction execution
* owner management
* module management
* fallback handling
* guards
The Safe singleton is **not used directly**. Instead, Safe accounts interact with it via proxy contracts using `delegatecall`.
There are two variants:
* **Safe** (mainnet and compatible chains)
* **SafeL2**, which emits additional events for L2 chains that do not support tracing
> For historical reasons, both variants are often referred to simply as “Safe”.
The diagram below shows the main components of the Safe contract:
### Owner Management
Safe supports multiple owners per account. The `OwnerManager.sol` contract enables:
* adding, removing, and replacing owners
* changing the approval threshold
* retrieving the current owner list
Events are emitted whenever owners or thresholds are updated.
### Module Management
Modules extend Safe functionality while keeping the core contract minimal.
They can, for example:
* allow transaction execution without collecting all signatures
* enable alternative authorization schemes
Adding or removing a module requires confirmation from the owner threshold. Because modules can bypass standard authorization logic, they are **security-critical** and must be carefully audited.
Examples:
* [Allowance Module](https://github.com/safe-fndn/safe-modules/s/tree/main/modules/allowances)
* [Recovery Module](https://github.com/safe-fndn/safe-modules/s/tree/main/modules/recovery)
* [ERC-4337 Module](https://github.com/safe-fndn/safe-modules/s/tree/main/modules/4337)
* [Passkey Module](https://github.com/safe-fndn/safe-modules/s/tree/main/modules/passkey)
### Executor
The Executor component contains the logic for executing `call` and `delegatecall` operations to external contracts.
### Fallback Manager
Fallback functions are executed when a function selector does not match any defined function.
Because EVM contracts are limited to 24 KB in size, Safe uses a **Fallback Manager** to:
* delegate fallback logic to a separate contract
* extend functionality without increasing the core contract size
### Guard Management
Guards define additional checks that run before and after transaction execution.
The Guard Manager allows guards to be added, removed, or replaced. Guards are security-critical: a faulty or malicious guard can block transactions or lock funds.
Events are emitted whenever a guard is updated.
### Safe Proxy
A **Safe Proxy** is a lightweight contract that delegates all calls to the Safe singleton.
Using proxies significantly reduces deployment costs, since the proxy’s bytecode is much smaller than the full Safe contract.
