Skip to main content
Back to Home
Transparency

Statement Methodology & Definitions

How CryptoBankStatement reconstructs, values and reconciles wallet activity from public blockchain data.

Overview

This statement is generated using publicly available blockchain data retrieved in read-only mode. Blockchain data retrieval uses public blockchain information and does not require private keys or a wallet connection. Optional wallet-control verification, when requested, requires the customer to authorise a cryptographic message signature. That signature does not transfer funds and does not disclose private keys. It establishes control of the address at the time of signing. It does not prove legal ownership or historical ownership. CryptoBankStatement applies accounting discipline to that data: exact native-asset amounts, historical fiat valuation, and native-asset reconciliation before a statement is shown as reconciled.

Native accounting

Authoritative accounting is performed in exact native blockchain units. Formatting into decimal display amounts happens after those calculations.

ETH

Reconciled in exact wei.

BTC

Reconciled in exact satoshis.

USDC / USDT

Reconciled in exact token base units for the relevant contract and decimals.

Displayed decimal amounts are a presentation layer. They do not replace the integer/base-unit calculations used for reconciliation.

Data Sources

Source: Public blockchain data (read-only access)

Networks Supported:

  • Bitcoin — BTC on Bitcoin mainnet
  • Ethereum mainnet — ETH, plus ERC-20 USDC and USDT only
  • Base mainnet — official Circle USDC only. Native ETH and USDT on Base are not included.

USDC and USDT on Solana, Polygon, Arbitrum and other networks are not included. Native ETH and USDT on Base are not included. Other ERC-20 tokens are not included. Exchange accounts are not included.

Ethereum data is retrieved from Etherscan (account transaction lists, including internal transactions) and Alchemy (historical balances, transaction receipts, and supporting transfer queries), in read-only mode. Bitcoin data is sourced from public Bitcoin APIs. No custodial or exchange data is included. Official Base USDC is retrieved from Alchemy on Base mainnet for contract 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913. Base USDC does not use Etherscan. Transaction links use Basescan.

Balance Definitions

Opening Balance

The blockchain balance immediately prior to the selected statement start.

  • Native Ethereum: independently queried using eth_getBalance at the historical boundary block immediately before the selected period.
  • ERC-20 (USDC, USDT): independently queried at the corresponding historical boundary block using the token contract's balanceOf method.
  • Bitcoin: derived from confirmed address activity and UTXO accounting up to the statement boundary.

Closing Balance

The wallet balance at the end of the selected period, after all transactions and network fees within the period have been applied.

Balance Reconciliation

Native-asset reconciliation uses the asset-specific identity. ETH: Opening Balance + Money In - Money Out - Fees +/- Adjustments = Closing Balance. Bitcoin: Opening Balance + Money In - Money Out - Fees = Closing Balance. USDC/USDT: Opening Balance + Money In - Money Out = Closing Balance. Native ETH reconciliation uses exact integer wei. Bitcoin uses exact integer satoshis. ERC-20 USDC/USDT uses exact integer token base units. These integer values are used for accounting before decimal formatting is applied for presentation. Fiat valuation is independent of native-asset reconciliation and does not determine whether the blockchain balance reconciles.

ETH transaction handling

  • Normal incoming and outgoing ETH transfers are included according to their confirmed on-chain effect.
  • Gas fees are accounted for separately rather than being hidden inside transfer amounts.
  • A reverted Ethereum transaction can still consume gas; that fee is still an on-chain effect.
  • Internal native ETH balance movements are included where they change the wallet's ETH balance.
  • Smart-contract credits and debits are included according to the native ETH balance effect, not as a semantic classification of every DeFi action.

CryptoBankStatement does not claim to interpret the commercial meaning of every smart-contract interaction. It accounts for the native ETH balance effect that can be established from supported blockchain data.

Bitcoin

  • Bitcoin statements use UTXO accounting for the exact address entered.
  • Amounts are accounted for in exact satoshis.
  • When the statement address provides all inputs, the full miner fee is attributed to that address and labelled Network Fee.
  • When a transaction contains inputs from multiple addresses, an allocated network fee is used for address-level accounting according to the documented method. That allocated share is not the total miner fee of the containing Bitcoin transaction.

