01Configure your multisig
Pick a preset or define your own. Owners are the addresses that can propose, confirm and execute transactions. The threshold is the number of confirmations required to execute.
02Read the source audit in < 1 hour
This is the exact contract that gets deployed. No build step, no library substitution, no compiler tricks. Read it line by line.
03Why this is safer
The contract is not magic — classic m‑of‑n multisig logic, written plainly. The safety comes from removing things, not adding them.
No proxy, no delegatecall
The contract has no delegatecall, no proxy, no module system. The Bybit attack worked because the malicious payload triggered a delegatecall into attacker-controlled logic via a Safe upgrade. That class of attack is structurally impossible here.
No trusted frontend
The "UI" you signed against can be the attack surface. Here, the page is one HTML file you can host yourself or open locally. The contract is right above — no hidden imports, no remote builds.
Immutable storage layout
Owners and threshold are set in the constructor. There is no addOwner, no swapOwner, no setter. A compromised signer cannot quietly rotate keys or change the threshold under you.
Readable in one sitting
Most multisig contracts are too large to fully audit before use. This one is short enough that any developer can read every line, every modifier, every event, before sending it a single wei.
04Compared to Safe (Gnosis Safe)
Safe is well audited and battle-tested. It also has a much larger attack surface. Here are the tradeoffs side by side.
| Property | Safe | ethmultisig |
|---|---|---|
| Core contract size | Thousands of lines across many files | ~120 lines, one file |
| External imports / libraries | Multiple internal libraries, base contracts, fallback handler | Zero |
| Proxy / upgradeability | Proxy pattern; singleton is upgradeable via masterCopy |
No proxy. Immutable. |
delegatecall |
Used heavily (fallback handler, modules, exec) | Never used |
| Modules / plugins | Module system can bypass signature checks if enabled | No module system |
| Owner rotation at runtime | Yes (addOwner, swapOwner, removeOwner) |
No — owners are immutable |
| Threshold change at runtime | Yes (changeThreshold) |
No — fixed at deploy |
| Off-chain signature aggregation | Yes (signatures gathered off-chain, submitted in one tx) | No — each owner confirms on-chain |
| Gas per execution | Lower (single batched submission) | Higher (one tx per confirmation) |
| UI surface to attack | Large (Safe{Wallet}, Tx Builder, signers' wallets, RPC) | Minimal (one HTML file, raw eth calls) |
| Recovery / social recovery | Possible via modules | Out of scope — lose your keys, lose your funds |
| Ecosystem integration | Huge — signers in many wallets, dApps | Minimal — you sign with raw transactions |
| Audit cost to fully understand | Days to weeks | Less than an hour |
In short: Safe optimises for features and UX. ethmultisig optimises for auditability and attack-surface minimisation. If you hold large sums and rarely move them, simpler is safer.
05What complexity has cost the ecosystem
To be fair: in every public incident below, Safe's smart-contract code itself was not directly broken. The losses came from the surrounding complexity — signing UIs, frontends, build pipelines, and delegatecall‑based upgrade flows that Safe enables. That's the point: complexity is the attack surface.
Bybit · ~$1.4 billion
Attackers (attributed to DPRK's Lazarus Group) compromised the Safe{Wallet} frontend infrastructure and showed Bybit signers a benign-looking transfer while the underlying transaction was a delegatecall that swapped the Safe's implementation to attacker-controlled code. Signers approved what they saw; the chain executed something else. Largest crypto theft in history at the time.
WazirX · ~$230 million
A 4‑of‑6 Safe was drained after attackers used a manipulated signing flow to get signers to approve a transaction whose calldata differed from what was displayed. Liberty Reserve‑style social engineering combined with the gap between what Safe's UI showed and what was actually signed.
Radiant Capital · ~$50 million
Attackers compromised multiple signers' devices and used a spoofed Safe transaction UI to obtain valid signatures for malicious calldata. Signers reported that the transactions "looked normal" in the Safe interface. Same root cause: trusting the rendering of a transaction over the bytes themselves.
DMM Bitcoin · ~$305 million
Private-key compromise of a wallet system that included Safe-managed cold storage. Not a contract bug, but illustrates that even hardened multisig setups can fail when the signing environment around them is complex enough to hide what's actually being approved.
ethmultisig does not eliminate signer-side compromise — nothing can. But it minimises every other layer, so that the only thing you need to verify is the calldata you sign. The contract above has no upgrade path, no module to enable, and no delegatecall for an attacker to redirect. The bytes you sign are the bytes that execute.
06Using your wallet after deploy
No special client needed. Any wallet that can send transactions can drive ethmultisig directly.
1. Deposit
Send ETH directly to the deployed contract address. The receive() function emits a Deposit event — that's it.
2. Propose
Any owner calls submit(to, value, data) with the destination, amount, and calldata. The proposer auto‑confirms.
3. Confirm
Other owners call confirm(txId) until confirmations ≥ threshold. Anyone can revoke(txId) their own confirmation before execution.
4. Execute
Once the threshold is reached, any owner calls execute(txId) and the wallet performs the call on‑chain. The transaction cannot replay — executed is flipped.
07FAQ
Has this contract been audited?
The pattern (m‑of‑n confirmations with submit/confirm/execute) has been deployed thousands of times since 2016 — ConsenSys, OpenZeppelin and others all ship versions of it. This page's contract is short enough that you can and should audit it yourself. Don't trust this site — read the source, test on Sepolia, then decide.
Why is the threshold fixed at deploy?
Because mutable thresholds and mutable owner sets are exactly what allowed several large multisig hacks to escalate. If an attacker controls one signer and a UI bug, they shouldn't also be able to lower the threshold to one. Immutable means deploy a new wallet to change the rules.
What if I lose a key?
If you still have ≥ threshold keys, your funds are safe; deploy a new multisig and move funds. If you drop below the threshold, the funds are stuck. Pick a threshold that gives you spare keys (e.g. 2‑of‑3, not 2‑of‑2).
Does it support ERC‑20 tokens?
Yes — the wallet can hold any token. To move tokens, propose a transaction where to is the token contract and data is the encoded transfer(recipient, amount) call. Same pattern works for any contract interaction.
Why on-chain confirmations instead of off-chain signatures?
Off-chain signatures are cheaper in gas but require a coordination service or a trusted UI to gather and submit them — another layer that can be attacked or rugged. On-chain confirmations cost more gas but require no external service. For wallets that hold significant value and transact rarely, gas is not the constraint.
Is this affiliated with the Ethereum Foundation, Safe, or anyone else?
No. This is an independent reference implementation. The code is MIT licensed — fork it, host it yourself, modify it. The deploy-via-Remix link goes to remix.ethereum.org, which is run by the Ethereum Foundation.