Crypto accounting, by asset and blockchain

Different assets, different accounting. Bitcoin's UTXO history, Ethereum's gas and staking, Solana's transaction volume, an L2's bridged positions — each carries its own treatment. CryptaCount handles them all in one sub-ledger, with cost-basis-accurate journals and reporting under IFRS and US-GAAP.

Pick your asset

Each asset page goes deep on the treatment that matters for that chain — cost basis, income classification, and the events standard tools miss.

• Bitcoin accounting → — clean cost basis at high UTXO volume; mining income and fees.
• Ethereum accounting → — gas on every tx, staking rewards, deep DeFi, NFTs, L2 bridging.
• Solana accounting → — very high tx volume, staking rewards, SPL tokens, NFTs.
• Polygon accounting → — MATIC→POL migration, bridged assets, low-fee DeFi.
• Avalanche accounting → — C-Chain EVM activity, subnets, staking, DeFi.

One sub-ledger, every chain

Whatever you hold, the accounting runs through the same engine: chain activity read directly through our own on-chain data infrastructure across 90+ chains, classified into proper accounting events, with your chosen cost-basis method applied across every lot and balanced journals reconciled on-chain ↔ exchange ↔ GL. How the crypto sub-ledger works →

Cost basis your way, jurisdiction rules automatically

Apply any of 12 disposal methods — FIFO, LIFO, HIFO, WAVG, Specific Identification, and more — per entity and jurisdiction. Your chosen method applies; jurisdiction-mandated treatments such as UK Section 104 pooling and Canada ACB apply automatically. Cost-basis methods →

Reporting under IFRS & US-GAAP

Gain/loss and disclosures mapped to the standard each entity reports under, including FASB ASU 2023-08 fair value. Crypto compliance & reporting →

Connect every source

Import each asset from exchanges and wallets, then sync reconciled journals to your ERP — Xero and Zoho live today, with QuickBooks, NetSuite, and Sage on the roadmap. Integrations →

The full picture: why accounting differs by asset and chain

"Crypto accounting" sounds like one discipline, but the work changes shape with every chain you hold, and a platform that flattens those differences will quietly mis-state your books. Bitcoin's UTXO model produces clean but high-volume acquisition and disposal history plus mining income and fees. Ethereum charges gas on every transaction and layers staking rewards, deep DeFi, NFTs and L2 bridging on top. Solana's transaction volume is very high, with staking rewards, SPL tokens and NFTs of its own. An L2 brings bridged positions that have to be tracked across the move. Each of these carries its own treatment for cost basis, income classification and the events that standard tools miss. CryptaCount handles them all in one sub-ledger, so the differences are respected rather than averaged away.

The unifying idea is that whatever you hold, the accounting runs through the same engine: chain activity read directly through our own on-chain data infrastructure across 90+ chains, classified into proper accounting events, with your chosen cost-basis method applied across every lot and balanced journals reconciled on-chain against exchange against GL. The per-asset depth lives on the leaf pages; this hub is where you see how one engine serves all of them. How the crypto sub-ledger works →

Go deep by asset

Each asset page goes deep on the treatment that matters for that chain — cost basis, income classification, and the events standard tools miss:

• Bitcoin accounting → — clean cost basis at high UTXO volume, plus mining income and fees
• Ethereum accounting → — gas on every transaction, staking rewards, deep DeFi, NFTs and L2 bridging
• Solana accounting → — very high transaction volume, staking rewards, SPL tokens and NFTs
• Polygon — the MATIC to POL migration, bridged assets and low-fee DeFi, all on one chart of accounts
• Avalanche — C-Chain EVM activity, subnets, staking and DeFi captured as accounting events

Who this is for

This hub speaks to finance teams whose holdings span more than one chain and who need each one accounted for correctly rather than lumped together:

• Treasuries and funds holding several assets across chains, each with its own income and cost-basis profile
• Web3 companies earning staking or protocol income on one chain while paying contributors on another
• Accounting firms carrying clients with mixed multi-chain portfolios that have to reconcile to one set of books
• Groups consolidating Bitcoin, Ethereum, Solana and EVM-chain activity into a single consolidated view

