Crypto DCA Calculator

Add up every unit of cash you committed, add up every coin you received, and divide the first by the second. It is not the average of the prices you paid. Because a fixed amount buys more coins when the price is low, cheap purchases carry more weight in the total, which is why that coin-weighted figure lands below the simple average of the same prices. This page then adds the fees on top of it, and calls the result your average cost.

It depends entirely on what the price did afterwards, which is why this page answers for the path you type rather than issuing a rule. In a market that mostly rose, the earliest possible entry wins and the comparison will say so. In a falling market, spreading the buys wins. In a flat one the two land on the same number, unless the fee is a flat amount per order: the schedule pays that on every buy while the single purchase pays it once. The honest caveat is availability: if the money arrived a paycheque at a time, the day-one column was never an option you had.

Yes. The average cost is total cash out of pocket divided by coins received, so the fee on every single buy is baked into it. That is why it prints slightly above the same division with the fees stripped out; the dark result panel puts the per-coin gap between those two figures next to the price bars, labelled as fees added per coin.

No, and it should not be read as one. You supply the first price and the last price, and the buys in between are placed evenly along a straight line between them. Real markets are never straight. The path is a way to ask a specific question (what would a year of weekly buys have produced if the price halved), not a projection of what comes next.

That is what the second mode is for. Give each purchase its price and either the cash you spent or the coins you received, optionally with a date, and the rows blend into one average cost, one coin balance, and one figure for what the lot is worth at the price you type. Up to 100 rows. One limitation to know: a single fee setting is applied to every row, so if your fee tier changed over time, use the rate closest to the majority of your buys or enter the fee as a flat amount per purchase.

Because weighting is by money, not by transaction count. A purchase near a peak buys few coins, so it changes the denominator very little. Averaging down works for the same reason in reverse: a purchase after a deep fall buys many coins and pulls the average sharply toward it.

A modelled schedule runs to 600 buys, which covers daily purchases for well over a year or weekly ones for a decade, and a clear notice appears if you ask for more instead of the table quietly growing forever. Hand-entered history stops at 100 rows. Everything is calculated on your own device, so those ceilings are about keeping a table readable, not about server capacity.

Neither. There is no price feed, so the current price is whatever you type, and there is no tax engine. Tax rules select particular lots (first in first out, highest in first out, or an averaged pool depending on the country) and only apply once you dispose of coins. Treat the blended average here as your cost basis input and check the disposal rules where you live.