MetaMask crypto accounting

Connect MetaMask to CryptaCount with your public wallet address and turn on-chain activity into clean books. CryptaCount reads your history, calculates cost basis, and posts journal entries to your ERP — with the detail held in the sub-ledger.

Your wallet as a source for the sub-ledger

On-chain wallets hold treasury and operational activity your accounting system can't see. CryptaCount reads that activity into a crypto sub-ledger, applies cost basis and your measurement policy, and produces summarized journal entries for your general ledger.

How to connect

MetaMask is a non-custodial wallet, so there's no API key — you connect by public address (a read-only, watch-only view):

1. Public address (recommended). Copy your MetaMask public wallet address (`0x…`). In CryptaCount, go to Integrations → Add wallet → MetaMask and paste it. CryptaCount reads your on-chain history across supported EVM networks (Ethereum, Polygon, Arbitrum, Optimism, Base, and others).
2. CSV import. Export your transaction history from the MetaMask portfolio as a CSV and upload it.

**Only ever provide the *public* address. Never enter a Secret Recovery Phrase** or private key — CryptaCount never asks for it. A public address is watch-only and read-only; it can't move funds. Add each address if your company uses multiple wallets.

What flows into your books

On-chain activity for those addresses: swaps, transfers, DeFi interactions (liquidity, lending, staking), NFT activity, and gas fees — each classified for accounting, with transfers between your own wallets matched so they aren't booked as disposals.

Built for finance teams

• Multi-chain — one set of books across the chains your company uses, via our on-chain data infrastructure
• Automated cost basis — 12 disposal methods (FIFO, LIFO, HIFO, WAVG, Specific ID, and more); jurisdiction-mandated treatments (UK Section 104 pooling, Canada ACB) apply automatically
• Journal entries to your ERP — QuickBooks, Xero, NetSuite, or Sage → ERP integrations →
• Audit-ready — every GL line drills back to the on-chain transaction

See the sub-ledger → · Accounting for firms →

How CryptaCount ingests your MetaMask wallet activity into the sub-ledger

A MetaMask wallet is connected by its public address, a watch-only view that lets CryptaCount read on-chain history without any ability to move funds. From that address CryptaCount reads every transaction across the supported EVM networks the wallet uses and writes each one as a discrete, timestamped record in the crypto sub-ledger — the swap, the transfer, the contract interaction, the gas fee — each with its asset, quantity, counterparty and on-chain reference intact. Your general ledger receives summarised journal entries, while the full on-chain detail stays underneath for reconciliation, gain calculation and audit.

Ingestion is idempotent: each on-chain transaction is keyed to its hash and log position, so re-reading a wallet never double-counts an event. You can refresh after a close, add a newly discovered address, or extend history, and trust that quantities and balances stay stable across refreshes. Because on-chain wallets hold treasury and operational activity your accounting system cannot otherwise see, this is often the only place that activity becomes visible to finance at all — a dependable single source of truth for what the wallet actually did.

Classifying and reconciling on-chain transactions

Raw on-chain data is dense and unlabelled; CryptaCount makes it accounting-ready by classifying each transaction into an event your books can use — a swap (a disposal of one asset and an acquisition of another, priced independently), a transfer in or out, a DeFi interaction such as supplying liquidity, lending or staking, an NFT movement, or a gas fee. A swap on a decentralised exchange is recognised for the two-sided event it is, so the realised gain embedded in it is captured rather than hidden inside a single token movement.

Reconciliation proves the books against the chain itself. CryptaCount tracks the running balance of each asset implied by your classified history and checks it against the on-chain balance of the address, so a missing transaction, an unsupported network, or an unclassified interaction surfaces as a discrepancy rather than silently distorting your positions. The chain is the ultimate authority for what a wallet holds, and the sub-ledger should reconcile to it — that status flows through to your crypto sub-ledger → for reviewers to inspect.

Cost basis and gain/loss for the books

Every disposal from the wallet — a swap into another token, a sale, or a transfer your policy treats as a disposal — needs a cost basis so the realised gain or loss can be measured and posted. CryptaCount maintains acquisition lots per asset and consumes them on disposal under your chosen method, then books the gain or loss to the general ledger alongside the on-chain movement. The lots live in the sub-ledger, so the posted figure is never opaque: you can drill from a gain on the GL back to the specific acquisitions it consumed, including assets first acquired on an exchange and later bridged into the wallet.

The engine supports the full range of disposal strategies a finance team may need and applies jurisdiction-mandated treatments automatically where relevant. The method is a deliberate policy choice applied consistently across every account and chain, not a per-transaction guess — see the available cost-basis methods → for how each one consumes lots.

Transfers between your own accounts

On-chain treasuries move assets constantly — from an exchange into MetaMask, between two of your own wallets, or across chains via a bridge — and each move can be mistaken for a disposal. Nothing has been sold when an asset simply changes location within the organisation, yet a naive reader sees an outflow from one address and an inflow to another and risks booking a phantom gain. CryptaCount matches the two legs of an internal transfer into a single movement of the same asset, carrying the original cost basis across the move so it is neither reset nor crystallised as a gain that never happened.

