How to calculate average buy price for a crypto portfolio
Last updated: September 10, 2026
Key Takeaways
- Buy 0.25 ETH at $2,000 per ETH, and the trade value is $500 before fees.
- Say 0.40 BTC at $50,000 is $20,000 before fees.
- With buys of $20,000, $7,500, and $12,000 plus $15 in included fees, the total basis comes to $39,515.
- Using the example above, $39,515 ÷ 0.80 BTC = $49,393.75 per BTC.
Average buy price for a crypto portfolio means your cost basis divided by the number of units you hold, with every purchase, fee, split, token migration, and any disposal that changes the lot history folded in. Want the clean version? This is the number that answers, “What did these coins actually cost me?” This article is informational only, not financial or tax advice, and your own tax and accounting rules may differ by country and change over time; for a personal situation, talk to a qualified adviser.
Who this is for — and who should do something else

Anyone who bought the same coin or token more than once can use this, especially if you want one clean average entry price across those buys. It also fits if you track a long-term stack in a spreadsheet, a portfolio app, or a tax lot export from an exchange. Simple arithmetic. The snag is deciding what counts as a “buy” and what counts as a cost.
I’m assuming you already have the transaction history: dates, amounts, prices, fees, and asset quantities. If all you have is a current balance and a fuzzy memory of what you paid, you cannot calculate a defensible average. You can guess. You cannot calculate.
This method is not for people trying to compute taxes from scratch in a jurisdiction with specific lot-selection rules unless they also know those rules. In some places, average cost is allowed for tax purposes; in others, FIFO means first in, first out, and specific identification may be required or permitted. The label “average buy price” can be fine for personal tracking while being wrong for filing. That split matters.
Not every receipt belongs here. If most of the portfolio came from mining, staking, airdrops, gifts, or transfers from another wallet, those entries can have different tax or accounting treatment from a simple cash purchase, so consult a tax adviser or accounting expert before blending them into an average; see IRS guidance on digital asset transactions and CRA guidance on cryptoassets. Separate those first, then average. Otherwise the spreadsheet looks tidy while the math goes sideways.
The cleanest use case is a spot position bought in several tranches: for example, you bought 0.10 BTC on one day, 0.05 BTC later, then another 0.08 BTC after that. The average buy price tells you your blended cost per BTC. It does not tell you profit, and it does not tell you tax due. Just the cost side. That’s it.
What does average buy price actually mean in crypto?
Average buy price means weighted average cost per unit, not the plain average of the prices you saw on different days. That’s the trap. Say you bought 1 unit at $10 and 9 units at $1: the simple average of the two prices is $5.50, but your real average cost is much closer to $1.90 because you bought far more at the lower price.
The formula is straightforward:
Average buy price = total cost basis ÷ total units held
Cost basis is the sum of what you paid to acquire the asset, usually including trading fees and sometimes exchange or network fees that are part of the acquisition. “Basis” is the accounting term for what you have in the position before gains or losses. If you later sell part of the position, that sale does not change the historical average cost of the remaining units under a pure average-cost view, but it does matter for realized gain or loss.
Price per coin and total cost are not the same thing. If you buy 0.25 ETH at $2,000 per ETH, the trade value is $500 before fees. Add a $2 exchange fee, and your total cost basis becomes $502; the average buy price for that lot is $2,008 per ETH. Small on paper, sure. Across many trades, though, that gap becomes hard to ignore.
Precision matters too. Crypto units can be tiny. BTC can be tracked to 8 decimal places on-chain, and many exchanges show more than 2 decimals for fiat equivalent. Round too aggressively and your average starts to drift. In practice, I’d keep at least 4 decimal places for the unit price and as many decimal places as your record source reliably provides for quantity. Anything coarser can be a bit of a dog’s breakfast.
Average buy price is useful for tracking, but it is not a universal accounting rule. Some brokers and tax systems use lot-based methods, not a single blended average. If you are using this for taxes, check the local rule set or an adviser before you assume the number you see in a portfolio app matches what the tax authority will accept. See the IRS and HMRC guidance on how crypto is treated in records and reporting.
How do you calculate it step by step?

