A single private key is a single point of failure. If a laptop gets stolen, a seed phrase gets phished, or a signer simply forgets a password, funds behind that one key are gone. That risk is exactly why institutional treasuries, DAOs, and increasingly individual holders are moving funds into multisig wallets, where two or more separate keys must approve every transaction before it executes on chain.

This tutorial walks through building a production-ready multisig wallet using Safe, the contract framework formerly branded as Gnosis Safe, paired with hardware wallet cosigners from Ledger and Trezor. By the end you will have a deployed Safe, a tested transaction flow, a spending-limit module for day-to-day spending, and a documented recovery plan. The guide covers 12 numbered steps, several code blocks you can copy directly into a terminal or script, and a troubleshooting section built from the failure modes that trip up first-time multisig operators.

None of the steps below require a background in Solidity or smart contract development. The entire workflow runs through a browser interface and a handful of optional scripts, so a small team, a solo holder who wants a backup signer, or a DAO treasurer can all follow the same procedure. What changes between those use cases is mostly the threshold you pick in Step 1 and how formal your recovery documentation in Step 11 needs to be.

Why a Single Private Key Isn’t Enough in 2026

Hardware wallets remain the gold standard for self-custody, but a hardware wallet protects against remote attackers, not against the physical loss of a single device or a single compromised signing session. A report dated October 2026 described a wallet-draining incident tied to Ledger-ecosystem signing flows that affected 311 wallets across five chains, with an estimated loss of roughly $92.9 million, split across Tron, Bitcoin, Ethereum, BNB Chain, and Polygon, according to a report from cnyes.com. Ledger had not confirmed the total at the time of that report, so treat the figure as an external estimate rather than a finalized loss number.

That incident is a useful motivator rather than a reason to panic. It illustrates what a single compromised signing path can cost when there is no second approval standing between a malicious transaction and an on-chain execution. A multisig wallet does not make hardware wallets unnecessary. It adds a second, third, or fifth independent approval on top of them, so one bad signature from one device cannot move funds by itself.

The same logic applies whether the assets in question belong to a two-person side project, a ten-person DAO treasury, or a company holding customer funds. The failure mode is identical in every case: one key, one approval, one point where an attacker, a mistake, or a lost device can end the story. Multisig does not eliminate that risk entirely, since a threshold of compromised signers can still move funds, but it raises the cost of an attack from compromising one device to compromising several independent devices held by several independent people, which is a far harder bar to clear.

What Is Safe, Formerly Known as Gnosis Safe

Safe is the current name for the smart contract wallet framework that most of the industry still searches for under its old name, Gnosis Safe. The product interface is called Safe{Wallet}, reachable at app.safe.global, and the underlying contracts are open source at github.com/safe-fndn/safe-smart-account. According to Safe’s own documentation, cited in a 2026 deep dive published on Eco’s support site, the contracts have been reviewed across multiple audit rounds: G0 Group covered releases 1.1.1 through 1.3.0, Certora and Nethermind Security audited 1.3.0, and Ackee Blockchain reviewed 1.4.0 and 1.5.0.

Safe’s smart-account contracts currently span versions v1.0.0 through v1.5.0, and which version is available depends on the chain you deploy to. Ethereum Mainnet supports the full range up through v1.5.0, according to Safe’s own supported-networks documentation. A Safe wallet is not a single private key with extra steps. It is a smart contract that holds funds directly and only moves them once a threshold of designated owner addresses has signed off, which is why it is often described as account abstraction rather than a simple multi-key scheme.

A 2026 review of the product on WalletReview put the newest contract release, v1.5.0, at having shipped in mid-2025, and noted that Safe charges nothing to use the interface itself, with Safe’s own power-user documentation citing support for 28-plus networks and integrations with more than 200 DeFi applications. That breadth is one reason Safe has become the default answer for teams asking how to move beyond a single hardware wallet without giving up programmability.

