How the Zcash acquisition average is calculated
The moving-average ledger, daily USD price inputs, transaction selection rules, and verification limits behind ZEC Buying Price.
ZEC Buying Price estimates the average acquisition price of selected confirmed wallet movements. It uses a moving-average ledger in USD. That selected ledger is distinct from your actual wallet balance.
Receipts add quantity and value
A selected confirmed receipt adds its ZEC quantity and its acquisition value: quantity multiplied by the historical or manually entered USD price per ZEC. The new average is the accumulated acquisition value divided by remaining quantity.
Sends remove value proportionally
A selected send removes quantity and acquisition value at the average immediately before that send. The send does not change the average price of the remaining holdings. A later receipt can change the average again.
For example, 2 ZEC acquired at $40 and 1 ZEC acquired at $70 produce a $50 average. Sending 1 ZEC leaves 2 ZEC with $100 of acquisition value. These are illustrative inputs. See the full worked example.
What counts in the current ledger
- Selected confirmed receipts and sends contribute to the calculation.
- Pending movements are excluded.
- Network fees are visible in tooltips and do not form purchases.
- Ownership-based self-transfers and change are excluded where identified.
- Movement quantities use exact zatoshis.
- Manual choices persist across rescans and restarts.
Price provenance
The app uses a CoinGecko daily USD observation for each movement’s UTC date. Requests are cached per day and throttled. A daily observation is a market estimate, not an exchange purchase record. A manual override can supply an actual acquisition price. Public API historical access is limited; older dates may require paid access or manual input.
Conditions that prevent a complete result
The full average is withheld until synchronization and required receipt pricing finish. Missing prices, selected sends exceeding selected holdings, or ambiguous history reconciliation also prevent completion. Deselecting an early receipt can make a later selected send inconsistent.
Verified behavior and open work
The native executable builds and launches. The repository reports 18 passing tests covering accounting and selected SDK integration behavior, including a real view-only import, scan progress, and pause. Complete receipt/spend scanning, interruption/resume, and controlled reorg behavior remain under verification. The available download is a development build.
This moving-average implementation is not a jurisdiction-specific tax method selector. The application does not generate tax reports or reconstruct exchange fills.