Start by totaling every acquisition cost, then divide by total units acquired and adjust for any units you no longer hold under the method you are using. The easiest route is one row per transaction, with units, price, and fees kept separate.
- List every acquisition transaction for the same asset. Record date, units, trade price, and fee for each buy, such as 0.40 BTC, 0.15 BTC, and 0.25 BTC. Check that each line is a real acquisition, not a transfer or internal wallet move. If a line has no trade price, it is probably not a purchase and should not enter the average.
- Convert each trade to total cost in your base currency. Multiply units by price, then add any acquisition fee charged in cash or crypto if it is part of the trade. For example, 0.40 BTC at $50,000 is $20,000 before fees. Check that the currency matches across all lines; if one exchange shows EUR and another USD, convert both to one base currency first. A mismatch here makes the average meaningless.
- Decide how you will treat fees before you start. A fee paid to acquire the asset usually belongs in cost basis, while a fee paid to send coins between your own wallets may not belong in the buy price itself; if the rule is unclear, speak with a tax adviser or accounting expert and check IRS Publication 551 or your local equivalent. Check that your rule stays consistent across the full history. If some fees are included and others are ignored, the result is distorted.
- Sum total cost basis. Add all acquisition costs across the rows. If your buys were $20,000, $7,500, and $12,000 with $15 in included fees, the total basis is $39,515. Check that the spreadsheet total matches the exchange export or account ledger. A row total that disagrees by even a small amount can point to a missed fee or a duplicated trade.
- Sum total units acquired. Add the coin amounts, such as 0.40 + 0.15 + 0.25 = 0.80 BTC. Check that you are not mixing in sold units, sent units, or staking rewards. If your total units are lower than the wallet balance, some units came from elsewhere and should be separated.
- Divide total cost basis by total units. Using the example above, $39,515 ÷ 0.80 BTC = $49,393.75 per BTC. Check the quotient with a calculator, not mental math. If the number looks far from the market price at the time of one purchase, that is not automatically wrong; the weighted average can sit above or below individual trade prices.
- Adjust for partial sales if your goal is current position cost. If you sold part of the stack, remove the sold units and the corresponding basis using the accounting method that applies to your records, such as FIFO or specific identification. Check whether your jurisdiction or accountant expects a lot-based method instead of a single blended average. Skip this step, and your average describes an old position, not the one you still hold.
- Check the result against your goal. If you want a personal breakeven estimate, compare the average buy price to current market price. If you want tax reporting, compare it to the method your jurisdiction requires. Check that the number answers the right question. A portfolio average is not the same as realized tax cost.
A worked example helps. Suppose you bought 0.50 ETH for $1,000, then 0.30 ETH for $900, and you paid $5 in buy fees on each trade. Total basis is $1,000 + $5 + $900 + $5 = $1,910. Total units are 0.80 ETH. Average buy price is $2,387.50 per ETH. Rounding too early can nudge the answer, so keep the full figure until the final display.
What should I include, and what should I leave out?
Include the purchase price, the acquisition fee, and the exact quantity for each buy. Leave out unrelated transfers, wallet-to-wallet moves, and non-purchase receipts until you know whether they belong in the same accounting bucket. Fussy? Maybe. But that line is the difference between a true average cost and a number that only looks precise.
The most useful data fields are date, asset symbol, quantity, unit price, fee, and currency. If you use a spreadsheet, one row per transaction is cleaner than one row per day. A trade on 2024-03-12 at 14:37 and another at 18:05 are separate lots even if they happened the same day. If the exchange export gives you order IDs or transaction hashes, keep them. They let you trace mistakes later.
I would not merge different assets just because they trade as a pair on the same platform. BTC and wrapped BTC are not the same thing in every accounting context. A token migration from one contract to another also needs care. A 1:1 swap may preserve value, but it does not always preserve the same record in the same way, so confirm how the platform and your records treat it before combining lots. If the platform auto-converts one asset to another, that event may be a disposal plus an acquisition rather than a simple transfer.
Stablecoins need special care too. If you bought a token against USDT or USDC, your base currency may still be USD for personal tracking, but the trade history may show only the quote asset. That is fine as long as you translate everything into one base currency before averaging. The number should answer one question in one currency.
A generic article often forgets fees, but fees are where many average-cost calculations go wrong. A $3.50 fee on a small trade can move your average a lot more than on a large one. If an exchange charges fees in the asset itself, the quantity you receive is net of fee, which changes the denominator. Record it exactly, not later from memory.
The mistakes people actually make, and what they cost
Most errors come from mixing price, cost basis, and balance as if they were the same thing. They are not, and the spreadsheet will still let you fool yourself.
-
Using a simple average of prices instead of a weighted average. The consequence is a fake entry price that gives too much weight to tiny buys. The correct alternative is to total cost basis and divide by total units.
-
Ignoring fees. The consequence is a slightly too-low average on each trade and a bigger gap over time. The correct alternative is to add acquisition fees into basis unless your accounting rule says otherwise.
-
Mixing buys with transfers or rewards. The consequence is an average that no longer describes purchase cost. The correct alternative is to keep purchases, transfers, and non-buy receipts in separate buckets.
-
Rounding too early. The consequence is small arithmetic drift that can become visible after dozens of trades. The correct alternative is to keep full precision in the working file and round only for display.
-
Using the average buy price as a tax number without checking local rules. The consequence is filing under the wrong cost method. The correct alternative is to confirm whether your country uses average cost, FIFO, specific identification, or another method.
-
Treating a wallet balance as proof of cost. The consequence is that you may assume all units share the same origin. The correct alternative is to reconcile every unit back to a lot or source event, and if the records are incomplete, get help from a tax or accounting expert before using the balance as a proxy; see IRS and HMRC recordkeeping guidance.
A clean portfolio average is useful, but it does not replace records. If your exchange history is incomplete, the number is only as good as the missing data. That’s the honest limit. A perfectly formatted spreadsheet cannot recover a trade you never recorded.
When does the standard method stop working?
The standard method stops working when one asset in your wallet came from more than one accounting source, because a single blended average can hide the rule that should apply to each part. Here are the common breakpoints.
You have staking, mining, airdrops, or referral rewards: these are not ordinary purchase lots in many systems — separate them and do not blend them into buy-price averaging until you know how your jurisdiction treats them; consult a tax adviser or accounting expert and review IRS or HMRC guidance.
You traded across several exchanges and some exports are missing: the record is incomplete — reconstruct from blockchain data, email confirmations, or account statements before calculating, because missing lots distort both units and basis.
You sold part of the position and need tax gain or loss: the remaining average may still be fine for tracking, but tax reporting may need FIFO or specific identification — use the method required where you file, not the one that is easiest.
You received a wrapped, bridged, or migrated token: the asset may have changed contract, ticker, or legal treatment — do not average the pre- and post-migration history together until you confirm the swap is treated as continuity in your records.
Your trades were in multiple fiat currencies: a USD, EUR, and GBP cost number are not directly comparable — translate each transaction into one base currency at the transaction date before averaging.
You are trying to compute a performance figure for borrowed or margin positions: interest, liquidation events, and repayments change the picture — a simple buy-price average leaves out the financing cost and can mislead badly.
When one of these situations shows up, the right move is usually to pause and separate the records, not to force a single average through the whole portfolio. A neat average that ignores the accounting breakpoints may look tidy, but it can give you the wrong answer.