What these teams have in common is that the differences between chains are not academic — they change the numbers. A Bitcoin-heavy treasury and an Ethereum-heavy DeFi operation need the same discipline applied to very different event types, and a fund spread across both plus Solana needs all of it reconciled to one defensible set of books. That is the case a single multi-chain sub-ledger is built to serve.

One engine, consistent across every chain

The advantage of running every asset through one sub-ledger is consistency. Cost basis is applied the same way whether the disposal is a Bitcoin UTXO or an SPL token: you apply any of 12 disposal methods — FIFO, LIFO, HIFO, WAVG, Specific Identification and more — per entity and jurisdiction, while jurisdiction-mandated treatments such as UK Section 104 pooling and Canada ACB apply automatically. Income is classified consistently too: staking rewards and DeFi yield as income, liquidity, lending, borrowing and wrapping as accounting events, and gas captured per transaction and treated as cost. The reporting that comes out the other end maps to the standard each entity reports under, including fair-value measurement under US-GAAP. Cost-basis methods → · crypto compliance & reporting →

The events standard tools miss

Most of the difference between a correct set of crypto books and a plausible-looking one comes down to events that generic tools never recognise. Gas is charged on every Ethereum transaction and has to be captured per transaction and treated as cost, not silently absorbed. Staking and validator rewards are income at the moment they are received, not a free increase in holdings. DeFi positions — liquidity provision, lending, borrowing and wrapping — are accounting events with real consequences for basis and gain, not raw transfers to be ignored. NFT mints, purchases, sales and royalties carry cost basis and gain/loss of their own. Bridged and L2 positions move basis across chains and break later disposals if that basis is lost in transit. CryptaCount classifies and posts every one of these as a proper accounting event through one engine, which is why the same books hold up whether the activity sits on Bitcoin, Ethereum, Solana or an EVM L2. The per-asset pages — Bitcoin →, Ethereum → and Solana → — show how each of these plays out chain by chain.

A buyer's guide: evaluating multi-asset crypto accounting

• Per-asset treatment, not a flat model — UTXO history, gas, staking and bridged positions each need handling, not one generic import
• Native coverage across many chains — own infrastructure across 90+ chains captures DeFi and internal transfers a rented API misses
• Consistent cost basis across assets — the same method should apply identically whether the lot is BTC, ETH or an SPL token
• Income classified correctly per chain — staking, mining, rewards and yield must be recognised as income, not buried in transfers
• Reporting mapped to your standard — gain/loss and disclosures should follow IFRS or US-GAAP per entity, including fair value where required
• One consolidated view — many assets and chains should roll up into a single set of books, not separate trackers

Common pitfalls across multi-chain books

• Treating every chain the same — ignoring UTXO volume, gas or bridging produces a basis no one can reconcile
• Gas left untracked — per-transaction network fees that aren't captured understate cost and distort gains
• Staking and yield mislabelled — income recognised as a transfer rather than income misstates both the P&L and the basis
• Bridged positions lost — assets moved across an L2 bridge with no basis carried across break every later disposal
• Separate tools per asset — a different tracker for each chain guarantees the books never reconcile to one source

How CryptaCount delivers this

CryptaCount is accounting software, not a portfolio tracker: double-entry journals, lot-level cost basis and audit-ready financials per asset and chain. It reads on-chain activity directly through our own infrastructure across 90+ chains, classifies staking, DeFi and gas as proper accounting events, applies your chosen cost-basis method consistently across every lot, and reconciles on-chain against exchange against GL before posting balanced journals. Reporting maps to the standard each entity reports under, and every asset rolls up into one consolidated set of books. Import each asset from exchanges and wallets, then sync reconciled journals to your ERP — Xero and Zoho live today, with QuickBooks, NetSuite and Sage on the roadmap. Integrations → · the crypto sub-ledger →

Is CryptaCount a portfolio tracker?

No. It is accounting software — double-entry journals, lot-level cost basis and audit-ready financials per asset and chain, not a performance tracker. A tracker tells you what a wallet is worth; CryptaCount gives you the debits and credits, the gain/loss and the audit trail behind them.

Does it handle staking, DeFi and gas consistently across chains?

