Every crypto exchange shows each customer a balance for every asset they hold. Behind that single number sits a ledger: a permanent, ordered record of the movements that produced it. The balance and the ledger are not the same object, and treating them as interchangeable is one of the most consequential design mistakes an exchange can make. The balance is a view. The ledger is the record.
The distinction matters to different readers for different reasons. For a chief executive it is the difference between an exchange that can always explain where customer funds are and one that cannot. For a technology leader it is a decision about which component is authoritative and which is merely derived. For a compliance or finance function it is the basis on which customer holdings are reconciled, reported and evidenced. This article sets out the distinction at a conceptual and architectural level. It is not a database schema or an implementation recipe.
Ledger and Customer Balance Defined
A ledger is an append-only record of every credit and debit that affects customer or exchange funds: deposits, trades, fees, withdrawals, internal transfers and controlled adjustments. Each entry is timestamped, attributed to a cause, and never altered once written. A customer balance, by contrast, is the amount a given customer sees and can act on for a specific asset at a specific moment. It is a computed summary of ledger entries, not an independent fact that exists on its own.
Put simply, the ledger records what happened and the balance describes where that leaves the customer now. The ledger is a history of causes; the balance is a snapshot of the current state. Because the balance is derived, it can always be recomputed from the ledger. Because the ledger is authoritative, it can never be reconstructed from a balance alone. That asymmetry is the whole point, and it should shape how the platform is built.
Why the Ledger Is the Source of Truth
The ledger is the source of truth because it records causes rather than only the current state. A stored balance is a single number that can be overwritten, corrupted or allowed to drift, and once it is wrong there is nothing inside it that explains why. A ledger of movements can always be replayed to recompute any balance, and it can be examined entry by entry to answer the question that eventually arrives from an auditor, a regulator or a customer: why is this figure what it is.
Double-entry discipline reinforces this. Every movement has matching sides, so value is never created or destroyed by accident, and the sum of customer holdings can be traced to real deposits and trades. Corrections are handled as new compensating entries rather than edits to old ones, which preserves the full history. An exchange whose balances are authoritative and whose ledger is a report generated afterwards has the relationship backwards, and will struggle the moment those two numbers disagree.
Note: The test of a sound design is simple. If every stored balance were deleted, could each one be reconstructed exactly from the ledger of movements? If yes, the ledger is authoritative and the balance is a cache. If no, the platform depends on a mutable number that nothing can verify, and reconciliation becomes guesswork rather than proof.
How a Customer Balance Is Derived
A customer balance for an asset is, in essence, the sum of that customer's ledger entries in that asset. In a healthy design the displayed balance is either computed directly from the ledger or held as a cache that can be rebuilt from it at any time. High-throughput platforms often keep a materialised balance for speed, because recomputing from history on every read would be expensive, but the cache remains a convenience rather than the truth.
The rule that keeps this safe is direction of authority. When the cached balance and the ledger-derived balance disagree, the ledger wins and the cache is corrected, never the other way around. This is what allows an exchange to run quickly in normal operation and still fall back to an unambiguous answer when something looks wrong. A platform that lets an isolated balance counter diverge from the ledger, and then trusts the counter, has quietly abandoned its own source of truth.
Available, Locked and Total Balances
A single figure is rarely enough to describe what a customer actually holds. A total balance is everything recorded for that asset. An available balance is what the customer can withdraw or trade at this instant. A locked or reserved balance is the portion committed elsewhere: quote currency held against an open buy order, an asset reserved against a pending withdrawal, or funds placed under a hold. Deposits still waiting for network confirmations are recorded but not yet spendable.
This is where the view and the record meet in practice. Placing an order should reserve funds, cancelling it should release them, and a withdrawal request should move value from available to reserved before it settles. Each of those reservations is best treated as a ledger-visible event in its own right, so that available, locked and total always reconcile to the same underlying history. When holds live only in application memory or a side table that the ledger does not see, the numbers drift and disputes become impossible to resolve cleanly.
| Concept | What it represents | Relationship to the ledger |
|---|---|---|
| Total balance | Everything the customer holds in an asset | Sum of all confirmed ledger entries for that customer and asset |
| Available balance | Amount that can be traded or withdrawn now | Total minus active reservations, each of which is a ledger-visible event |
| Locked balance | Funds committed to open orders, withdrawals or holds | Reservations recorded and released as movements, never as hidden state |
| Pending deposit | Incoming value awaiting network confirmation | Recorded as received but not yet counted as spendable |
Reconciliation Against Chain and Bank
An internal ledger is only trustworthy if it agrees with the outside world. What the ledger says the exchange holds must be reconciled against what custody actually holds: on-chain wallet balances for crypto assets and fiat accounts at a bank or e-money partner. Reconciliation compares these continuously and treats any difference as a break to be investigated rather than a figure to be quietly adjusted into agreement.
Reconciliation is a control, not an occasional clean-up. A difference between recorded and actual holdings can indicate a missed deposit, a processing error, a duplicated withdrawal or something that needs escalation, and the ledger is what makes the investigation possible because every expected movement is already written down. The engineering detail of how a reconciliation process is built sits outside the scope of a decision-maker's overview, but the principle does not: external reality and the internal ledger must be kept in demonstrable agreement.
Change Control, Audit and Integrity
The most sensitive movements on any exchange are manual adjustments: corrections, goodwill credits, write-offs and the resolution of reconciliation breaks. These must never be a back-office action that edits a balance directly and leaves no trace. Each adjustment should be an authorised, attributed and reason-coded ledger entry, subject to segregation of duties so that the person who requests a change is not the only person who can approve it.
This is what makes a ledger genuinely auditable. Every figure a customer sees should trace back to entries, and every entry should trace back to an actor and a cause. An exchange that can produce that chain on demand can answer questions from auditors, regulators and customers with evidence rather than assertion. One that relies on editable balances and undocumented corrections has no such chain, and discovers the gap at the worst possible moment.
UK and EU Expectations
Accurate records and regular reconciliation are not only sound engineering; they align with regulatory expectations in both of Grumpio's core markets. In the United Kingdom, firms handling cryptoassets are expected to keep accurate books and reconcile customer holdings, and registration under the Money Laundering Regulations is a financial-crime gateway rather than full authorisation. The incoming FSMA cryptoasset regime raises those expectations further, so a ledger built for evidence is a sound investment well before the rules apply in full.
In the European Union the position is settled. The MiCA transition has ended. New EU cryptoasset projects must be designed for an authorised CASP operating model from the beginning, and the safeguarding of client assets together with orderly record-keeping sits at the centre of that model. We do not provide legal opinions or guarantee authorisation. We implement regulatory and audit requirements across technology, infrastructure and operations. A platform whose balances always reconcile to an auditable ledger is far better placed to meet these requirements than one that cannot explain its own numbers.
Building, Buying and Evaluating
Whether an exchange is being built in-house, procured as a white-label platform or licensed as source code, the questions are the same and they cut past the dashboard. Is the ledger the source of truth, or is it a report generated from a mutable balance table? Can any balance be reconstructed exactly from entries? Are reservations, holds and pending deposits first-class ledger events? Are manual adjustments authorised, attributed and recorded as movements rather than edits?
These questions matter more than the appearance of the customer interface, because a polished balance display built on an unverifiable number is a liability that only becomes visible under stress. Evaluating a provider on the integrity of its ledger model, its reconciliation approach and its change controls is a more reliable signal of quality than any feature list. For a wider view of how these components fit an exchange platform, the crypto exchange software overview and the regulatory readiness pages set the surrounding context.
Summary and Next Steps
The customer balance is a view and the ledger is the record, and an exchange should be designed so the number a customer sees always traces to the entries that produced it. The ledger stays authoritative, balances are derived and reconstructable, reservations and holds are visible movements, and reconciliation against on-chain and bank holdings is continuous. Adjustments are controlled and audited rather than quietly applied. Read together, these choices are what separate an exchange that can always account for customer funds from one that hopes its numbers are right. Region-specific expectations are covered further on the United Kingdom and European Union readiness pages.
Make the ledger the single answer to where funds are. Grumpio builds crypto exchange platforms where balances are derived from an auditable ledger, and reservations, reconciliation and adjustments share one controlled record.