Setting Up a Safe Multisig on Base and Arbitrum Without Burning Money on Gas

The treasury that was one signature deep

Our team ran its operating funds out of a single hot wallet for far too long. The failure, when it came, was not dramatic. A teammate signed one approval to a "revoke tool" that a search result had surfaced, the contract was a drainer wearing the right logo, and about $18,000 of USDC plus a little ETH walked out of the wallet inside a minute. No seed phrase leaked. No exchange failed. The entire security model was one key on one laptop, and one signature was enough to empty it.

We moved the treasury into a Safe multisig two weeks later and I have set one up for every team I have worked with since. The mechanism is boring in the best way: no single person, no single stolen key, no single phishing click can move the money. What follows is the setup I actually run, the threshold math behind it, and the cost difference that makes doing this on Base or Arbitrum almost free. The comparable single-wallet risks are laid out in the L2 security risks guide.

The detail that still bothers me is how little it would have cost to prevent. The drainer exploited an approval, not a broken contract, and the whole loss hinged on there being exactly one key that could authorize a transfer. One extra signature requirement — a second person, a second device — and the transaction would have died at the threshold instead of moving $18,000. We spent two weeks congratulating ourselves on a fast response and about ninety seconds understanding the actual fix.

What a Safe actually is — and what it is not

A Safe is a smart contract account. The funds do not sit at an address controlled by a private key; they sit at the contract's address, and the contract will only execute a transaction when a preset number of owner keys have signed off. On Base (chain id 8453) and Arbitrum One (42161) the same Safe contracts are deployed at identical addresses across chains through deterministic deployment, which is why a Safe you create on Base has the exact same address as one on Arbitrum if the owners and threshold match.

Three things people get wrong. It is not a backup — it survives a lost key, not a lost threshold. It is not a hardware wallet — it holds the policy, while a hardware wallet holds one of the keys that satisfies that policy; the two are strongest together, as covered in using a hardware wallet on Base and Arbitrum. And it is not free of responsibility — you become the operator of a small treasury contract, and losing enough keys permanently freezes the funds with no customer support line.

The practical consequence of all this is that a Safe behaves like an account you deploy and configure, not a wallet you import from a seed. You can rename it, add owners, and read its transaction history on Basescan or Arbiscan like any other address. What you cannot do is hand someone a phrase and have them restore it; the recovery story is owners and threshold, full stop. Understanding that upfront is what separates people who use a multisig well from people who build one, breathe a sigh of relief, and then discover eighteen months later that they cannot get in.

Threshold design: the number that decides everything

The instinct on first setup is to over-protect: a 3-of-3 or 2-of-2 that feels maximally secure. It is the wrong direction. A 2-of-2 dies the moment either key is lost or either signer is unreachable, and if both keys live on the same laptop you built a 1-of-1 that merely looks impressive. The rule I follow: the threshold must be strictly greater than one, and the number of spare owners above the threshold must also be at least one. 2-of-3 and 3-of-5 satisfy both. 3-of-3 and 2-of-2 do not.

There is a second-order point people miss: the threshold is not the only number that matters, the identity of the spare owners is too. A 3-of-5 where three of the five keys belong to one person, or all five sit on devices in the same office, has quietly collapsed back toward a single point of failure. The redundancy only counts if it is genuinely distributed — different people, different devices, different places.

Deployment cost: the reason this belongs on a rollup

The deployment itself is a one-time cost, but every structural change is a transaction too: adding an owner, removing an owner, or changing the threshold each cost gas. On mainnet that is a real bill that makes people postpone important hygiene. On Base or Arbitrum it is pennies, so you can add an owner, rotate a key that might have been exposed, or raise the threshold the moment circumstances change instead of scheduling it for "someday." That flexibility is the quiet argument for running the treasury on a rollup — the policy stays current instead of drifting.

The mainnet figures swing too much to plan around. A quiet Saturday can get a deploy under $8; a congested week pushes it past $20 for the identical contract. On Base and Arbitrum the number barely moves, which is the real point: the cost of good security hygiene should not depend on the calendar.

Adding owners and putting a hardware wallet on the list

