Crypto tax CSVs: cost basis, Form 8949, FIFO

glnc does NOT compute ordinary income from staking rewards, airdrops, hard forks, mining, or lending interest. These are taxable as ordinary income at fair market value on receipt (Rev. Rul. 2019-24, Rev. Rul. 2023-14). glnc records each potential inbound as a zero-cost-basis lot and surfaces the USD value in the income_usd column for you or your CPA to classify and report on Schedule 1.

glnc is MIT-licensed AS-IS software. It does not constitute tax, legal, or accounting advice. Verify all output with a qualified tax professional before filing.

Single chain (Ethereum is the default), FIFO cost basis, write to 2025.csv:

Treat transfers between your own wallets as non-taxable — basis travels with the asset instead of being realized:

The CSV imports directly into TurboTax (Documents → Import → CSV), Koinly, CoinTracker, and TaxBit. The column order is stable across glnc versions within a major release — see the table below.

Columns are stable so spreadsheets and tax tools can map them once. The last five rows (marked new in v1.1.0) are populated only when --cost-basis fifo is set.

realized_gain_usd and holding_period together give you exactly what Form 8949 needs to populate Part I (short-term) and Part II (long-term) rows. income_usd is a separate Schedule 1 input — see the next section.

US tax treats crypto activity along two tracks. glnc emits the data for both, but it does not decide which is which — that decision depends on your facts.

Capital gains (Form 8949 → Schedule D). Disposals of crypto held as property: selling for fiat, swapping one token for another (yes, every swap is a disposal — Notice 2014-21), spending crypto on goods. glnc populates cost_basis_usd, proceeds_usd, realized_gain_usd, and holding_period on every swap, transfer-out, and native-transfer-out row that is not an own-wallet transfer.

Ordinary income (Schedule 1). Crypto received in exchange for services or as a reward — staking rewards, airdrops, hard forks, mining income, lending interest, referral rewards. Per Rev. Rul. 2019-24 and Rev. Rul. 2023-14, this is taxable at fair market value on the date of receipt, and the FMV becomes the cost basis of the resulting lot. glnc surfaces the candidate USD value in income_usd on every inbound row from a non-own-wallet counterparty — but glnc cannot tell a staking reward from a gift from a relative from a returned loan. You or your CPA make that call. See IRS Publication 525 (Schedule 1 income categories) and Publication 544 (sales and dispositions).

The minimal workflow: filter the CSV to rows where income_usd is non-empty, classify each one as income or non-income, sum the income rows by category for Schedule 1. The zero-cost-basis lots that glnc created from those receipts will then produce the correct realized gain when you eventually dispose of them.

FIFO (First In, First Out) is the default IRS assumption for digital-asset disposals when no specific-identification election applies. glnc walks rows chronologically and maintains a per-asset queue of lots; each acquisition pushes a lot (quantity, cost basis per unit, acquired_at), and each disposal pops lots from the front of the queue until the disposed quantity is consumed.

Worked example. Assume a single asset, ETH:

If a single disposal had popped one short-term lot and one long-term lot, glnc would label holding_period as mixed. For Form 8949 you would then split that disposal into two rows manually (short-term portion on Part I, long-term portion on Part II) using the basis breakdown in the CSV — the algorithm preserves enough detail for that, but glnc does not auto-split the output row.

The IRS rule is "more than one year" for long-term capital gain treatment. glnc implements this as disposed_at − acquired_at > 365 × 86400 seconds.

Caveat. glnc compares unix-second timestamps, not calendar dates. For more than 99% of dispositions this matches the IRS rule exactly, but the second-precision comparison can disagree with calendar-date arithmetic by one day across a leap year for a disposal almost exactly 366 days after acquisition. If you are within ten days of the boundary on a material disposal, verify by hand.

Send 1 ETH from your hardware wallet to your exchange and back, and a naive cost-basis engine will record two disposals and two acquisitions — fabricating a taxable event out of thin air. --own-wallets tells glnc which addresses you also control so transfers between them are not treated as disposals.

How it works. When glnc sees an outbound transfer to an own-wallet counterparty, it consumes lots from the queue silently — no realization, no row in Form 8949. When it sees an inbound transfer from an own-wallet counterparty, it adds the received amount as a zero-basis lot and emits a warning, because the source wallet was outside the queried address range.