Matching considers asset, quantity, timing and direction across all of your connected addresses, and flags anything it cannot confidently pair for human confirmation — bridges and wrapped-asset conversions in particular benefit from a reviewer's eye. That keeps you in control of the basis being carried, which is precisely what an auditor expects when assets move between an organisation's own wallets. Adding every company address up front is what makes this matching reliable rather than partial.

Fees and internal movements

Every on-chain action costs gas, and gas is part of the economics of the transaction it pays for. CryptaCount captures gas fees and treats them per your policy — adding the gas on an acquisition to that asset's cost basis, netting it against proceeds on a disposal, or booking it as an expense — so reported cost and gain reflect the true cost of operating on-chain. Across an active wallet, gas adds up to a real number, and ignoring it understates cost and overstates gains. DeFi interactions can also generate reward or fee tokens, which are recognised on receipt rather than dropped.

• Gas fees — capitalised into basis, netted against proceeds, or expensed per your measurement policy, never silently ignored.
• DeFi rewards — liquidity, lending or staking rewards recognised at fair value on receipt and given a cost basis for later disposal.
• Swaps — recognised as a disposal and an acquisition, each priced independently, so embedded gains are captured.
• Internal and cross-chain movements — paired across your addresses and excluded from gain calculations, with basis carried forward.

Controls and audit trail

The strongest control with a non-custodial wallet is that CryptaCount only ever holds a public address — watch-only, read-only, unable to move funds — and never asks for a Secret Recovery Phrase or private key. That is trivial to evidence to an auditor: the connection physically cannot transact. Beyond access, every general-ledger line is traceable back through the sub-ledger to the exact on-chain transaction behind it, with its hash, date, asset, quantity and the cost-basis lots consumed. Because the chain is public and immutable, that source reference is unusually strong evidence.

Summarised entries keep your ERP clean while the on-chain detail stays in the sub-ledger, and the same data feeds your crypto compliance reporting → so statements and sub-ledger never diverge. The journals — debits, credits and account mappings — are reviewable before posting via journal entries →, so nothing reaches the GL unseen.

Multi-entity and treasury considerations

Web3 organisations rarely operate from one wallet. Operations, treasury, payroll and protocol activity may each live in separate addresses, and a group may span several legal entities. CryptaCount's workspace model lets you assign each entity's wallets to its own set of books, with its own measurement policy and chart of accounts, while still consolidating across the group when needed. A DAO operator, a fund, or a corporate treasury can keep each entity's on-chain activity cleanly separated rather than commingled in one undifferentiated ledger.

This matters for accuracy and governance alike. Cost basis, transfer matching and gain calculation run within an entity's books, so a transfer between two entities' wallets is treated as the intercompany movement it is, not netted away as if the group were one address. Review and permissions can be scoped per workspace, supporting the segregation of duties an auditor expects across a multi-wallet, multi-chain treasury.

Common pitfalls when accounting for MetaMask activity

• Missing wallets. On-chain activity is only complete if every company address is connected; an omitted wallet leaves a hole that breaks transfer matching and balances.
• Treating swaps as non-events. A DEX swap is a disposal and an acquisition; ignoring it hides a realised gain or loss.
• Booking internal or bridge transfers as sales. Moving assets between your own wallets or across chains is not a disposal — matching the legs preserves basis.
• Ignoring gas. Gas fees are part of transaction cost; omitting them understates cost and overstates gains across an active wallet.
• Mislabelling DeFi rewards. Liquidity, lending and staking rewards are income at receipt and a separate gain on later disposal; conflating them distorts both.

How CryptaCount uses your MetaMask data

CryptaCount reads your MetaMask public address as a watch-only source, ingests every on-chain transaction across the EVM networks you use, classifies swaps, transfers, DeFi interactions, NFT activity and gas into accounting events, reconciles balances against the chain, calculates cost basis and realised gains under your policy, and posts summarised journal entries to your ERP — with the full on-chain detail retained in the sub-ledger so every number is traceable to its transaction hash. It never holds keys and never moves funds. To see how it would handle your wallets and chains, our team can walk through your setup.

Which networks does CryptaCount read for a MetaMask address?

CryptaCount reads on-chain history across the supported EVM networks the wallet uses — Ethereum and major layer-2s and sidechains such as Polygon, Arbitrum, Optimism and Base, among others. The same public address is read on each chain it has been active on, so one set of books can span the networks your organisation actually uses.

How does CryptaCount handle DeFi positions for the books?

DeFi interactions are classified by what they economically are — supplying or withdrawing liquidity, lending, borrowing, or staking — and any reward tokens received are recognised at fair value on receipt with a cost basis for later disposal. Where an interaction is ambiguous, it is flagged for review rather than guessed, so the accounting treatment is a decision you control.

Is connecting a public address actually safe for our treasury?

Yes. A public address is watch-only and read-only: it lets CryptaCount see the wallet's on-chain history but cannot move, sign or withdraw anything. CryptaCount never asks for your Secret Recovery Phrase or private key, and there is no path by which a connected address could authorise a transaction — the access is observation only.

How are cross-chain bridge movements treated?

A bridge moves the same value from one chain to another within your organisation, so it should not be booked as a disposal. When both sides are connected, CryptaCount pairs the legs and carries the cost basis across the bridge, and flags any leg it cannot confidently match for a reviewer to confirm — which is why connecting all of your addresses up front matters.