How We Build Calculators

Last updated: 25/08/2026

CryptoCalk calculators are deterministic tools: outputs are generated from explicit formulas plus user input values. This page outlines our methodology, data inputs, and limitations.

1. Core Approach

• Define domain formula (profit, ROI, liquidation, compounding, etc.).
• Normalise all inputs into consistent units.
• Compute outputs client-side in real time.
• Display key assumptions next to results.

2. Data Sources

Two kinds of numbers enter these calculators, and they are maintained in completely different ways.

Live market data

Prices, network difficulty and mining yields are fetched at page load. Prices come primarily from CoinGecko; mining yields are cross-checked against WhatToMine. Client requests are cached and deduplicated in-browser. These values are as fresh as the upstream API and are never hand-edited.

• CoinGecko API Documentation

Regulatory and protocol constants

Tax rates, holding-period thresholds, inheritance allowances and protocol facts cannot come from a price API — they come from law and from consensus rules. CryptoCalk tracks 101 such constants (79 regulatory across 17 jurisdictions, plus protocol and formula values) in a versioned ledger, each with the primary source it was verified against and the date of that verification.

The standard is to read the primary source, not a summary of it. Examples of what that means in practice:

• Portugal's 28% rate and 365-day exclusion are read from the consolidated Código do IRS itself (art. 72.º n.º 1 al. c) and art. 10.º n.º 22) — not from a tax-guide blog.
• Australian resident bands come from the ATO's own rate tables; Germany's income and inheritance figures from the statutory texts of EStG §32a and ErbStG §16/§19.
• Canada's 50% capital-gains inclusion is taken from the Income Tax Act s.38; Japan's inheritance bands and filing rules from the NTA; Brazil's progressive 15–22.5% from Lei 8.981.
• Protocol facts are read from the protocol: the 546-satoshi dust threshold comes from Bitcoin Core's policy.cpp, and mining block rewards are reconciled against on-chain coinbase outputs.

Which source backs which jurisdiction

That standard is met for most, but not all, of what we track — so here is the ledger itself rather than a claim about it. The Source of record column is the page a human re-reads when the monitor flags a change, and the tier is derived from that page's host, not asserted by hand. Where a row still reads secondary guide, the value on the site may well be correct, but it has not yet been traced back to the statute; those 12 of 17 jurisdictions are the current re-verification queue, and saying so here is more useful than claiming a standard we have not finished applying.

statute = a tax authority, ministry or statute database ·protocol = the chain's own specification or client source ·secondary = a tax-guide or news article, usable as a tripwire but not as a source of record.

“Last verified” shows only dates we actually recorded as an ISO date during a verification pass; a dash means the value carries over from the initial audit without an individually dated re-check, not that it is known to be stale.

Protocol constants

These do not come from law at all — they come from consensus rules, so the source of record is the chain's own specification, client source or improvement proposal.

How those constants are kept current

An automated monitor re-reads every tracked source page on a schedule and flags any that changed. A flag is never applied blindly: each flagged value is re-verified against the primary source by hand before a single number moves. Calendar-driven changes that no page-watcher can see — a halving, an emission-era rollover, a tax year starting on 1 July — are tracked as scheduled dates instead.

Every change that reaches the site is dated in the ledger and published in the changelog. Verification that finds nothing wrong is also recorded, so "checked and unchanged" is distinguishable from "never checked".

Corrections we have published

This process exists because we have found real errors in our own numbers. Rather than quietly patching them, we record them:

• Dash mining revenue was overstated 4×. Our fallback block reward held the full in-block coinbase, but a Dash miner receives only 25% of it (masternodes and the treasury take the rest). Found by reading coinbase outputs on-chain, corrected, and the same class of bug then checked across every coin — which also caught Zcash (dev fund) and Ethereum Classic (a missed emission era).
• A Japanese inheritance estimate was ~3× too high. The calculator applied one band rate to the whole estate; Japan's statutory method splits the estate into per-heir shares, taxes each share, then sums. Rewritten to the NTA's method and checked against the NTA's own worked example.
• A Kaspa block reward was 10× too low — a per-second emission figure had been recorded as a per-block reward.

If you find a number you believe is wrong, tell us and include the source you are comparing against; that is how several of the above were caught.

3. Formula Families

Profit and ROI

Used in Profit Calculator, ROI Calculator, and related tools:

• Profit = Exit Value - Entry Value - Fees
• ROI (%) = Profit / Total Cost × 100

DCA and Historical Scenarios

Used in DCA Calculator and What If Calculator:

• Periodic buys are simulated over selected date ranges.
• Average buy price and current valuation are derived from aggregated purchase points.

Risk and Margin Tools

Used in Position Size, Liquidation, and Margin:

• Risk-per-trade values are mapped to stop distance and account size.
• Leverage and maintenance constraints are modelled with exchange-style logic where applicable.

4. Validation Workflow

• Known-value tests against manual spreadsheet calculations.
• Edge-case checks: zero values, negative outcomes, extreme percentages.
• UI validation for input bounds and formatting.
• Build-time verification before publishing.

5. Known Limitations

• Exchange execution differs from theoretical values (slippage, spread, funding timing).
• Tax treatment can vary by jurisdiction and account structure.
• Market conditions can change faster than API refresh cadence.
• Inheritance tax, currency: the inheritance calculator asks for a portfolio value in USD but applies each country's thresholds in that country's own currency (yen, euro, pound). For a rough comparison this is fine; for a real estate near a threshold, convert to the local currency first.
• Inheritance tax, Japan: heirs are assumed to take equal statutory shares, and the spouse tax credit (配偶者の税額軽減) is not modelled — both can materially reduce a real liability.
• Announced-but-not-yet-in-force changes are not applied early. Where a change has a known start date (for example an Australian band stepping down on 1 July 2027), the current-year figure is used until that date arrives.

6. How to Use Outputs Correctly

Treat calculator outputs as planning estimates, not guarantees. For robust decisions, cross-check with at least one supporting tool (for example: profit + tax, or position size + liquidation).