Yes. Staking rewards and DeFi yield are classified as income; liquidity, lending, borrowing and wrapping are recorded as accounting events; and gas is captured per transaction and treated as cost — the same way on Ethereum, Solana or any EVM chain. Consistency across assets is the point of running them through one engine.

How are bridged and L2 positions accounted for?

Bridged movements are recognised as the internal transfers they are, with cost basis carried across the move rather than lost at the bridge. That keeps later disposals on the destination chain accurate, which is exactly where multi-chain books usually go wrong. The Ethereum accounting → page covers L2 bridging in depth.

Which cost-basis methods can I use, and do jurisdiction rules apply?

Twelve disposal methods — FIFO, LIFO, HIFO, WAVG, Specific Identification and more — selectable per entity and jurisdiction. Jurisdiction-mandated treatments such as UK Section 104 pooling and Canada ACB apply automatically, so a mixed-jurisdiction group is handled correctly without manual workarounds. See the cost-basis methods → page.

How does multi-chain activity roll up for reporting?

Every asset and chain runs through the same sub-ledger and consolidates into one set of books, so gain/loss and disclosures map to the standard each entity reports under from a single source. There is no separate tracker per chain to reconcile — the consolidated view sits on top of all of them. Crypto compliance & reporting →

Which chains does CryptaCount cover?

On-chain activity is read directly across 90+ blockchains through our own infrastructure, covering Bitcoin, Ethereum, Solana, Polygon, Avalanche and many more. Reading chain history natively rather than through a rented third-party API is what improves capture of internal transfers, gas and DeFi, and it means a new chain you start holding flows into the same engine and the same consolidated books without a separate tool.

How is high transaction volume, such as Solana's, handled at close?

The volume lives in the sub-ledger, not your general ledger. CryptaCount ingests and classifies every transaction at source, applies cost basis across the lots, and posts only summarised, balanced journals up to the GL. So a chain like Solana that produces very high transaction counts is absorbed without bloating your books — the detail stays reconcilable in the sub-ledger while the GL receives a clean period summary it can actually read.

Bringing crypto accounting together

Accounting for crypto is less about any single asset and more about one reconciled record that ties every position, gain and disclosure back to a source transaction. That is what a sub-ledger provides, and it is what lets a firm apply a consistent policy under IFRS or US GAAP, post clean journal entries to the general ledger, and meet compliance reporting obligations. CryptaCount is the sub-ledger that does this across every asset and venue, so your books stay the system of record and the transaction-level detail stays where it belongs.

Putting a multi-chain close together

The hardest part of multi-chain accounting is not any single asset — it is assembling one defensible close out of positions that each behave differently. A treasury might hold Bitcoin with clean but high-volume UTXO history, Ethereum throwing off staking rewards and gas, and Solana generating sheer transaction volume, and at month-end all of it has to roll up into a single consolidated set of books that a reviewer can sign. That only works when the per-chain detail is reconciled before it consolidates, not patched together afterward from separate trackers. Running every chain through the same engine is what makes the consolidation trustworthy: the cost-basis method is applied the same way to a Bitcoin disposal and an SPL token, and income is classified the same way wherever it is earned.

A multi-chain close tends to come together along the same path:

• Each chain reconciles to its own wallets and venues first, so a discrepancy is caught at source rather than buried in the group total.
• Cost basis and income are classified consistently across assets, so the consolidated gain/loss is comparable rather than method-soup.
• Internal and bridged movements carry basis across, so a transfer between chains is not mistaken for a disposal.
• Only summarised, balanced journals reach the general ledger, while the per-transaction detail stays reconcilable underneath.

Done this way, the consolidated view sits on top of every chain rather than competing with a pile of single-asset tools. CryptaCount keeps the detail in one crypto sub-ledger and maps the reporting to the standard each entity reports under, so a mixed Bitcoin, Ethereum and Solana book closes from a single source — see the crypto compliance and reporting overview for how that policy flows through to the statements. The structural advantage is that adding a new chain does not add a new tool or a new reconciliation silo: the next asset a treasury starts holding flows into the same engine, the same chart of accounts, and the same consolidated close, so the process grows with the portfolio instead of fragmenting under it. The differences between chains are respected where they matter and disappear where they should: in one clean, auditable close that a reviewer can trace back to source on any line.