Skip to main content

​
Owners

Each Safe Smart Account stores a list of owners on-chain as Ethereum addresses. Owners collectively control the account: they can approve transactions and update the Safe’s configuration. Adding or removing an owner requires a valid Safe transaction approved by the current owners (according to the threshold).

​
Threshold

A Safe also stores a threshold: the minimum number of owner approvals required to execute a transaction. Owners can update the threshold through a Safe transaction. The threshold must be between 1 and the total number of owners.

​
Signature verification

Because a Safe is a smart contract, it does not have a private key. The EVM therefore cannot “authenticate” a Safe transaction the way it does for EOAs. Instead, the Safe contract performs authentication and authorization in its own code. When a transaction is submitted to a Safe, the Safe:
  1. Computes the transaction hash from the submitted parameters.
  2. Verifies that each signer is a current owner.
  3. Validates each signature according to its type (for example EOAs, contract signatures, or other supported schemes).
  4. Checks that the number of valid approvals meets the threshold.
  5. Executes the transaction if the checks pass; otherwise, the call reverts.
To learn about supported signature types and encoding, see Signatures.

​
Transaction flow

Safe executes transactions through two main paths: Safe transactions (approved by owners) and module transactions (initiated by enabled modules).

​
Safe transaction

Safe Smart Account exposes execTransaction to execute a transaction that has been approved by the owners. To execute a Safe transaction, call execTransaction with:
  • to: Recipient address.
  • value: Amount of ETH to send (in wei).
  • data: Calldata, typically a function call on to.
  • operation: Execution type: CALL or DELEGATECALL.
  • safeTxGas: Gas allocated to the Safe transaction execution.
  • baseGas: Gas overhead for tasks such as signature checks and refunds. safeTxGas + baseGas is comparable to the gas limit of a regular transaction.
  • gasPrice: Gas price used for refunds. If set to 0, no refund is paid.
  • gasToken: Token used to pay the refund. Use 0x0 for ETH; otherwise an ERC-20 token address. Refund cost is calculated as (baseGas + safeTxGas) * gasPrice.
  • refundReceiver: Address that receives the refund. If set to 0, tx.origin is used.
  • signatures: Hex-encoded owner signatures over the transaction hash. Signatures must be sorted by owner address so the Safe can efficiently prevent duplicates.

​
Module transaction

Safe also exposes execTransactionFromModule and execTransactionFromModuleReturnData to execute transactions initiated by enabled modules. A module can be any contract address that has been explicitly enabled on the Safe. Once enabled, a module can execute transactions through the Safe without going through owner signature verification (which is why modules are security-critical). Module calls include:
  • to: Recipient address.
  • value: Amount of ETH to send (in wei).
  • data: Calldata, typically a function call on to.
  • operation: Execution type: CALL or DELEGATECALL.

​
Core components

The following components are central to how Safe Smart Accounts are extended and secured.

​
Safe Modules

Safe Modules are smart contracts that extend Safe functionality while keeping module logic separate from the Safe core contracts. Learn more on the Safe Modules page.

​
Safe Guards

Safe Guards perform checks before and after a Safe transaction is executed. Learn more on the Safe Guards page.

​
Signatures

Safe supports multiple signature schemes, including EIP-1271 and EIP-712. It also supports relayed execution by keeping confirmation and verification logic independent of msg.sender. For details on supported signature schemes and encoding, see: