DEV Community: Huzaifa Zahoor

Before You Paste That Wallet Address: Sanity-Checking Crypto Addresses in Python

Huzaifa Zahoor — Sun, 11 Oct 2026 08:49:26 +0000

Every crypto transfer ends with the same scary moment: you paste a long string into a "recipient" box and press send. There's no chargeback and no support line that can reverse it. If the string is wrong, or right but on the wrong network, the money is usually gone.

As developers we can make that moment a lot less scary. This post walks through what a wallet address actually is and a few cheap checks you can run in code before trusting one.

What an address really is

A wallet address is a public identifier that can receive coins. It sits at the end of a one-way chain:

Private key: a secret number that signs transactions. Whoever holds it controls the funds.
Public key: derived from the private key, used by the network to verify signatures.
Address: a shorter encoding, usually a hash of the public key, built for sharing.

Because every step only works in one direction, sharing an address is safe. Sharing the private key or the seed phrase behind it is not. If you want the beginner-friendly version of all this, NutshellCrypto has a clear explainer on what a crypto wallet address is and how to use one safely.

Formats give you free validation

Different chains use different encodings, and most of them carry a checksum. That means a single typo is usually detectable before anything touches the network.

Chain	Looks like	Built-in check
Bitcoin SegWit / Taproot	`bc1q...` / `bc1p...`	Bech32 / Bech32m checksum
Bitcoin legacy	`1...` / `3...`	Base58Check
Ethereum and EVM chains	`0x` + 40 hex chars	EIP-55 mixed-case checksum
Solana	32-44 base58 chars	Must decode to 32 bytes

A quick EIP-55 check

Ethereum addresses encode a checksum in the capitalization of their letters. Here's a minimal validator using pycryptodome for Keccak-256:

from Crypto.Hash import keccak

def is_valid_eip55(addr: str) -> bool:
    if not (addr.startswith("0x") and len(addr) == 42):
        return False
    body = addr[2:]
    try:
        int(body, 16)
    except ValueError:
        return False
    if body.islower() or body.isupper():
        return True  # no checksum present, format only
    h = keccak.new(digest_bits=256, data=body.lower().encode()).hexdigest()
    for ch, nibble in zip(body, h):
        if ch.isalpha() and (int(nibble, 16) >= 8) != ch.isupper():
            return False
    return True

An all-lowercase address passes the format check but carries no checksum, so treat it as "weaker" and confirm it another way. For Bitcoin, use a maintained library (for example the reference segwit_addr.py from BIP 173/350) rather than rolling your own bech32 decoder.

The check code can't do: the network

Here's the trap that a checksum won't catch. The same 0x... address is valid on Ethereum, Arbitrum, Base, Polygon, and BNB Chain. The string is identical, but the networks are separate ledgers. Send USDT on one chain to an exchange deposit that only credits another, and you may end up with a lost or stuck deposit.

So if you build anything that moves funds, make the network an explicit, required field next to the address, never something inferred from the address alone. Also watch for assets like XRP that need a destination tag or memo for exchange deposits.

Habits worth automating

A few things from the security side:

Clipboard hijackers swap a copied address for the attacker's. Compare the first and last several characters after pasting, every time.
Address poisoning scams send you tiny transfers from look-alike addresses, hoping you'll copy one from your history later. Keep an allowlist or address book instead of copying from past transactions.
Hardware wallets let you confirm the receiving address on the device screen, which beats trusting a possibly compromised computer.
Test transfers: send a small amount first on a new route, then the rest.
Privacy: addresses and balances are public on most chains. Anyone with your address can look at its history.

Takeaways

An address is public and safe to share; private keys and seed phrases are not.
Most address formats include a checksum, so validate it in code before sending.
A valid address on the wrong network is still a costly mistake; make the network explicit.
Defend against clipboard malware and address poisoning with visual checks and allowlists.
Do a small test transfer when in doubt.

For the full walkthrough, including how to find your address on exchanges and self-custody wallets, plus common mistakes and an FAQ: Read the full guide on NutshellCrypto.

This is educational content, not financial advice.

This post was written with AI assistance.

Your Seed Phrase Is Just 128 Bits With a Checksum: BIP-39 Explained for Developers

Huzaifa Zahoor — Sat, 10 Oct 2026 08:41:23 +0000