Prerequisites: What You Need Before You Start

  • Two or more hardware wallets (Ledger or Trezor devices, each initialized with its own independent seed phrase, stored separately)
  • A browser with no unverified extensions installed, used only for the Safe{Wallet} interface at app.safe.global
  • Node.js 18 or newer if you plan to script deployments or transaction proposals with the Safe SDK
  • The @safe-global/protocol-kit and @safe-global/api-kit packages (install the latest published version, do not pin to an old release)
  • A funded deployer address with enough native token to cover one deployment transaction (roughly $50 to $150 in gas on Ethereum Mainnet at current prices, far less on an L2)
  • A written list of every owner address, cross-checked against each hardware wallet’s on-device display, not copy-pasted from a notes app
  • A decision, made in advance, on your confirmation threshold and what happens if one signer becomes unavailable

None of this requires writing Solidity. Safe’s deployed contracts handle the logic, your job is configuration, verification, and operational discipline.

It also helps to decide, before you start, which network you will deploy on first. Ethereum Mainnet gives you the widest audit history and the deepest DeFi integration, but it carries the highest gas cost per transaction. An L2 such as Base or Arbitrum cuts that cost by an order of magnitude and is a reasonable place to run a day-to-day operational Safe, while reserving a Mainnet Safe for a treasury that moves less often. Pick one network to start with, finish the whole 12-step process there, and only then repeat Step 9 to replicate the same address elsewhere.

Step 1: Choose Your Signer Set and Threshold

Before opening any wallet software, decide how many owners your Safe will have and how many signatures are required to execute a transaction, written as an M-of-N threshold. Smaller teams commonly use 2-of-3, which tolerates one unavailable signer while still requiring two independent approvals. Larger treasuries tend toward 3-of-5, which survives the loss of up to two signers without locking funds and prevents any two-person collusion from moving assets alone. The table below summarizes common configurations.

ThresholdOwners Needed to ActTolerates This Many Lost SignersTypical Use Case
2-of-220Personal backup pair, not recommended for sole custody
2-of-321Small teams, personal treasury with a backup signer
3-of-532Institutional or DAO treasury
4-of-743Larger organizations with distributed signer committees

Avoid 1-of-N configurations for anything beyond short-lived testing. A single approving signature defeats the entire purpose of a Safe multisig wallet, since it means one compromised key can still move every asset the contract holds.

Institutional treasury guidance published by ChainScore Labs frames the threshold decision around a simple question: how many people would need to collude, or how many devices would need to be simultaneously compromised, for an attacker to move funds without the rest of the organization noticing. A 3-of-5 setup means an attacker needs to compromise three separate hardware devices held by three separate people before a single unauthorized transaction can execute, which is a meaningfully higher bar than a 2-of-3 setup guarding the same assets. Weigh that security margin against the operational cost of needing three people available every time a transaction has to move.

It is worth separating the threshold decision from the owner count decision. You can run a 3-of-7 Safe just as easily as a 3-of-5, trading a slightly higher coordination overhead for more redundancy against lost or unavailable signers. There is no universally correct number. The right threshold is the smallest one that still requires genuine collusion or a genuine multi-device compromise to move funds without your knowledge.

Step 2: Prepare Your Hardware Wallet Cosigners

Each owner address in your Safe should correspond to a separate hardware wallet, not a software wallet or an exchange-custodied address. Safe’s ecosystem documentation identifies Ledger and Trezor as the hardware options most commonly paired with the Safe{Wallet} interface, each connected through its own browser bridge or desktop application. Initialize each device independently, write down each seed phrase on paper or metal, and store the backups in physically separate locations. Do not generate two owner keys on the same device or back them up to the same safe deposit box, since that collapses the independence the multisig model depends on.

Label each device clearly, note which Ethereum address it controls, and assign that information to a specific named signer. A multisig wallet with three anonymous addresses and no record of who controls what is far harder to recover from if one person leaves a team or becomes unreachable.