To preserve basis across all your wallets, run glnc history separately for each, listing the others in --own-wallets each time, and concatenate the outputs. A future version may add a single-invocation mode that takes a list of addresses and tracks basis across all of them.

glnc history defaults to --chain ethereum for FIFO mode. v1.1.0 supports five EVM chains via Etherscan V2: ethereum, polygon, arbitrum, base, and optimism. If you run FIFO without an explicit --chain, glnc prints a banner reminding you that the export covers a single chain and that bridging activity will show up as cross-chain "transfer-out" rows with no offsetting acquisition.

For a multi-chain wallet, run once per chain and concatenate. Dedupe by hash if the wallet has activity on chains that share an EVM address — they shouldn't have shared txs, but cross-chain bridges sometimes emit on both sides:

Caveat: FIFO lot state is per-invocation, so cross-chain bridge activity has the same problem as cross-wallet transfers — basis is rebuilt from scratch on each chain. For any wallet that bridges meaningfully across chains, you will want to reconcile by hand or wait for v1.2's planned multi-chain mode.

glnc treats WETH ↔ ETH wrap/unwrap (and analogous wrappers on other chains) as an ordinary swap — both sides realize. This is the conservative position: the taxpayer slightly over-reports gain, because a wrap that occurs near the cost basis produces a near-zero realized gain anyway, and an unwrap that occurs far from the cost basis correctly captures the price move. The IRS has not issued definitive guidance on whether a wrap is a "like-kind" exchange (which was disallowed for non-real-property by the 2017 Tax Cuts and Jobs Act anyway) or a non-event, so this stays the safe default until guidance lands.

If your CPA prefers the alternative treatment (basis carries through, no realization), filter kind == 'wrap' or kind == 'unwrap' rows out of the CSV before importing, and net the resulting WETH/ETH lots manually. A future version may add an override flag.

1. Schedule 1 ordinary income is not auto-classified. income_usd is populated for inbound transfers from non-own-wallets and is a hint, not a determination. Staking rewards, airdrops, hard forks, mining, lending interest, and referral payouts all flow through this column, mixed in with gifts and returned loans. You decide which is income, and you report on Schedule 1. The IRS treats the FMV at receipt as both the income amount and the cost basis of the resulting lot (Rev. Rul. 2019-24, 2023-14).

2. Cross-chain bridges and unsupported DeFi are not basis-tracked. Liquidity provision, lending, perpetuals, bridge deposits, and any contract call glnc does not specifically decode land in the generic contract-call bucket with no FIFO treatment. The asset movement is still in the CSV; the basis math is not.

3. Without --own-wallets, transfers to your own addresses look like disposals. Sending ETH from your hardware wallet to your exchange and back will produce fabricated taxable events unless you list every wallet you control. Run with --own-wallets from the start — there is no good way to reconstruct this after the fact.

4. Gas fees are not capitalized. fee_usd is recorded separately on every row but is not added to cost basis on acquisitions or netted from proceeds on disposals. Pub 551 allows capitalizing acquisition costs into basis, and Pub 544 allows netting disposal costs from amount realized — glnc defers this to your tax tool because the right answer depends on whether you treat trading as an investment activity or a business activity.

5. Wrap and unwrap are taxable in glnc. See the section above; this is a conservative choice and CPAs may disagree.

6. FIFO only. LIFO, HIFO, and specific-identification are not implemented in v1.1.0. Deferred to v1.2 or later. If you have elected specific-identification for digital assets in writing under the procedures clarified by Notice 2014-21 and subsequent guidance, FIFO output will not match your election.

7. Missing basis records as $0. If glnc sees a disposal of an asset it never saw acquired (because the acquisition was before the queried range, on a different chain, or on a wallet not listed in --own-wallets), it records cost_basis_usd = 0 and emits a warning. This is conservative — the taxpayer over-reports the gain — but you should backfill the real basis before filing.

8. Stablecoin micro-gains. CoinGecko's daily close prices for USDC, USDT, and DAI drift by a fraction of a cent day-to-day, so moving stablecoins around can produce $0.01–$0.10 "realized gains" per disposal. These are de minimis but technically reportable; aggregate or zero them in your tax tool if you prefer.

9. Holding-period boundary uses second-precision arithmetic. See the holding-period section. Verify any disposal within ten days of the 365-day boundary against a calendar-date calculation.