If you have ever set up a self-custody crypto wallet, you have seen it: a screen with 12 or 24 plain English words and a stern warning to write them down. As developers we tend to treat that list like a password. It isn't. It is an encoding of raw entropy, and once you see how it is built, the security rules around it stop feeling like superstition.

What the words actually encode

Most wallets follow a standard called BIP-39. The recipe is short:

Generate random entropy: 128 bits for 12 words, 256 bits for 24.
Hash it with SHA-256 and append the first few bits of the hash as a checksum (4 bits for 128-bit entropy, 8 bits for 256).
Split the result into 11-bit chunks. Each chunk is an index into a fixed list of 2,048 words.

That's it. 132 bits / 11 = 12 words. 264 bits / 11 = 24 words. The words are just a human-friendly serialization, and the checksum is why your wallet can tell you when you mistyped one.

A tiny Python demo (toy data only)

Here is the entropy-to-indices step, so you can see the mechanics. Never run anything like this with a real phrase, and never paste a real phrase into any script, website, or chat.

import hashlib, secrets

entropy = secrets.token_bytes(16)          # 128 bits -> 12 words
h = hashlib.sha256(entropy).digest()
cs_bits = len(entropy) * 8 // 32           # 4-bit checksum

bits = bin(int.from_bytes(entropy, "big"))[2:].zfill(len(entropy) * 8)
bits += bin(h[0])[2:].zfill(8)[:cs_bits]

indices = [int(bits[i:i + 11], 2) for i in range(0, len(bits), 11)]
print(indices)  # 12 numbers in 0..2047, each maps to one BIP-39 word

Map those indices to the official wordlist and you have a valid mnemonic. A real wallet then runs the words (plus an optional passphrase) through PBKDF2 to get a 512-bit seed, and derives a whole tree of keys from it using BIP-32. One seed, unlimited addresses, which is why one backup covers everything.

Seed phrase vs private key vs PIN

A quick mental model:

PIN / password: a local lock on one device. Resettable.
Private key: controls one address. Not resettable.
Seed phrase: generates every key in the wallet. Not resettable. Whoever has it owns the funds.

The PIN protects the device; the seed phrase is the wallet. NutshellCrypto has a clear breakdown of this in its guide on what a seed phrase is and how to store it safely.

12 or 24 words?

128 bits is already far beyond brute-force range. For most people the threat model isn't guessing; it is phishing, malware, cloud backups, and plain loss. Use whatever your wallet generates and spend your effort on storage.

The optional passphrase ("25th word")

BIP-39 lets you add a passphrase that is mixed into the PBKDF2 step. Same words plus a different passphrase gives a completely different wallet. That's useful against someone who finds your written words, but it adds a second secret you can lose, and there is no recovery if you forget it.

Thinking about storage like an engineer

Treat the phrase as an offline root secret:

Never digitize it. No screenshots, notes apps, password managers synced to the cloud, or photos. Your threat surface is every device that ever touched it.
Plan for physical failure. Paper burns and fades; metal backup plates survive fire and water better.
Avoid single points of failure. Consider more than one copy in separate secure places, weighing theft risk against loss risk.
Test recovery with a small amount before trusting a wallet with more.
Assume any prompt asking for it is a scam. No legitimate support team, airdrop, or "wallet sync" site needs your words.

Takeaways

A seed phrase is 128 or 256 bits of entropy plus a checksum, encoded as words.
It derives every key in your wallet; losing it, or leaking it, is final.
Words beat brute force easily; humans and malware are the real attack surface.
Keep it offline, durable, redundant, and never typed into a website.

For storage options, common scams, and what to do if you lose your phrase, read the full guide on NutshellCrypto.

Not financial advice; this post is for education only.

This post was written with AI assistance.

That 'Free Money' Crypto Price Gap Usually Isn't: Checking an Arbitrage Spread in Python

Huzaifa Zahoor — Fri, 09 Oct 2026 08:49:53 +0000

If you've ever pulled ticker data from two crypto exchanges at once, you've probably seen it: the same coin quoted at slightly different prices. Buy low here, sell high there, pocket the difference. That's crypto arbitrage, and on paper it looks like the one trade that doesn't care which way the market moves.