If a signer already owns a hardware wallet they use for personal holdings, resist the temptation to reuse an existing address as a Safe owner. A dedicated address for Safe duty, derived from the same device but on its own derivation path, keeps personal activity and treasury-signing activity cleanly separated, which makes auditing who approved what far simpler months or years later.

Step 3: Create a New Safe at app.safe.global

Open a browser session, navigate to app.safe.global, and connect the first hardware wallet through its supported bridge. Select the network you intend to deploy on first, such as Ethereum Mainnet, then choose the option to create a new Safe rather than importing an existing one. The interface will ask for a name, which is stored locally and does not affect the contract, followed by the list of owner addresses and the threshold you settled on in Step 1.

Double-check the network selector before proceeding. Deploying to the wrong chain by mistake is one of the most common early errors, covered in more detail in the troubleshooting section below.

Step 4: Add Owners and Set the Confirmation Threshold

Enter every owner address exactly as it appears on each hardware wallet’s screen, not from a browser extension’s cached display. Paste each address, then manually verify the full string character by character against the device, since a single altered character can redirect an owner slot to an address nobody controls. Set the threshold field to match your Step 1 decision, for example 2 out of 3 or 3 out of 5. The Safe{Wallet} interface will display a summary screen before deployment, showing the final owner list and threshold. Review that summary slowly. This is the last checkpoint before the configuration becomes permanent on chain.

Step 5: Predict the Address and Deploy the Safe Contract

Safe deployments use a factory contract and a deterministic CREATE2 address, which means you can calculate the resulting Safe address before spending any gas. If you prefer scripting the deployment instead of using the browser interface, the Safe{Core} SDK’s protocol-kit package supports exactly this through a predicted-Safe configuration.

npm install @safe-global/protocol-kit@latest ethers@latest
// deploy-safe.js (Node.js 18+, requires an RPC URL and a one-time deployer key)
import Safe from "@safe-global/protocol-kit"

const owners = [
  "0xA1b2C3d4E5f6000000000000000000000000A1", // Ledger - signer 1
  "0xB2c3D4e5F6a7000000000000000000000000B2", // Trezor - signer 2
  "0xC3d4E5f6A7b8000000000000000000000000C3", // Ledger - signer 3 (backup)
]
const threshold = 2 // 2-of-3

async function main() {
  const protocolKit = await Safe.init({
    provider: process.env.RPC_URL,
    signer: process.env.DEPLOYER_KEY,
    predictedSafe: { safeAccountConfig: { owners, threshold } },
  })

  const predictedAddress = await protocolKit.getAddress()
  console.log("Predicted Safe address:", predictedAddress)

  const deploymentTransaction = await protocolKit.createSafeDeploymentTransaction()
  const client = await protocolKit.getSafeProvider().getExternalSigner()
  const txResponse = await client.sendTransaction(deploymentTransaction)
  console.log("Deployment transaction hash:", txResponse.hash)
}

main()

Running the script above against a connected RPC endpoint produces output similar to this, though your addresses and hash will differ:

Predicted Safe address: 0x9f3a...22c1
Deployment transaction hash: 0x7bd1a4...e90f3c

A fresh Safe proxy deployment on Ethereum Mainnet typically consumes roughly 1.5 to 2.5 million gas, depending on the owner count and threshold, with the exact figure varying by network conditions. Wait for the deployment transaction to confirm before funding the new address, and confirm the address returned by the script matches what the Safe{Wallet} interface shows for the same configuration.

Step 6: Verify Every Address on Your Hardware Device

This step is the single most skipped part of multisig setup, and it is also the step most directly connected to incidents like the Ledger-ecosystem drain referenced earlier in this guide. Every hardware wallet has a small screen specifically so you can verify the address and transaction details independently of whatever your computer’s browser is displaying. Before confirming any signature, check that the address shown on the device matches the address you expect, character by character, not just the first and last four digits.

Blind signing, meaning approving a transaction without reading what the device actually displays, is how a compromised browser extension or a malicious dApp front end can trick a signer into approving something other than what they think they are approving. Safe’s EIP-712 typed-data signing is designed to show structured, readable transaction details on supported hardware wallets rather than a raw hex blob, so use that readability. If a device shows an unreadable string of bytes instead of a clear summary, stop and investigate before signing.

