DEV Community: Huzaifa Zahoor

Multisig Wallets for Developers: Thinking in m-of-n Before You Trust One Key

Huzaifa Zahoor — Tue, 06 Oct 2026 08:44:05 +0000

A single private key is a single point of failure. If you've ever run a system with one database and no replica, you already know the feeling. Multisig wallets apply a familiar fix: spread control across several independent keys and require a quorum before anything happens.

This post looks at multisig the way you'd look at any distributed system: thresholds, failure modes, and the state you must not lose. For the full beginner walkthrough, including use cases and an MPC comparison, see this plain-English guide to multisig wallets.

m-of-n is a threshold policy

A multisig wallet is described as m-of-n: n keys exist, and any m of them must sign before funds move. A 2-of-3 wallet has three keys and needs two signatures.

That gives you two tolerances to reason about:

Theft tolerance: an attacker needs m keys, so up to m - 1 stolen keys can't move funds.
Loss tolerance: you only need m keys to spend, so you can lose up to n - m keys and still recover.

Here's a tiny script that prints both for common setups:

def tolerances(m: int, n: int) -> dict:
    if not 1 <= m <= n:
        raise ValueError("need 1 <= m <= n")
    return {
        "setup": f"{m}-of-{n}",
        "stolen_keys_survivable": m - 1,
        "lost_keys_survivable": n - m,
    }

for m, n in [(1, 2), (2, 2), (2, 3), (3, 5)]:
    print(tolerances(m, n))

The output tells the story quickly. 1-of-2 survives a lost key but not a stolen one. 2-of-2 is the reverse: one stolen key is harmless, but one lost key locks the funds. 2-of-3 survives either one lost key or one stolen key, which is why it's the usual starting point for personal cold storage. 3-of-5 survives two of either, at the cost of managing five devices.

How signing actually flows

On Bitcoin, multisig is built into the script system. BIP 11 and BIP 16 standardized it years ago, and Taproot added the OP_CHECKSIGADD opcode for multisig policies (BIP 342). The day-to-day workflow uses PSBTs, Partially Signed Bitcoin Transactions (BIP 174). One device builds the transaction, it gets passed around (often as a file or QR code to an offline signer), each signer adds a signature, and once m signatures are attached it can be broadcast.

On Ethereum, an ordinary account is controlled by one key, so multisig lives in a smart contract instead. Safe is the best-known example: the contract stores a list of owners and a confirmation threshold, and only executes a transaction once enough owners approve. That makes things like rotating owners possible, but it also means the contract code is part of what you trust, and deploying it costs gas.

The state you must back up

This is the part people miss. On Bitcoin, seed phrases alone may not be enough to rebuild a multisig wallet. You also need the wallet configuration, usually called the output descriptor, which records which public keys are involved and what the threshold is. Lose it and recovery gets much harder, even if you still hold enough seeds.

A sensible backup checklist:

Each seed phrase stored separately, ideally on hardware wallets from different vendors.
The wallet descriptor or configuration file, copied to several places.
Plain-language instructions for whoever might need to recover the funds later.

Trade-offs worth naming

Multisig removes the single key as a failure point, but it adds others:

Complexity. More devices, more backups, more locations. Complexity is where humans make mistakes.
Coordinator software. The app that builds addresses and collects signatures matters. Prefer well-known, open-source tools that let you export your setup and move elsewhere.
Fees. Spending from a Bitcoin multisig usually costs more than single-sig, and bigger quorums cost more.
Overkill for small balances. For everyday amounts, a single-sig hardware wallet is usually the simpler choice.

MPC wallets are a related option. They split one key into shares and produce a single signature off-chain, while multisig uses independent keys whose approvals are checked on-chain. Different trust model, similar goal.

Test before you trust it

Treat a new multisig like a staging deploy. Receive a small amount, then spend it by signing with two different keys. Only move anything that matters once that round trip works.

Takeaways

m-of-n means you survive up to m - 1 stolen keys and up to n - m lost keys.
2-of-3 is the common default because it tolerates one lost or one stolen key.
On Bitcoin, back up the descriptor, not just the seeds.
On Ethereum, multisig is a smart contract, so its code joins your trust base.
Always do a small test spend before trusting a setup with real funds.

Read the full guide on NutshellCrypto

This is educational content only, not financial or investment advice. Crypto is volatile and you can lose money.