As developers, we're good at spotting a gap in two JSON responses. We're less good, at first, at counting everything that sits between that gap and an actual profit. This post walks through why prices drift apart, the main flavors of arbitrage, and a small Python check that shows how quickly a "spread" disappears once you model real costs.

For the non-code version with tax notes for the US and Canada, see this plain-English guide to crypto arbitrage.

Why the same coin has different prices

There's no single official bitcoin price. Every centralized exchange runs its own order book, so prices drift because of:

Local demand: a buying burst on one venue pushes its price up for a while.
Liquidity: thin order books move more per trade.
Capital rules: South Korea's well-known "kimchi premium" survived for years partly because moving money in and out is hard.
Transfer friction: deposits and withdrawals take time and cost fees, which is exactly what keeps gaps alive.

That last point matters: the friction that creates the gap is the same friction that eats your profit.

The main types

Cross-exchange: buy on A, sell on B. Serious traders pre-fund both sides so they never wait on a transfer.
Triangular: loop through three pairs on one exchange (USD to BTC to ETH to USD). Gaps last seconds; this is bot territory.
Funding-rate (cash-and-carry): hold spot, short an equal perpetual future, collect funding while the rate is positive. The rate can flip, and the short can get liquidated.
DEX arbitrage: buy and sell across liquidity pools in one atomic transaction. It's the most competitive form of MEV, and searchers often hand most of the profit to block builders to win ordering.

Modeling the real spread

Here's a deliberately simple check. It takes the two quoted prices and subtracts taker fees, a withdrawal fee, and an allowance for slippage and price movement during the transfer.

def net_arbitrage(buy_price, sell_price, amount,
                  taker_fee=0.001,         # 0.1% per side
                  withdrawal_fee_coin=0.0002,
                  slippage=0.0005,         # 0.05% per side
                  drift=0.002):            # price move while transferring
    cost = buy_price * amount * (1 + taker_fee + slippage)
    coins_arriving = amount - withdrawal_fee_coin
    effective_sell = sell_price * (1 - drift)
    proceeds = effective_sell * coins_arriving * (1 - taker_fee - slippage)
    return proceeds - cost

gross_gap = 60_300 - 60_000
print("Gross gap per BTC:", gross_gap)
print("Net result for 0.1 BTC:", round(net_arbitrage(60_000, 60_300, 0.1), 2))

A 0.5% gap looks attractive. With the example assumptions above, the result for 0.1 BTC comes out negative. Swap in your own numbers: the point isn't these exact values, it's that every term is a percentage that stacks, and the gross gap has to beat all of them and still exist when both legs finish.

Things the toy model leaves out, which make it harder in real life:

Order book depth (the quoted price only covers the first slice of size).
Withdrawal queues, network congestion, and exchange maintenance windows.
Counterparty risk: your pre-funded balance sits on someone else's platform.
Taxes: every leg can be a taxable disposal.

The security angle: arbitrage bot scams

"Guaranteed arbitrage bot" offers are a classic scam pattern. Red flags worth treating like a failing test:

Fixed daily returns or "risk-free" promises.
You must deposit to their platform or wallet to "activate" the bot.
Withdrawals require an extra "fee" or "tax" first.
Pressure to recruit friends for bonuses.

If the code really printed money reliably, nobody would sell it to you for a subscription.

Takeaways

Price gaps between exchanges are real but usually small and short-lived.
Fees, slippage, transfer time, and drift often turn a gross gap into a net loss.
Most practical arbitrage is automated, pre-funded, and highly competitive.
Treat any "guaranteed" arbitrage product as a likely scam.
Model costs before you trust a spread you saw in an API response.

The full breakdown, including a worked example, scam warning signs, and how arbitrage is taxed in the US and Canada, is in Crypto Arbitrage Explained on NutshellCrypto.

Read the full guide on NutshellCrypto

This is educational content, not financial advice.

This post was written with AI assistance.

Your Crypto Buy Has Four Fees, Not One: Modeling the All-In Cost in Python

Huzaifa Zahoor — Thu, 08 Oct 2026 08:44:20 +0000

If you've ever compared two exchanges by their headline trading fee, you were probably comparing the wrong number. A crypto buy usually carries several costs at once: a funding fee for getting cash in, a trading fee or a spread on the trade itself, and a network fee when you move coins out. Only some of them show up as a line item.