Step 7: Fund the Safe and Run a Test Transaction

Send a small amount, not your full treasury, to the newly deployed Safe address first. Once the funds arrive, initiate a test transaction from the Safe{Wallet} interface, such as sending a tiny fraction back out to a known address. The first signer proposes the transaction, which then appears as pending in the interface, and the remaining required signers must open the same transaction and approve it from their own hardware wallets before it executes.

A successful test produces a pending-to-executed state change you can watch in real time, with output in the activity log resembling:

Transaction queued: 1 of 2 confirmations
Transaction queued: 2 of 2 confirmations
Transaction executed: 0x4e8a...f10b (block 21384022)

Only after a full round-trip test succeeds, with every signer confirming from their own device, should you move meaningful funds into the Safe.

Step 8: Add a Spending-Limit Module for Day-to-Day Use

Requiring every signer to approve every small transaction gets impractical fast for operational expenses. Safe supports modules, which are separate contracts that extend a Safe’s behavior under rules the owners define upfront. The Allowance Module lets owners grant one delegate address a capped daily or periodic spending limit, so routine payments do not need the full multisig quorum while large transfers still do.

// enable-allowance-module.js
import Safe from "@safe-global/protocol-kit"

const protocolKit = await Safe.init({
  provider: process.env.RPC_URL,
  signer: process.env.OWNER_KEY,
  safeAddress: process.env.SAFE_ADDRESS,
})

const enableModuleTx = await protocolKit.createEnableModuleTx(
  process.env.ALLOWANCE_MODULE_ADDRESS
)
const signedTx = await protocolKit.signTransaction(enableModuleTx)
const result = await protocolKit.executeTransaction(signedTx)
console.log("Allowance module enabled, tx:", result.hash)

Enabling a module still requires reaching the Safe’s full threshold once, since it changes what the contract is allowed to do. After that one-time approval, the delegate can spend within the configured limit without collecting fresh signatures for every transaction.

Step 9: Replicate the Same Safe Address on Other Chains

Because Safe deployments rely on a deterministic factory and a consistent salt nonce, the same owner list, threshold, and factory version will produce the identical Safe address on any EVM-compatible chain, including Optimism, Polygon, Arbitrum, Base, BNB Chain, Avalanche C-Chain, Gnosis Chain, zkSync Era, Linea, Scroll, Mantle, Celo, Rootstock, and Kaia, which Safe documentation lists among its supported networks. This lets a team use one memorable address across multiple chains instead of juggling a different address per network.

# Confirm a predicted address matches before funding a second chain
cast call  \
  "createProxyWithNonce(address,bytes,uint256)" \
     \
  --rpc-url $ARBITRUM_RPC_URL
NetworkChain IDNewest Safe Smart-Account Version
Ethereum Mainnet1v1.5.0
Optimism10v1.4.1
Base8453v1.4.1 or newer, per chain docs
Kaia Mainnet8217Varies, see Kaia-specific Safe docs

Always verify the predicted address on a new chain before sending funds. A different factory version or a mismatched nonce will silently produce a different address, and funds sent to the wrong one are not recoverable through the Safe interface.

Not every chain carries the exact same contract version, which is why the table above lists the newest available version per network rather than a single blanket number. Before relying on a cross-chain deployment for anything beyond testing, open the Safe{Wallet} interface on the second chain, look up the predicted address independently there, and compare it to what your script or your first deployment produced. A matching address on two different chains is a strong signal your configuration, including the exact factory and singleton contract versions, lined up correctly.

Step 10: Script Proposals With the Safe SDK

For teams that need to propose transactions programmatically, such as a treasury bot that queues recurring payments for human signers to approve, the Safe SDK’s api-kit package handles posting a proposed transaction to Safe’s transaction service so every owner sees it in their Safe{Wallet} interface. This is the complete working piece you can adapt into a standalone project.