Base USDC

  • Base Mainnet, chain ID 8453.
  • Official Circle-issued USDC only, contract 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913, 6 decimal places. Transfers are filtered to that contract.
  • Base ETH, Base USDT, bridged USDbC and other Base tokens are not included. Native ETH statements are not offered on Base.
  • Transfer history is retrieved from Alchemy on Base mainnet for that contract.
  • A completeness check re-derives raw ERC-20 Transfer events with eth_getLogs for that contract over the statement block range and compares them at exact base-unit and event identity.
  • Opening and closing balances are independent historical balanceOf reads on that contract.
  • Reconciliation uses exact integer token base units: Opening Balance + Money In − Money Out = Closing Balance. Transfer fees are paid in ETH and are not subtracted from the USDC token ledger.
  • Historical fiat values use the USDC historical closing price for the applicable UTC valuation date. Fiat figures do not decide whether the token balance reconciles.
  • Transaction references link to Basescan. A Base statement does not include Bitcoin or Ethereum activity.

ERC-20 completeness

For supported ERC-20 tokens (USDC, USDT), an additional check re-derives the period's Transfer events from raw Ethereum Transfer logs over the exact statement block range and compares them, at exact base-unit and event-identity granularity, against the Transfer events in the statement.

  • This complements balance reconciliation by catching missing or mismatched Transfer events even when net opening-to-closing balances still reconcile.
  • It is an independent retrieval-path cross-check using the same blockchain data provider — not a second, separate data provider.
  • A mismatch, or an inability to establish complete coverage, marks Transfer activity for review; it does not, on its own, mean the balances failed to reconcile.

Transaction Processing

Ordering: Confirmed transactions are ordered by blockchain confirmation position. Bitcoin uses block height, then transaction position within the block. Ethereum uses block number and log index. Running balances follow this canonical order. Same-block Bitcoin transactions that share a block timestamp are not ordered by transaction-id lexicography.

Network Fees: Network fees (gas fees for Ethereum, transaction fees for Bitcoin) are shown as separate line items and deducted from balances. Bitcoin miner fees are defined at the transaction level rather than per input address. Bitcoin does not assign fee portions to individual addresses or inputs. When the statement address provides all inputs, the full network fee is attributed to that address and labelled Network Fee. When a transaction contains inputs from multiple addresses, CryptoBankStatement allocates a proportional share (round_half_up(actualTransactionFeeSats × addressInputSats ÷ transactionTotalInputSats), integer satoshi arithmetic) for address-level accounting. That allocated share is labelled Allocated Network Fee and is not the total miner fee of the containing Bitcoin transaction. The underlying total transaction fee remains on-chain derivable as total inputs minus total outputs.

Contract Interactions (Ethereum): For Ethereum-based assets, token deposits and withdrawals may involve smart contract calls. Fee adjustments are applied where necessary to avoid double-counting. Native Ethereum activity includes wallet-originated transactions even where the transaction transfers zero ETH, because such contract calls may still consume gas. Transaction-history coverage is checked against the selected block range and supporting on-chain signals; an unexplained balance or nonce movement is not treated as complete activity.

All transactions are included based on confirmed blockchain data. Pending or unconfirmed transactions are excluded.

Historical fiat valuation

Historical Pricing: Fiat values (GBP, USD, EUR, AED, INR) are estimates based on historical closing market prices for the applicable UTC valuation date. Each activity row uses the historical closing price for that transaction's UTC calendar date. Opening-balance fiat uses the previous UTC calendar day's close, because the opening balance is the on-chain amount immediately before 00:00:00.000 UTC on the statement start date. Closing-balance fiat uses the selected end date's historical close, because that entire UTC day is included in the period. All configured report currencies use the same historical pipeline; a current market price is never substituted.

  • Transaction activity uses the historical closing price for the transaction UTC calendar date.
  • Opening-balance fiat uses the previous UTC calendar day's close, because the opening balance is the on-chain amount immediately before 00:00:00.000 UTC on the statement start date.
  • Closing-balance fiat uses the statement end-date historical close, because that entire UTC day is included in the period.
  • Supported report currencies are GBP, USD, EUR, AED and INR.
  • Fiat amounts are derived estimates. They do not change native-asset reconciliation.
  • A current or spot market price is never substituted for an unavailable historical close.

