← back to blog

Guide: Tax reporting for airdrop income across US, EU, UK, SG

Guide: Tax reporting for airdrop income across US, EU, UK, SG

Airdrops feel like free money until tax season arrives. if you’ve been farming across multiple wallets and chains, you’re sitting on a pile of taxable events that most crypto tax tools handle badly. the core problem is that different jurisdictions treat airdrop income differently: the IRS taxes it as ordinary income at fair market value on receipt, HMRC has a nuanced “beneficial ownership” test, IRAS in Singapore generally doesn’t tax capital gains but does care about trading income, and the EU has no unified rule so you’re at the mercy of whichever member state you’re resident in.

this guide is for operators who have already farmed airdrops and now need to figure out what to declare. you’ve probably got wallets spread across EVM chains, Solana, Aptos, maybe some Cosmos, and you received tokens from multiple protocols across multiple tax years. you’re not a CPA and neither am I. this is not legal or tax advice, consult a licensed tax professional in your jurisdiction before filing.

what you get out of this: a repeatable workflow for exporting transaction history, categorizing airdrop income, calculating fair market value at receipt, and generating reports that a tax preparer can actually use. i’ll cover the US, UK, EU (Germany and France as the two most common cases), and Singapore specifically.


what you need

  • wallet addresses: every address you’ve ever used to receive airdrops, exported as a list
  • a crypto tax tool: Koinly (plans start around $49/year for up to 100 transactions), CoinTracker, or Coinpanda are the main options. Koinly has the best multi-chain support as of 2026 and is what I use
  • exchange account CSV exports: Binance, Coinbase, Kraken, OKX, wherever you sold or converted tokens
  • price history source: CoinGecko historical prices or CryptoCompare for tokens not covered by your tax tool
  • a spreadsheet: Google Sheets or Excel for edge cases your tax tool misses
  • your jurisdiction’s tax year dates: US is Jan 1-Dec 31, UK is Apr 6-Apr 5, SG is Jan 1-Dec 31, Germany and France both Jan 1-Dec 31
  • optional: a block explorer API key (Etherscan, Solscan, Aptos Explorer) if you need raw transaction data

step by step

step 1: compile all wallet addresses

before you touch any tax tool, build a complete address inventory. missed addresses are the most common cause of gaps in your cost basis history.

# example format for your address list
ETH: 0xabc...123
ETH: 0xdef...456
SOL: 7abc...xyz
APT: 0x1a2b...

go through your browser wallet history, hardware wallet accounts, and any burner wallets you used for farming. if you used separate wallets per protocol, those all need to be in the list. check the airdropfarming.org blog for guides on wallet management strategies.

expected output: a flat text file with every address labeled by chain.

if it breaks: if you’ve lost track of some addresses, check your Discord DM history for wallet addresses you shared, and review any protocol dashboards that show your connected wallets.

step 2: import addresses into Koinly (or your chosen tool)

add each wallet as a separate portfolio in Koinly. the tool will automatically fetch transaction history from on-chain data via public APIs. for EVM chains this works well. for Solana, Aptos, and some Cosmos chains you may need to manually upload CSV exports.

for each wallet, set the correct creation date so the tool doesn’t waste time scanning empty history.

expected output: Koinly populates transaction history with deposits, withdrawals, swaps, and receives.

if it breaks: Koinly sometimes misclassifies airdrops as “unknown” income. you’ll fix this in step 4.

step 3: export and upload exchange history

download CSV exports from every exchange you used. in Binance, this is under Account > Order History > Export. in Coinbase it’s under Taxes > Download. upload these directly into Koinly.

this step matters because if you received an airdrop and then sold on Binance, the tax tool needs to match the cost basis from the airdrop receipt to the sale. without exchange history, it can’t calculate gains correctly.

expected output: exchange trades appear in the transaction timeline alongside on-chain events.

if it breaks: Koinly’s Binance importer occasionally drops rows from large exports. cross-check total trade count against the exchange’s native history view.

step 4: tag all airdrop transactions

this is the most manual part. filter your transaction list to show only “receive” events and go through them to tag each one as “airdrop” rather than generic income. most tools treat tagged airdrops differently for reporting purposes.

for each airdrop transaction you need: the token, the quantity received, the fair market value in your local fiat at the exact date and time of receipt. Koinly pulls prices automatically for major tokens but for small-cap or newly-launched tokens you’ll need to input the price manually from CoinGecko’s historical data.

# CoinGecko historical price API (free tier)
# example for fetching a token price on a specific date
https://api.coingecko.com/api/v3/coins/{id}/history?date={dd-mm-yyyy}&localization=false

expected output: every airdrop is tagged with the correct income category and a verified fair market value.

if it breaks: if a token doesn’t exist on CoinGecko, check DEX price history on Dexscreener or GeckoTerminal. document your source in a notes column for the tax preparer.

step 5: apply jurisdiction-specific income treatment

this is where the workflows diverge by country.