npm install @safe-global/protocol-kit@latest @safe-global/api-kit@latest
// propose-transaction.js (queues a payment for the remaining signers)
import Safe from "@safe-global/protocol-kit"
import SafeApiKit from "@safe-global/api-kit"

const safeAddress = process.env.SAFE_ADDRESS
const protocolKit = await Safe.init({
  provider: process.env.RPC_URL,
  signer: process.env.SIGNER_1_KEY,
  safeAddress,
})
const apiKit = new SafeApiKit({ chainId: 1n })

const safeTransaction = await protocolKit.createTransaction({
  transactions: [
    { to: process.env.RECIPIENT, value: process.env.AMOUNT_WEI, data: "0x" },
  ],
})

const safeTxHash = await protocolKit.getTransactionHash(safeTransaction)
const signature = await protocolKit.signHash(safeTxHash)

await apiKit.proposeTransaction({
  safeAddress,
  safeTransactionData: safeTransaction.data,
  safeTxHash,
  senderAddress: process.env.SIGNER_1_ADDRESS,
  senderSignature: signature.data,
})

console.log("Proposed transaction hash:", safeTxHash)

Package this script with a small .env file holding the RPC URL and the Safe address, and it becomes a reusable project any signer with a Node environment can run to queue a payment for the rest of the group to approve from their own hardware wallets.

Step 11: Write a Signer Rotation and Recovery Plan

A multisig wallet is only as resilient as its plan for when a signer leaves, loses a device, or becomes unreachable. Document, in advance, exactly how your team will swap an owner address, which requires a transaction approved by the existing threshold that calls the Safe’s owner-management functions to remove the old address and add a new one. Store this procedure somewhere durable and accessible to every current signer, not only in one person’s memory.

Decide in advance what counts as a signer becoming unreachable, how long the group waits before acting, and who has the authority to propose a rotation. Treat this document the same way you treat the hardware wallets themselves, as critical infrastructure rather than an afterthought written only once funds are already locked behind a threshold nobody can reach.

A practical recovery plan usually covers three scenarios separately: a signer who is temporarily unavailable but still trusted, a signer who has left the organization and should be removed outright, and a signer whose device may have been compromised, which calls for an emergency rotation rather than a routine one. Write out the exact owner-management transaction each scenario requires, who proposes it, and how many of the remaining signers need to approve it, so the group is executing a rehearsed procedure rather than improvising during a stressful moment.

Step 12: Run a Pre-Launch Security Review

Before moving a meaningful balance into the Safe, do a final on-chain check of the owner list and threshold directly against the contract, rather than trusting only what the browser interface displays.

# Read the live owner list and threshold straight from the contract
cast call  "getOwners()(address[])" --rpc-url $ETH_RPC_URL
cast call  "getThreshold()(uint256)" --rpc-url $ETH_RPC_URL

Compare the returned addresses against your written signer list character by character, and confirm the threshold value matches your intended configuration. If you enabled any modules, such as the spending-limit module from Step 8, review their permissions as well, since a misconfigured module can create a path around the multisig threshold entirely.

Common Pitfalls When Setting Up a Multisig Wallet

  • Using software wallets as owners. A browser extension wallet on an internet-connected machine defeats the point of a hardware-backed multisig, since malware on that machine can approve transactions without a physical confirmation step.
  • Setting the threshold too low. A 1-of-N Safe offers no real protection over a single key, since any one compromised signer can move every asset alone.
  • Setting the threshold too high relative to signer availability. A 5-of-5 Safe locks funds completely the moment one signer is unreachable, with no path to recovery until that signer returns.
  • Blind signing transactions. Approving whatever a browser shows without reading the hardware wallet’s own display is the exact failure pattern behind many wallet-draining incidents.
  • Skipping the test transaction. Sending a full treasury balance to a freshly deployed Safe before confirming a small round-trip transaction works leaves no margin for a misconfiguration.
  • Assuming the same address works everywhere without checking. Deploying on a new chain with a different factory version or nonce can produce a different address than expected, and funds sent to the wrong address are not recoverable through the interface.
  • No documented recovery plan. Teams that never write down a signer-rotation procedure often discover, during an actual emergency, that nobody remembers the exact steps required to swap an owner.