As developers, we already know how to handle this kind of problem: model every component, then sum them. This post does exactly that, with a small Python function you can adapt. For the full breakdown of each fee type, with numbers from the official fee pages, see this plain-English guide to crypto exchange fees (maker, taker, spread and withdrawal).

The fee stack, as a data model

Think of one purchase as a pipeline with up to four cost stages:

Funding. Adding cash by bank transfer is often free; cards and PayPal can cost a few percent of the amount.
Trading. On an order-book ("advanced" or "pro") screen you pay a maker or taker percentage. On a simple "Buy" button you usually pay a convenience fee plus a spread baked into the quoted price.
Conversion. Trading in a different currency than you funded in (say CAD into a USD pair) can add an FX fee.
Withdrawal. Sending coins to your own wallet costs a network fee, sometimes plus a platform processing fee.

The spread is the sneaky one. It's the gap between the buy and sell price, so it never appears on your receipt as a "fee". It just makes the price you're quoted a little worse.

Maker vs taker in one paragraph

If your order fills immediately against an order already on the book, you're the taker and pay the higher rate. If your order rests on the book until someone else fills it, you're the maker and pay less. Market orders always take. A limit order placed away from the current price usually makes. A partially filled limit order can be charged both: taker on the part that matched right away, maker on the rest.

Model it in Python

Here's a small function that turns a fee schedule into an all-in cost. Every number in it is a parameter, because fee schedules change and differ by tier, region, and payment method. Always plug in the current figures from your own exchange's fee page.

def all_in_cost(amount, trade_fee_pct=0.0, spread_pct=0.0,
                funding_fee_pct=0.0, fx_fee_pct=0.0, network_fee=0.0):
    """Approximate total cost of buying `amount` worth of crypto
    and withdrawing it. Percentages are given as decimals."""
    funding = amount * funding_fee_pct
    trading = amount * trade_fee_pct
    spread = amount * spread_pct
    fx = amount * fx_fee_pct
    total = funding + trading + spread + fx + network_fee
    return round(total, 2), round(total / amount * 100, 2)

# Example inputs only; check your exchange's current schedule.
scenarios = {
    "advanced, resting limit (maker)": dict(trade_fee_pct=0.004),
    "advanced, market order (taker)":  dict(trade_fee_pct=0.008),
    "simple buy + spread":             dict(trade_fee_pct=0.01, spread_pct=0.005),
    "taker + debit card funding":      dict(trade_fee_pct=0.012, funding_fee_pct=0.0349),
}

for name, fees in scenarios.items():
    cost, pct = all_in_cost(1_000, network_fee=2.0, **fees)
    print(f"{name:34} ${cost:>6}  ({pct}%)")

The example rates mirror figures the NutshellCrypto guide pulled from public fee pages on October 8, 2026, while the 0.5% spread and $2 network fee are assumptions, since exchanges don't publish fixed values for those. Even with made-up extras, the pattern is obvious: the payment method and the button you press can matter more than which exchange you pick.

Why this matters more for recurring buys

A one-off purchase hides small differences. A weekly recurring buy multiplies them. If you're running a dollar-cost averaging plan, the fee stage repeats every single interval, and selling later charges you again.

That's a good reason to run your own numbers before automating anything. The free crypto DCA calculator on NutshellCrypto lets you play with amounts and schedules, and you can apply the fee model above to each buy to see how much of your plan goes to costs.

Practical ways to pay less

Fund by bank transfer (ACH in the US, Interac e-Transfer in Canada) instead of a card.
Use limit orders on the advanced screen if you're comfortable with them, so you pay the maker rate.
Batch withdrawals. Network fees are charged per transaction, so one larger transfer beats many small ones.
Avoid needless conversions, such as funding in one currency and trading a pair in another.
Send a small test amount first, and double-check you picked the right network.
Log your fees. They can affect your cost basis at tax time, so export them with your trade history.

Takeaways

A crypto buy has up to four cost stages: funding, trading or spread, conversion, and withdrawal.
The spread is a real cost even though it never appears as a line item.
Takers pay more than makers; market orders always take.
Recurring buys repeat every fee, so model the all-in cost before you automate.
Keep the numbers as parameters and refresh them from the official fee page.

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.

Treat Your Crypto Wallet Like a Dependency: Licenses, Reproducible Builds, and gpg --verify