United States: per IRS FAQ on virtual currency transactions, airdrops are ordinary income at FMV on the date received. that income flows to Schedule 1 (Form 1040). when you later sell the tokens, the cost basis is that FMV, and the gain or loss is capital (short-term if held under 12 months, long-term if over). Koinly’s US tax report generates a Form 8949 CSV you can hand to a CPA.

United Kingdom: HMRC’s Cryptoassets Manual at CRYPTO21250 distinguishes between airdrops received in return for services (taxable as income) and airdrops received without any action (often treated as capital with a zero-cost basis). if you did tasks like bridging, trading, or providing liquidity to qualify for the airdrop, HMRC is likely to treat it as income. Koinly generates a Capital Gains Summary report for the UK tax year.

EU (Germany and France): Germany is relatively favorable for long-term holders. tokens held over 12 months are tax-free on sale, but income tax applies at receipt if you received airdrop rewards in connection with staking or activity. France taxes crypto gains at a 30% flat rate (the PFU). neither country has issued specific guidance on airdrops equivalent to HMRC’s manual, so you’re working from general income tax principles. a local steuerberater or expert-comptable is worth the cost here.

Singapore: IRAS guidance on Digital Payment Tokens takes the position that gains from sale of digital tokens are generally not taxable if they are capital in nature. however, if you’re systematically farming airdrops as a trading activity, IRAS may treat income as arising from a trade, which is taxable. the line between investor and trader isn’t drawn in a bright place. as a Singapore operator, I keep records of intent at acquisition and the frequency and volume of activity.

expected output: your tax tool report reflects the correct income and gain/loss treatment for your jurisdiction.

if it breaks: if your tax tool doesn’t have a jurisdiction-specific report, export the raw transaction CSV and have your accountant manually sort income versus capital events.

step 6: reconcile and verify totals

before exporting the final report, check three things. first, does the total income figure match a rough manual calculation? take the top 5 airdrops by value and verify the per-token income makes sense. second, are there any transactions flagged as “missing purchase history”? these will show up as 100% gains and inflate your tax liability. third, do your ending wallet balances in the tool match your actual on-chain balances?

expected output: a clean transaction set with no unresolved warnings.

if it breaks: missing purchase history often comes from tokens bridged across chains where the tool loses the trail. you’ll need to manually add a cost basis transfer entry.

step 7: export reports and hand off to a tax preparer

export the jurisdiction-specific reports as PDF and CSV. for the US this is the Form 8949 CSV plus income summary. for the UK it’s the capital gains summary. for Singapore and Germany/France, the raw income and disposal records.

if you’re running significant volume, it’s worth having a crypto-specialist accountant review the output before filing. the cost is usually $200-$1000 depending on complexity and is deductible as a professional expense in most jurisdictions.

expected output: completed tax filings or handoff documents ready for a professional review.

if it breaks: if your tax tool export doesn’t match what your accountant needs, export the raw CSV and provide documentation of your tagging methodology.


common pitfalls

treating all airdrops as zero-cost capital gains. a number of operators skip the income recognition step and only report on the eventual sale. this is incorrect in the US and UK. if you received tokens worth $2,000 at airdrop and sold for $500, you have $2,000 of ordinary income and a $1,500 capital loss, not a $500 gain.

forgetting tokens that went to near-zero. worthless or near-worthless tokens still had FMV at receipt. if you received 10,000 units of a token at $0.05 each, that’s $500 of income you need to declare even if you never sold and it’s now worth $0.001.

missing wallets used for farming. the most common audit trigger in crypto is unreported income from wallets you forgot to include. if you’re managing multiple wallets across protocols, the approach at multiaccountops.com/blog/ has good material on keeping an organized wallet inventory.

using the wrong FMV date. some protocols snapshot eligibility weeks before the actual token distribution. the taxable date is the date you could actually claim the tokens, not the snapshot date. for many protocols, this is the date you executed the claim transaction on-chain.

ignoring cross-chain complexity. bridging an airdropped token to another chain for a swap is itself a taxable disposal in some jurisdictions. the bridge transaction record needs to be in your tax tool, not just the eventual trade.


scaling this

10 wallets: everything above works fine. manual review of airdrop tags is tedious but doable in a few hours.

100 wallets: at this scale you need to automate the wallet import. Koinly’s API lets you add wallets programmatically. build a script that reads your address inventory file and posts each wallet via the API. set up a scheduled run at the start of each tax year. for tracking wallet activity at scale before tax time, see our guide on how to track wallet activity across chains.

1000 wallets: at this volume you’re likely operating as a professional and the income treatment changes in most jurisdictions. you’re also generating enough in fees for a full-service crypto accounting firm to be cost-effective. Lukka and TaxBit Enterprise both offer bulk processing. the data pipeline becomes the problem: you need reliable on-chain data exports for every chain you operate on, and Etherscan/Solscan rate limits become a bottleneck. invest in a proper indexer or use a data provider like Transpose or Allium for bulk transaction pulls.


where to go next


Written by Xavier Fok

disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-05-19.

need infra for this today?