Gas Costs and Fees to Budget For

Safe itself does not charge a protocol fee on transaction execution. Every cost you pay is the underlying blockchain’s standard gas fee, which varies by network congestion and the native token’s price.

ActionApproximate Gas UsedNotes
Deploying a new Safe proxy1.5M to 2.5M gasVaries with owner count and threshold
Executing a Safe transaction+40,000 to 60,000 gasAdded on top of the destination contract’s own execution cost
Basic token or ETH transfer through a Safe~100,000 to 150,000 gasVaries by transaction type and network load
Ethereum Mainnet deployment, dollar estimateRoughly $50 to $150Changes substantially with ETH price and gas fees at the time

Deploying and operating a Safe on an L2 such as Base, Arbitrum, or Optimism is typically far cheaper than Ethereum Mainnet, which is one reason many teams deploy their primary operational Safe on an L2 and reserve Mainnet for larger, less frequent transfers.

Budget for more than just the deployment transaction. Every signature round that executes a transaction also costs gas, and a team that proposes and executes several transactions a week on Ethereum Mainnet will spend meaningfully more over a year than a team running the same workflow on an L2. If your Safe is mostly a cold-storage treasury that moves funds a handful of times a year, Mainnet gas costs are a rounding error. If it is an active operational wallet handling frequent payments, the cumulative gas difference between Mainnet and an L2 is worth modeling before you commit to a network.

Safe vs Other Multisig Options

Safe is not the only way to run a multisig wallet, and the right choice depends on which chain your assets live on and how much programmability you need.

OptionChainsProgrammabilityBest For
Safe (Gnosis Safe)28+ EVM-compatible networks, per Safe’s own documentationHigh, supports modules and custom logicTeams and treasuries that want smart contract flexibility
Native Bitcoin multisig (P2SH/P2WSH)Bitcoin onlyLow, fixed script templatesBitcoin-only cold storage without smart contract needs
Hardware wallet passphrase-based multi-key setupsChain-dependentLowSimpler setups without on-chain contract logic

For Bitcoin-only holdings, a native multisig script template avoids EVM entirely and may be the better fit. For anything on an EVM chain, especially where modules, spending limits, or DAO governance integration matter, Safe remains the most widely audited and adopted option.

One more distinction worth noting is who writes the contract logic you are trusting. A native Bitcoin multisig relies on standardized, well-understood script templates that have changed little in years, which is itself a form of safety through simplicity. Safe’s smart contracts are more complex and carry more surface area, which is exactly why the multiple independent audit rounds from G0 Group, Certora, Nethermind Security, and Ackee Blockchain mentioned earlier in this guide matter. Complexity bought with audited, battle-tested code is a reasonable trade for the programmability a smart contract wallet provides, but it is a trade you should make deliberately rather than by default.

Troubleshooting Guide

  • Transaction stuck at pending confirmations. Check that every required signer actually opened the transaction in their own Safe{Wallet} session. A proposal only moves forward once the full threshold count of owners confirms it.
  • Safe{Wallet} shows the wrong balance or network. Confirm the network selector at the top of the interface matches the chain where you actually deployed. Safe addresses can exist, unfunded, on chains you never intended to use.
  • Hardware wallet not detected by the browser. Reconnect the device, confirm its firmware is unlocked and on the correct app (such as the Ethereum app on a Ledger), and try a different USB cable or port.
  • Predicted address does not match between networks. This usually means a different factory or singleton contract version was used on the second chain. Recompute the prediction using the exact same owners, threshold, and salt nonce.
  • Deployment transaction fails with a gas estimation error. This is often a stale RPC endpoint or an incorrect factory address for that chain. Switch RPC providers and re-verify the factory address against Safe’s official documentation.
  • Signature rejected or address mismatch on the hardware device. Stop immediately. This typically means the transaction data shown on the device does not match what you expected, which is the exact scenario blind-signing protections are meant to catch.
  • Threshold set incorrectly and transactions cannot execute. If you accidentally set a threshold higher than the number of available signers, the available owners will need to first approve an owner-management transaction lowering the threshold, assuming enough signers remain to reach the original quorum.
  • Lost access to a signer’s hardware device. Execute your documented recovery plan from Step 11, which should already specify how the remaining signers propose and approve an owner swap.
  • SDK script throws a nonce or sequencing error. Multiple pending proposals from the same owner can conflict. Fetch the Safe’s current nonce from the api-kit before constructing a new transaction.