Adding an owner is an owner-initiated transaction, which means you sign it with an existing owner set — including the threshold rule. So the order matters: get the initial owner list and threshold right at creation, because fixing them later requires the current owners to cooperate. When you add a signer, paste their plain wallet address and verify every character against the device or a saved contact; a silently altered address in a browser extension is a classic attack.

I require at least one hardware wallet in every treasury configuration, holding the key on a device that never touches the internet. The hardware wallet does not replace the multisig — it is one strong key inside it. When a transaction is proposed, each owner signs an EIP-712 structured message; the hardware wallet displays the Safe address, the target, and the amount on its own screen, so a compromised browser cannot slip a different transaction past the signature. This is the same device discipline that protects any large balance, and the broader setup is in the hardware wallet guide.

Two habits make owner management painless. First, keep a written owner list — address, who holds it, which device — so nobody has to guess who the third signer is during an emergency. Second, whenever the roster changes, run a tiny test payment immediately. An owner change that has not been exercised with a real transaction is a config you believe in, not one you have verified. On Base or Arbitrum both habits cost a few cents. If a confirmed test payment hangs in your balance view, that is almost always the node talking, not the Safe — a second endpoint sorts it out, as covered in choosing an RPC for Base and Arbitrum.

The recovery and backup traps that freeze funds

Multisigs trade single-point failure for a new failure mode: not enough keys. Here are the traps I have watched people walk into.

• Two keys, one machine. A 2-of-3 where two seeds sit on the same laptop or the same password manager is a 1-of-1 with extra steps. Separate the keys across devices and locations by design.
• The unforgettable address. A Safe address is not derived from any seed phrase. Write it down with its network name and store it somewhere durable; a wallet-restore from seed will not bring the Safe back.
• Silent threshold erosion. Every lost signer permanently lowers your resilience. If a teammate leaves, replace their key on the multisig instead of just deleting their contact.
• Recovery modules left untested. Guardian or social-recovery setups only help if you have actually walked the flow once, before you need it.

If keys are already gone, the situation is not always final — the wallet recovery guide covers what is and is not salvageable after a compromise. Prevention is cheaper: a spare owner above the threshold means a single loss is an inconvenience, not a crisis.

The one that catches teams most often is not a dramatic hack but a departure. A signer leaves, their device gets wiped as part of offboarding, and six months later the treasury is quietly operating at a lower effective threshold than anyone remembers. Because replacing that key is a pennies-on-Base transaction, there is no excuse to let it slide — do it in the same week, in the same meeting where you revoke their other access.

Personal savings vs a team treasury: different rules

The mistake I see most is running both with the same template. They need different priorities.

For personal long-term savings, the enemy is losing access. A 2-of-3 — a phone key, a hardware-wallet key, and a third key on paper in a separate location — keeps the funds safe from one theft and one loss, and lets you move alone when you must. It is a vault you operate solo, and the third key exists purely so a single failure never locks you out.

For a team treasury, the enemy is one person going rogue or one person getting phished. That flips the design toward distribution: 3-of-5, one key per person, at least two hardware wallets, zero overlap in where the keys are stored, and a written list of who holds what that the team reviews quarterly. No individual should hold two keys. Someone should be able to be unavailable for a week without blocking payroll. If the team cannot execute a payment on a normal day, the config is too tight; if any one person can, it is too loose.

One more team-only habit: treat the multisig as an account you audit, not a wallet you open. Activity shows up on Basescan or Arbiscan, and approvals granted by the Safe should be reviewed with the same discipline as any wallet — the mechanics are in the approval-revoking guide and the cost of each is explained in ERC-20 approval fees.

My setup, itemized

• Team treasury: a 3-of-5 Safe on Base, one key per person, two of them hardware wallets, no two keys stored together.
• Personal savings: a 2-of-3 Safe across phone, hardware wallet, and a paper key in a separate location.
• The Safe address and its network written down on paper and in a shared document, because it cannot be derived from a seed.
• A small test transaction after every owner or threshold change — the change is only real once you have sent through it.
• Quarterly review: confirm every signer is reachable, rotate any key under suspicion, and check the Safe's token approvals.

Our single-wallet treasury cost us $18,000 to learn this. The multisig that replaced it cost about twenty cents to deploy on Base and has saved the team from at least one more near-miss since. On chains this cheap there is no good reason for a treasury to depend on one key on one laptop — set the threshold, spread the keys, and make a single mistake survivable.