Crypto wallets are software or hardware tools that store the private keys controlling on-chain digital assets — and the wallet type directly determines the custody classification, data source for the crypto subledger, and internal transfer detection logic that finance teams rely on for accurate record-keeping. Wallet knowledge is one of the 3 highest-impact domains for finance teams because wallet architecture affects every downstream accounting decision: where transaction data originates, how balances are verified, and whether a movement between addresses is a taxable event or an internal transfer.
Five wallet categories exist in practice: hot wallets, cold wallets, custodial wallets, non-custodial wallets, and institutional wallets (multisig and MPC). Each category carries distinct implications for data ingestion, reconciliation workflows, custody disclosure, and internal control design.
What Is the Difference Between Hot and Cold Wallets?
The difference between hot and cold wallets is internet connectivity — the first wallet classification within crypto fundamentals for finance teams. Hot wallets maintain a persistent connection to the internet for immediate transaction signing, while cold wallets store private keys offline and require physical access or air-gapped processes to authorize transactions.
Hot Wallets
Hot wallets include browser extensions (MetaMask), mobile apps (Trust Wallet, Coinbase Wallet), and exchange-hosted wallets. Because hot wallets are always connected, they generate real-time transaction data that the subledger can ingest continuously. Hot wallets typically account for 70-90% of an organization’s transaction volume because they handle day-to-day operations: trades, token approvals, DeFi interactions, and payment processing.
The accounting implication of hot wallet connectivity is data availability — transaction records appear on-chain within seconds, enabling near-real-time reconciliation. The trade-off is security: hot wallets are exposed to phishing, malware, and unauthorized access risks that require compensating controls (transaction limits, approval workflows, IP allowlisting).
Cold Wallets
Cold wallets include hardware devices (Ledger Nano X, Trezor Model T), air-gapped computers, and paper wallets. Private keys never touch an internet-connected device. Cold wallets serve as long-term storage for reserve holdings, treasury assets, and high-value positions.
Cold wallet transactions follow a batch pattern: the organization periodically moves assets from hot wallets to cold storage (or vice versa) in planned transfers. This batch pattern creates a distinct reconciliation profile — fewer transactions, larger amounts, and predictable transfer schedules that the subledger can validate against internal approval records.
| Attribute | Hot Wallet | Cold Wallet |
|---|---|---|
| Connectivity | Always online | Offline / air-gapped |
| Use case | Daily operations, trading, DeFi | Long-term storage, reserves |
| Data availability | Real-time on-chain | Batch, event-driven |
| Transaction volume | High (70-90% of activity) | Low (periodic transfers) |
| Risk profile | Phishing, malware, unauthorized access | Physical theft, device failure |
| Reconciliation pattern | Continuous matching | Batch correlation |
What Is Custodial vs Non-Custodial Custody?
Custodial custody means a third party (exchange, custodian, or financial institution) holds the private keys on behalf of the entity, while non-custodial custody means the entity retains direct control of its own private keys — a distinction that determines the data source, counterparty risk profile, and balance sheet disclosure requirements.
Custodial Wallets
Custodial wallets are accounts held at centralized platforms — Coinbase, Binance, Kraken, or institutional custodians such as Fireblocks, BitGo, and Copper. The platform generates and manages the private keys. Transaction data is extracted via API or CSV export from the platform’s reporting interface, not from on-chain records.
Custodial holdings introduce counterparty risk: if the custodian becomes insolvent, the entity’s assets may be at risk. FASB ASU 2023-08 requires fair value measurement for in-scope crypto assets, and SEC Staff Accounting Bulletin No. 121 (SAB 121) established specific disclosure requirements for entities that safeguard crypto assets on behalf of others. Organizations holding assets at custodians must evaluate concentration risk and disclose the custodial arrangement in financial statement notes.
Non-Custodial Wallets
Non-custodial wallets (MetaMask, Ledger, Trezor, Safe) give the entity sole control over private keys. No third party can freeze, seize, or move the assets. Transaction data comes directly from on-chain records — the subledger reads blockchain data to extract balances and transaction histories.
Non-custodial wallets eliminate counterparty risk but introduce operational risk: lost private keys mean permanently lost assets. Organizations using non-custodial wallets require key management procedures, backup protocols, and succession planning as internal controls.
| Attribute | Custodial | Non-Custodial |
|---|---|---|
| Key holder | Third-party platform | Entity itself |
| Data source | Platform API / CSV | On-chain blockchain data |
| Counterparty risk | Yes — custodian solvency | No |
| Operational risk | Platform-managed | Entity-managed (key loss) |
| Regulatory treatment | Subject to custodian reporting (DAC8, CARF) | Self-reported |
| Reconciliation method | API record matching | On-chain event decoding |
How Do Multisig and MPC Wallets Work?
Multisig and MPC wallets are institutional wallet types designed for multi-party authorization — requiring multiple approvers to sign a transaction before it executes, which creates distinct on-chain and off-chain data patterns that affect how the subledger ingests and categorizes each transaction.
Multisig Wallets
Multisig (multi-signature) wallets such as Safe (formerly Gnosis Safe) implement M-of-N approval logic on-chain: a transaction requires M out of N designated signers to submit approval transactions before the final transaction executes. A 3-of-5 multisig requires 3 separate signer transactions.
Each signer approval is a separate on-chain transaction that consumes gas. A single business event — such as transferring 10 ETH to a vendor — generates M+1 on-chain transactions (M approvals + 1 execution). The subledger must group these related transactions into a single accounting event and allocate gas fees across the approval chain.
MPC Wallets
MPC (Multi-Party Computation) wallets such as Fireblocks and BitGo use cryptographic key sharding: the private key is split into encrypted fragments distributed across multiple parties. Signers compute their portion of the signature independently, and the fragments combine into a single valid signature — all off-chain. The blockchain sees one standard transaction.
MPC wallets produce cleaner accounting records because the approval workflow happens entirely off-chain. The subledger ingests one on-chain transaction with standard gas costs, and the custody platform’s API provides the approval metadata (who approved, when, policy rules triggered) as supplementary audit trail data.
How Does Wallet Type Affect Reconciliation?
Wallet type affects reconciliation by determining 3 variables: the data source (API, on-chain, or hybrid), the matching keys used to pair records (transaction hash, internal ID, or amount-timestamp correlation), and the exception rules for detecting anomalies.
| Wallet Type | Data Source | Matching Method | Common Exceptions |
|---|---|---|---|
| Exchange custodial | Platform API | Internal trade ID | Missing API records, delayed settlement |
| Self-custodial hot | On-chain events | Transaction hash | Unrecognized contract interactions |
| Cold storage | On-chain events | Batch transfer correlation | Unexpected movements, device compromise |
| Multisig (Safe) | On-chain + Safe API | Grouped tx hash | Orphaned approvals, partial signing |
| MPC (Fireblocks) | On-chain + custody API | Transaction hash + policy ID | Policy override, pending approvals |
Internal transfer detection is the highest-impact reconciliation function tied to wallet architecture. When an organization controls multiple wallets, transfers between those wallets must be identified and excluded from gain/loss calculations — a transfer is not a disposal event.
How Do Wallet Addresses Map to the Chart of Accounts?
Each wallet address (or group of addresses under a single custody arrangement) maps to a sub-account within the digital asset holdings section of the chart of accounts — enabling per-wallet balance tracking, custody-level reporting, and granular reconciliation at the address level.
A typical chart of accounts structure for an organization with 4 wallets:
- 1200 — Digital Asset Holdings
- 1201 — Hot Wallet (MetaMask 0xABC…)
- 1202 — Cold Storage (Ledger — bc1QXY…)
- 1203 — Exchange Account (Coinbase)
- 1204 — Treasury Vault (Fireblocks)
Transfers between wallets controlled by the same entity are reclassification entries — no gain or loss is recognized:
| Account | Debit | Credit |
|---|---|---|
| Cold Storage — ETH Holdings | $20,000 | — |
| Hot Wallet — ETH Holdings | — | $20,000 |
Deposits from external sources create acquisition or income entries depending on the transaction type:
| Account | Debit | Credit |
|---|---|---|
| Exchange Account — USDC Holdings | $10,000 | — |
| Revenue — Crypto Payments | — | $10,000 |
Blockchain address formats determine the data ingestion pathway: Bitcoin addresses (bc1… for native SegWit, 3… for P2SH) route to the Bitcoin node adapter, Ethereum-compatible addresses (0x…) route to EVM chain adapters (Ethereum, Polygon, Arbitrum, Base), and Solana addresses (base58 format) route to the Solana adapter. The crypto subledger’s address registry automates this routing, mapping each address to the correct blockchain, wallet label, and chart of accounts sub-account.