Multi-sig (multisignature) means distributing the right to spend funds across several keys, with the requirement that some of them co-sign. For teams, DAOs and serious individual savings on TON, it’s a baseline practice. This article covers how it works under the hood, how to deploy it, what configurations are sensible, and where the pitfalls are.
Why multi-sig
A single key is a single point of failure. Compromise the seed → lose all funds. Multi-sig removes that:
- Protection against single-device compromise. An attacker who gets one key cannot move funds.
- Protection against insider risk. No single team member can move funds alone.
- Protection against your own mistake. Lose one of your own keys — funds are still accessible through the rest.
- Transparency. Every operation requires explicit approval from a defined number of participants, all visible on-chain.
The trade-off — higher operational complexity and more time to gather signatures.
Multi-sig implementation in TON
In TON, multi-sig is a smart-contract wallet, not a separate protocol feature. The canonical implementation is multisig-contract-v2 by the TON Core team, version 2.0 from April 2024.
Audits
The contract has passed two independent audits:
- Zellic — report published in the repository.
- Trail of Bits — security review completed in March 2024.
Both audits confirmed the logic is correct; there are no publicly known vulnerabilities in the stable version.
Architecture
The contract stores:
- Signers list. Any TON address — a regular wallet, a Ledger account, another multi-sig, a smart contract.
- Proposers list (optional). Addresses that can propose orders but cannot vote on them.
- Threshold. Minimum number of signatures k required to execute an order.
- Wallet ID. Unique identifier so you can deploy several multi-sigs with the same set of keys.
Order lifecycle
- Creation (propose). Any signer or proposer creates an order: “send X TON to address Y, call Z”. The order is sent to the contract.
- Signature collection. Signers post their approvals via transactions to the contract. Each signature is recorded in the contract state.
- Expiry. If k signatures aren’t collected within the configured window (hours) — the order expires and cannot execute.
- Execution. Once k approvals are in — the order auto-executes (or can be triggered by any signer).
Configuration changes (add or remove a signer, change the threshold) are themselves orders requiring k signatures. That means you cannot quietly hijack a multi-sig — any change to the signer set is recorded on-chain.
Typical configurations
2-of-3 — for individuals
Three Ledger keys distributed geographically:
- Key A — at home.
- Key B — in a bank deposit box.
- Key C — with a lawyer or trusted partner.
Any two are enough to sign. Losing one is not critical. One compromised — also not critical.
Suitable for long-term storage of $50k–500k.
3-of-5 — for teams
Five signers, three required. Common layout:
- CEO,
- CFO,
- CTO,
- a trusted investor / advisor,
- a “secure resource” (a cold device in a deposit box).
This is “team plus insurance”. Any three can sign during normal operations, but no two can move funds.
2-of-2 — for paired control
Often used between two key figures with equal rights. Not fault-tolerant (losing one key permanently locks the funds), so it requires either an additional recovery key or extremely robust seed backup.
3-of-7 — for a DAO
Extended team with granular control. Harder to maintain — makes sense once a DAO treasury is above $1M.
Tools for multi-sig
multisig.ton.org
Web interface from the TON Foundation for creating and managing multi-sig contracts. Supports:
- contract deployment with chosen signers and threshold;
- order creation;
- signature collection via TON Connect;
- monitoring state and order history.
Suitable for most cases. Connection — through Tonkeeper or MyTonWallet.
Tonkeeper and MyTonWallet
There is no native in-wallet multi-sig management yet, but both work well as signers — through TON Connect to multisig.ton.org or other interfaces. Each signature shows up in the wallet’s UI as a regular transaction.
Self-hosted UI
Technical teams can stand up their own UI on top of the open multisig-contract-v2 source and the TON Foundation SDK. This gives full control over interface and logging behaviour, but requires engineering effort.
Tonkeeper as a multi-sig signer
Connects to multi-sig interfaces through TON Connect. Supports Ledger for an extra layer of protection.
→
Deploying a multi-sig: step by step
Suppose you want to deploy a 2-of-3 multi-sig across three Ledger accounts.
1. Key preparation
- Buy three Ledger Nano S Plus or X devices.
- Set each up separately (independent seed on each, stamped onto a steel plate).
- Install the TON app on each.
- Get the public address of each via Tonkeeper or MyTonWallet.
- Test transfer of $5 to each Ledger — confirm the devices work.
2. Contract deployment
- Open multisig.ton.org.
- Connect the wallet that will pay for deployment (~0.5–1 TON in gas).
- Enter the three signer addresses.
- Set threshold = 2.
- Optionally — set the Wallet ID, if multiple multi-sigs are planned.
- Confirm the deployment transaction.
- You’ll get the multi-sig address — public, ready to receive funds.
3. Testing
Don’t fund with the main amount right away.
- Send $50 to the multi-sig address.
- Create an order — send $10 to one of your own addresses.
- Sign with two of the three Ledgers.
- Confirm the order executed.
- Create a configuration-change order (e.g. temporarily change the threshold) and verify.
- Only after a full cycle — fund with the main amount.
4. Documentation
Write down:
- the multi-sig address;
- all signer addresses;
- who owns each key;
- threshold;
- key rotation procedure;
- recovery contacts for each signer.
Store this document somewhere safe and accessible to all signers. Without it, recovery during an incident becomes a nightmare.
!A test order is mandatory
Every time you change the signer set or threshold — run a test order on a minimal amount before doing anything with the main balance. Multi-sig is harder than a single-key wallet; configuration mistakes are usually discovered the moment you change configuration, not at initial deployment.
Use cases
Corporate treasury
A company holds operational treasury in TON / USDT-jetton. A 3-of-5 multi-sig across CEO, CFO, COO, advisor and a cold backup. Anything above a certain threshold goes through multi-sig; small operational expenses go through a capped single-key wallet.
DAO treasury
Community votes define orders, a multi-sig of delegates executes. Threshold is usually high (e.g. 5-of-7) to defend against collusion of a delegate subset.
Family treasury
Family wallet split across family members. Threshold tends to be low (e.g. 2-of-4 — two parents and two adult children), but with a documented inheritance path.
Project grant treasury
A project receives a grant from the TON Foundation into a 3-of-5 multi-sig that includes a foundation representative. Every spend is transparent and visible to donors.
Field log · 2025–2026Twice, a 2-of-3 multi-sig saved us from incidents. First — a phone with one of the keys turned out to be compromised by a phishing app; the attacker couldn’t push a single transaction because they didn’t have a second key. Second — a Ledger lost on a business trip; the wallet kept operating on the two remaining keys, the lost one was rotated out via the standard signer-change procedure.
— TON Adoption
Downsides and pitfalls
Operation speed
Collecting signatures takes hours or days in a distributed team. Multi-sig is not suitable for active DeFi — that needs a separate operational wallet with small caps.
Higher gas
Every multi-sig operation is more expensive than a regular transaction (gas for signature verification). For small transfers it’s overkill.
Usability
Every signer must understand the process and have an active wallet and device. In a team, somebody is always “didn’t sign in time”, blocking an urgent payment.
Recovery complexity
If a key is lost and the remaining count is below threshold — funds are locked forever. 2-of-2 without a recovery key is a time bomb. Always leave headroom on the threshold.
Version mismatch
Multisig-contract-v2 is the current standard. If you deploy old v1 — some tools may not support it. Use only v2 from TON Core, not custom forks.
Multi-sig vs a regular Ledger
| Scenario | Single Ledger | Multi-sig 2-of-3 |
|---|---|---|
| Single-phone protection | Sufficient | Overkill |
| Team protection | Not suitable | Ideal |
| Operation speed | Seconds | Hours–days |
| Gas cost | Low | High |
| Amount $5k–50k | Sufficient | Possibly overkill |
| Amount $50k+ | Minimum | Standard |
For more on cold storage broadly — TON cold storage: strategies and tools.
Bottom line
Multi-sig in TON in 2026 is mature technology. The multisig-contract-v2 contract has been audited, the infrastructure (multisig.ton.org, TON Connect, Ledger as a signer) works. For individuals, multi-sig makes sense from $50k–100k; for teams it’s the right tool from any meaningful corporate balance.
The main rule: always leave threshold headroom (never 2-of-2 without a recovery), always test orders before funding, always document the process.
Sources
- github.com/ton-blockchain/multisig-contract-v2 — multisig from the TON Core team.
- Audits by Zellic and Trail of Bits — reports in the repository.
- docs.ton.org — general TON documentation.
- multisig.ton.org — the official TON Foundation web UI.
Top comments (0)