This post was written with AI assistance.

Crypto Tax Loss Harvesting for Developers: Find Your Losing Lots with a Few Lines of Python

Huzaifa Zahoor — Mon, 05 Oct 2026 08:44:06 +0000

If you hold crypto and you write code, tax season is mostly a data problem. Which coins did you buy, when, at what price, and which of those lots are worth less today? Answer that cleanly and one of the more useful year-end moves, tax loss harvesting, gets a lot less scary.

This post walks through the idea in plain terms and then shows a tiny script for spotting harvestable losses in your own records. For the full rules, limits, and a worked example, see this guide to crypto tax loss harvesting in the US.

The idea in one paragraph

In the US, the IRS treats crypto as property. When you sell, swap, or spend it, you realize a gain or loss: what you got minus your cost basis. A coin that is down on paper gives you nothing to deduct. Harvesting means deliberately realizing that loss, usually by selling, so it offsets gains elsewhere. Losses beyond your gains can reduce up to $3,000 of ordinary income a year ($1,500 if married filing separately), and the rest carries forward to later years.

Two details trip people up:

Crypto-to-crypto swaps count as disposals. Swapping one token for another can realize a loss (or a gain) just like selling for dollars.
It mostly defers tax. If you buy back in, your new basis is lower, so a later sale may show a bigger gain.

Why this is really a data problem

Which units you sell decides how big your loss is. IRS FAQs allow specific identification of units at the time of sale, or a standing order with your broker; otherwise a wallet-by-wallet first-in, first-out default applies. So if you bought the same coin at three different prices, selling the most expensive lot first gives the biggest harvestable loss.

That only works if your lot data is trustworthy. The classic failure point is wallet-to-wallet transfers, where cost basis quietly goes missing. Brokers now report on Form 1099-DA, but for 2026 and later basis is generally reported only for coins bought after 2025 and kept with that same broker. Coins moved in from elsewhere can show up with no basis at all, and self-custody or DeFi activity still has to be reported by you.

A minimal lot scanner

Here's a small sketch. Export your buys to a CSV with asset,date,qty,cost_usd columns, plug in current prices, and it lists every lot that is under water, sorted by the size of the loss, with a short-term or long-term flag.

import csv
from datetime import date

prices = {"ETH": 2400.0, "SOL": 120.0}  # fill in current prices yourself
today = date.today()

rows = []
with open("lots.csv") as f:
    for r in csv.DictReader(f):
        qty, cost = float(r["qty"]), float(r["cost_usd"])
        bought = date.fromisoformat(r["date"])
        value = qty * prices[r["asset"]]
        pnl = value - cost
        if pnl < 0:
            term = "long" if (today - bought).days > 365 else "short"
            rows.append((pnl, r["asset"], r["date"], term))

for pnl, asset, bought, term in sorted(rows):
    print(f"{asset:<5} bought {bought}  {term}-term  unrealized {pnl:,.2f} USD")

The prices above are placeholders, not real quotes. The holding-period flag matters because short-term losses (held a year or less) offset short-term gains first, and long-term losses offset long-term gains first, before crossing over. The day count is a rough cut, so check edge cases against your own records.

The wash-sale question, carefully

For stocks, the wash-sale rule blocks a loss if you buy back substantially identical securities within 30 days. As of October 5, 2026, that rule covers stock and securities, and ordinary crypto held directly like bitcoin or ether generally isn't caught by it. Spot crypto ETF shares are different: treat them as covered.

There's a catch worth knowing. A bill introduced in September 2026, H.R. 10357, would extend the rule to traded digital assets for sales after September 14, 2026, if it is enacted as written. It has cleared a House committee but isn't law. So "sell and immediately rebuy" now carries real uncertainty. The full guide covers where that bill stands.

Takeaways

Losses only count once realized, and the sale has to happen in the tax year you want the loss in, which for most people means by December 31.
Your edge is clean data: dated lots, amounts, and dollar values, especially across wallet transfers.
Check your exchange's cost-basis or lot-selection settings before you sell.
Don't sell just for the tax break; fees, spreads, and a bad investment call can outweigh the saving.
Canada works differently, with a superficial loss rule and no $3,000-style income deduction.

Read the full guide on NutshellCrypto

This is educational content, not tax or financial advice. Tax rules and pending legislation change, so check current IRS guidance or a tax professional before acting.

This post was written with AI assistance.