Blockchain vs fiat: On-chain balances are authoritative. Historical fiat figures do not themselves satisfy native-asset reconciliation identities, because market prices change over time. Historical fiat figures do not themselves satisfy native-asset reconciliation identities such as Opening Balance + Money In - Money Out - Fees +/- Adjustments = Closing Balance, because market prices change over time. These estimates are not independently bank- or audit-certified.

Limitations: Fiat valuations are for informational purposes only and do not constitute financial or tax advice. Actual market prices may vary.

Fail-closed behaviour

If required blockchain history cannot be established reliably, or required historical closing prices cannot be retrieved for the applicable UTC valuation dates, CryptoBankStatement does not silently substitute a current price or knowingly issue a partial statement. Incomplete, malformed or missing required data prevents generation rather than causing a silent fallback.

Is CryptoBankStatement crypto tax software?

No. CryptoBankStatement is designed for financial documentation rather than crypto tax calculation. Tax software is built to calculate gains, losses, disposals and filing figures. CryptoBankStatement reconstructs supported self-custody wallet activity into a reconciled statement.

Does CryptoBankStatement issue a bank statement?

CryptoBankStatement is not a bank and does not issue regulated bank statements. It generates statement-style financial records from supported public blockchain wallet data.

Document integrity

An issued statement can carry a Statement Data Hash, a verification URL and a QR code that opens that URL. A reviewer can use them to check that the recorded statement data matches the issued verification record. The hash does not oblige a bank, lender or other institution to accept the document, and it does not certify the legal effect of the underlying activity.

Verification

A generated statement can include three separate evidence layers. They must not be collapsed into a single "verified" claim.

On-chain statement

Reconstructed public blockchain activity, native-asset reconciliation, historical fiat estimates, and statement integrity metadata.

Wallet-control verification

When requested, the customer authorises a cryptographic message signature. The signature does not transfer funds and does not disclose private keys. It establishes control of the address at the time of signing. It does not prove legal ownership or historical ownership. A Bitcoin P2SH-P2WPKH compatibility signature is not a BIP-322 v2 Simple or Full signature.

Identity verification

Where selected, identity is verified through Stripe Identity. Identity verification is not source-of-funds clearance, AML clearance, or a guarantee of institutional acceptance.

  • Wallet control is not legal ownership.
  • Identity verification is not source-of-funds clearance.
  • Reconciliation is not audit certification.

Timezone & Dates

Timezone: All timestamps are displayed in UTC (Coordinated Universal Time) unless otherwise specified.

Date Format: Date formatting may vary based on selected statement format (International, UK, US, EU, UAE) but does not affect calculations or included transactions.

Statement Format

Statements can be generated in multiple formats (International, UK, US, EU, UAE) which control:

  • Date formatting (YYYY-MM-DD, DD/MM/YYYY, MM/DD/YYYY)
  • Minor wording differences (e.g., “Closing Balance” vs “Ending Balance”)

Format selection affects presentation only and does not change calculations, included transactions, or statement content.

Scope & Limitations

Single Wallet, Single Asset: Each statement covers one wallet address and one asset (e.g., BTC, ETH, USDC, or USDT) per statement period.

Self-Custody Only: Statements are designed for self-custody wallets (e.g., MetaMask, Ledger, hardware wallets). Exchange and custodial wallets are not supported.

Statement history: Statements are available for activity within the most recent 36 months, up to the latest completed UTC day. This is a rolling window from the current UTC date, not a stored copy of your blockchain history.

Transaction Volume: For accountant readability, statements are limited to 2,500 transactions per period. High-activity wallets (lifetime activity above 50,000 transactions) are not supported as they typically belong to exchanges or service providers rather than personal users.

Important Information

Not Tax Advice

This statement is provided for informational purposes only and does not constitute tax, legal, accounting, or financial advice. Consult a qualified professional for guidance on your specific situation.

No Regulatory Approval

This service is not regulated, approved, or endorsed by any financial authority, tax authority, or government agency. Generated statements are not official documents.

Acceptance

We do not claim or guarantee that banks, accountants, auditors, or any other third parties will accept these statements. Acceptance is at the sole discretion of the recipient.

User Responsibility

Users are responsible for verifying the accuracy of generated statements and ensuring compliance with applicable laws and regulations in their jurisdiction.

Questions?

This methodology is provided for transparency and clarity. Related reading: how wallet statement reconciliation works, Ethereum USDC wallet statement, wallet-control verification, and how this differs from crypto tax software.

Last updated: September 2026