Overview

​

Externally-Owned Accounts (EOAs)

Externally-Owned Accounts (EOAs) 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, 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

​

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
• Recovery Module
• ERC-4337 Module
• Passkey Module

​

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.