Huzaifa Zahoor — Wed, 07 Oct 2026 08:41:46 +0000

Most developers wouldn't deploy a dependency without glancing at its license, its repo activity, and whether the release artifact is what it claims to be. Yet plenty of us install a crypto wallet, the one piece of software that holds our private keys, straight from a search result.

This post treats a wallet like any other dependency in your supply chain: what "open source" actually buys you, where it stops helping, and how to check a download yourself. For the beginner-friendly version with a wallet-by-wallet breakdown, see this guide to what an open source crypto wallet really means.

"The code is on GitHub" is not the same as open source

The Open Source Initiative's definition requires more than public code. The license has to allow redistribution and modified versions, and it can't restrict use in a particular field, such as commercial use.

That distinction matters in practice. A wallet can publish every line of its code and still use a custom license that limits reuse to non-commercial projects. That's source-available: you can read and review it, but it doesn't meet the open source definition. Readable code is still useful for auditing, so treat this as a label to get right, not a red flag on its own.

Your first check is the same one you'd run on a library:

Find the repo by following the link from the wallet's official website, not from an ad.
Open LICENSE, LICENCE, or COPYING. MIT, Apache 2.0, and GPL are standard open source licenses. Phrases like "non-commercial" mean source-available.
Confirm the license covers the actual app, not just a few helper libraries. Some vendors open-source components and keep the core closed.

Public code only helps if the binary matches it

Here's the gap most people miss: you almost never run the source. You run a binary someone else built. If that binary was built from different code, the public repo tells you nothing.

Reproducible builds close that gap. A build is reproducible when anyone with the same source, build environment, and instructions can produce bit-for-bit identical output. Independent builders can then confirm that the release on the download page really came from the published code. Some well-known Bitcoin wallets document reproducible build processes, and independent projects like WalletScrutiny try to check whether wallet binaries match their public code.

If a wallet's docs say nothing about reproducible builds, that's worth noting when you compare options.

Verify the download yourself

Many desktop wallets publish a signed checksum file next to each release. Verifying it takes a few minutes:

Download the installer and the signature or checksum file from the official site only.
Import the developer's public PGP key from the source the project names.
Run gpg --verify on the signature to confirm the checksum list was signed by that key.
Hash your installer and confirm it appears in the signed list.

Step 4 is easy to script. Here's a small Python helper that hashes a file and looks for it in a SHA256SUMS-style file:

import hashlib
import sys
from pathlib import Path


def sha256_of(path: Path) -> str:
    h = hashlib.sha256()
    with path.open("rb") as f:
        for chunk in iter(lambda: f.read(1 << 20), b""):
            h.update(chunk)
    return h.hexdigest()


def check(installer: str, sums_file: str) -> bool:
    digest = sha256_of(Path(installer))
    name = Path(installer).name
    for line in Path(sums_file).read_text().splitlines():
        parts = line.split()
        if len(parts) >= 2 and parts[-1].lstrip("*") == name:
            return parts[0].lower() == digest
    raise SystemExit(f"{name} not listed in {sums_file}")


if __name__ == "__main__":
    ok = check(sys.argv[1], sys.argv[2])
    print("MATCH" if ok else "MISMATCH, do not install")

Only trust the result after gpg --verify has passed on the sums file. An attacker who can swap your installer can swap an unsigned checksum file too. If anything fails, don't install.

For mobile apps, open the store listing from the wallet's official website and check that the publisher name matches the real company.

Where open source stops protecting you

Open source is a strong signal, not a guarantee:

Public isn't the same as reviewed. On smaller projects, few people may actually read the code.
Supply-chain attacks still happen. In December 2023, a compromised npm account was used to publish malicious versions of an open-source Ledger library that dApps depended on. Pin your dependencies and watch your lockfiles.
Open code is easy to clone. Scammers copy wallet names, icons, and UIs and push fake apps through app stores.
You're still the last line of defense. No audit saves a seed phrase typed into a phishing site.

Takeaways

Check the license: open source and source-available are different things.
Public code only matters if the binary you run was built from it, which is what reproducible builds are for.
Verify signatures with gpg --verify before trusting any checksum match.
Get the download link from the official website, never from an ad.
Test any new wallet with a small amount before moving more.

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.

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.