Advanced Tips for Power Users

Once the basic Safe is working, a few additional patterns are worth layering in. Time-locked modules can delay execution of large transfers by a fixed window, giving signers a chance to catch a mistake or a compromised proposal before funds actually move. Guard contracts let owners attach extra validation logic that runs on every transaction, such as rejecting transfers above a certain size unless a specific condition is met.

For organizations running many Safes across chains, the Safe Transaction Builder lets you batch multiple calls into a single proposal, which cuts down on the number of separate signature rounds your team needs to complete. If your workflow benefits from gasless relaying, look into Safe’s relayer-compatible flows, which let a third party submit the final transaction while owners still provide the signatures that actually authorize it. Treat every new Safe Apps integration the same way you treat a new browser extension, by verifying what permissions it requests before connecting it to a Safe holding real funds.

It is also worth periodically re-running the on-chain verification from Step 12, not just at launch but on a recurring schedule, such as quarterly for a treasury or monthly for a more active operational Safe. Owner lists and module permissions do not change on their own, so a difference between what you expect and what the contract actually returns is a signal worth investigating immediately rather than dismissing as a display glitch. Pairing that recurring check with the signer rotation plan from Step 11 turns multisig security from a one-time setup task into an ongoing habit, and that habit is what keeps a Safe wallet safer than the single key it replaced.

Frequently Asked Questions

Is Safe the same thing as Gnosis Safe?
Yes. Safe is the current name for the product previously branded Gnosis Safe. The underlying smart contracts and the broader multisig concept are the same, and many people still search using the old name.

How much does it cost to deploy a Safe wallet?
Safe charges no protocol fee. You pay only the blockchain’s standard gas cost, which on Ethereum Mainnet has recently run roughly $50 to $150 depending on gas prices and ETH’s value at the time, and considerably less on an L2.

What is the best multisig threshold for a small team?
2-of-3 is a common starting point for small teams, since it tolerates one unavailable signer while still requiring two independent approvals for every transaction.

Can I use a Safe across multiple blockchains with the same address?
Yes, because Safe deployments use a deterministic factory contract. The same owner list, threshold, and salt nonce produce an identical address on other EVM-compatible chains, though you should always verify the predicted address before funding it on a new network.

What happens if I lose one of my hardware wallet signers?
If your threshold still allows the remaining owners to reach quorum, they can approve an owner-management transaction that removes the lost signer and adds a replacement. This is why a documented recovery plan, written before any funds move in, matters so much.

Is Safe affected by the Ledger-related wallet drain reported in October 2026?
The reported incident involved Ledger-ecosystem signing flows and was not described as a flaw in Safe’s own contracts, which have gone through multiple independent audit rounds. The episode is still a useful reminder to verify every transaction on a hardware device’s own screen before approving it.

Do I need to know how to code to use Safe?
No. The Safe{Wallet} browser interface at app.safe.global handles deployment, owner management, and transaction approvals without any scripting. Code becomes useful only if you want to automate recurring proposals or integrate a Safe into another application.

Can a Safe wallet interact with DeFi apps directly?
Yes. Because a Safe is a smart contract wallet, it can hold positions in and interact with DeFi protocols the same way an externally owned account can, subject to each signer approving the relevant transaction up to the configured threshold.