Coinmarketcap is a manual portfolio ledger for entries and balance checks

Published 2026-08-06

Coinmarketcap is a portfolio tracker that lets a signed-in user record buys, sells, and transfers without moving crypto. Each saved entry changes the displayed holding, cost data, or realized performance inside the portfolio, while the actual BTC, ETH, SOL, or token remains at its exchange or wallet. The useful workflow is bookkeeping: choose the correct record type, enter the quantity and timing, confirm the new state, then reconcile the dashboard against the venue that holds the asset.

In short: A transfer changes tracked quantity without creating a purchase cost, while a buy records both units and acquisition price.

A manual ledger gives multi-venue holders one reconciled balance

The manual portfolio gives someone holding assets across Binance, Coinbase, MetaMask, and Phantom one consolidated accounting view. A single logged-in Coinmarketcap account is the prerequisite, after which each asset receives its own transaction history and calculated balance.

Three entry choices describe how quantity reached or left the portfolio: Buy, Sell, and Transfer. The Transfer choice has two directions, in and out. Buy and Transfer In raise the recorded quantity; Sell and Transfer Out reduce it. None of those buttons sends a wallet instruction, requests a blockchain signature, or places an order. Zero funds enter Coinmarketcap custody because the confirmed action writes a portfolio record rather than executing a payment.

This arrangement suits holdings accumulated through several venues because the dashboard treats their manual records as one ledger. A BTC purchase on Coinbase and another BTC purchase on Binance contribute to the same BTC total when entered in one portfolio. Venue names belong in the note field, preserving context without changing the arithmetic.

Typed records create a gap between displayed and on-chain balances

Manual transaction records are user-supplied assertions, so displayed accuracy follows the accuracy of the quantity, asset, price, and direction entered. A portfolio balance does not independently prove that the corresponding units exist on Bitcoin, Ethereum, Solana, or BNB Smart Chain.

Decimal placement produces the largest mechanical discrepancy. Entering 0.1 BTC instead of 0.01 BTC makes the tracked amount 10 times larger. Bitcoin supports 8 decimal places, ether uses 18, and native USD Coin issued by Circle uses 6. ERC-20 tokens define their own decimal precision, so the asset selection and displayed unit must match the actual token. Native ETH and Wrapped Ether, or ETH and WETH, are separate assets even though their values are designed to remain closely related.

Ticker similarity creates another accounting boundary. Select the full asset listing rather than relying on a short symbol alone, especially when recording tokens issued on multiple networks. The confirmation screen should agree with the source record on asset name, ticker, quantity, transaction type, and timestamp before the entry is saved (covered in Coinmarketcap api ).

Buy, Sell, and Transfer choices determine the next balance change

The transaction form presents three choices because purchases, disposals, and movements have different accounting consequences. Coinmarketcap manual entries use the selected choice to decide whether quantity rises or falls and whether price information enters performance calculations.

A Buy record captures 6 practical data points: asset quantity, price per unit, date, time, fee, and note. The market price associated with the selected time provides a starting value, while the editable price field records the actual execution price. A Sell record needs the disposed quantity, sale price, timing, fee, and optional context. Transfer In and Transfer Out record movement without requiring an inception price.

The correct choice follows the economic event, not the screen from which the record is entered. Receiving SOL as a purchase belongs under Buy; moving existing SOL into a tracked venue belongs under Transfer In. If one portfolio already aggregates both the sending and receiving venues, an internal movement should leave its total quantity unchanged. Recording both transfer directions preserves that zero-net movement when separate venue records are desired.

Recorded quantity and market data produce the displayed totals

The portfolio engine updates holdings by adding buys and transfers in, then subtracting sells and transfers out. Saving an entry therefore changes the affected asset row, the aggregate balance, allocation, historical chart, and relevant performance fields.

Performance is divided into 2 categories: realized profit from recorded sales and unrealized profit on units still held. The published calculation sequence describes 7 measures: average buy price, cost basis, average buy cost, realized profit, unrealized profit, all-time profit, and profit-and-loss percentage. Average buy price excludes fees, whereas average buy cost includes purchase fees. Selling fees reduce realized profit.

Current value follows a separate mechanism: recorded holding quantity multiplied by the latest market price used by the portfolio. That explains why a correct quantity changes in fiat value even when no new transaction is entered. The 24-hour change describes a market window, while all-time profit incorporates the entered purchase and sale history. A Transfer record changes holdings and therefore unrealized value, yet it does not directly create a realized gain or loss.

Transaction details turn balance checks into a repeatable audit

The transaction-detail view provides the source rows needed to verify a portfolio total. Start with units rather than fiat value: compare the recorded BTC, ETH, SOL, or USDC quantity against the exchange account, wallet interface, or public ledger that holds it.

Binance and Coinbase provide account-level quantities, while MetaMask and Phantom display wallet holdings. Etherscan supplies an independent view of Ethereum addresses, and Solscan does the same for Solana addresses. These comparisons address quantity; the fiat total still moves with market data and update timing. One bitcoin equals 100 million satoshis, so a BTC balance may extend to 8 decimal places. Matching all significant digits prevents small residual amounts from disappearing during reconciliation.

The portfolio dashboard documents 4 historical windows: 24 hours, 7 days, 30 days, and 90 days. Its allocation view also offers 2 perspectives, by token and by chain. A quantity mismatch belongs in the transaction ledger; a short-lived fiat mismatch points to price timing or data refresh. Checking those layers separately keeps a correct entry from being changed merely because two screens sampled the market at different moments.

Editing the source row repairs a bad starting balance

A common setup error is recording an existing holding as a fresh Buy when it should begin as Transfer In. The Buy choice introduces an acquisition price and fee context, whereas Transfer In adds quantity without an inception value. That difference flows into average-cost and profit displays even when both choices add the same number of units.

The portfolio offers 2 direct repair paths: edit the incorrect transaction or remove it and enter a replacement. Open the affected asset, inspect its transaction details, and change the type, quantity, price, fee, or timing that caused the discrepancy. Deleting the entire asset is broader than necessary when only one row is wrong.

Coinmarketcap recomputes historical balance and allocation after a transaction changes, so the chart may update after the transaction list and current holding. The ledger mechanism explains the order: source rows change first, derived totals are recalculated next, and market-priced charts follow. No blockchain rollback occurs because the original action never left the portfolio database. Once the corrected holding matches its external quantity, cost and performance fields provide a consistent accounting view of that manual history.