CavalRe Ledger: Getting the Accounting Right
I often say:
Finance is 90% getting the accounting right.
Behind every payment, trade, or withdrawal are a few basic questions. Where are the assets? Who has a claim on them? Who is allowed to move them?
CavalRe Ledger is a standalone product that helps financial applications answer those questions. It holds digital assets and keeps the accounts that record how those assets are allocated. Its first implementation runs on Solana.
Ledger uses double-entry accounting, where every change has an equal debit and credit. It also introduces an accounting innovation: a tree of accounts whose debit and credit balances describe what exists now, all the way up to the total.
Here is what that means in practice.
One vault, many accounts
Imagine Alice deposits 100 USDC and Bob deposits 50 USDC into an application. USDC is a digital token designed to track the US dollar.
The application can hold all 150 USDC in one vault, with separate records showing Alice's 100 and Bob's 50. This arrangement is called omnibus custody. Assets share a home; the accounts keep track of each person's share.
Now Alice transfers 25 USDC to Bob inside the application. The vault still holds 150. Only the allocation changes: Alice has 75, and Bob has 75.
Then Bob withdraws 40 USDC to his wallet. Tokens leave the vault, and his internal balance falls by the same amount.
| After each step | Alice's balance | Bob's balance | USDC in the vault |
|---|---|---|---|
| Alice deposits 100 | 100 | 0 | 100 |
| Bob deposits 50 | 100 | 50 | 150 |
| Alice transfers 25 to Bob | 75 | 75 | 150 |
| Bob withdraws 40 | 75 | 35 | 110 |
The vault now holds 110 USDC, allocated as 75 to Alice and 35 to Bob. Those internal balances are claims on the tokens in the vault. Counting the tokens and the claims as separate wealth would count the same money twice.
Ledger handles the token movement and its accounting together. If a deposit or withdrawal fails, the whole operation rolls back.
Balances that describe today
There is a useful distinction between how much activity an account has seen and how much it holds now.
A common accounting approach keeps running totals of debits and credits. Each new entry adds to one of those totals, and their difference gives the account's balance. That works, but the totals grow with activity.
Across our example, the four operations involve 100, 50, 25, and 40 USDC. Cumulative debit and credit totals would each reach 215. Yet only 110 USDC remains in the vault.
Ledger gives every account both a debit balance and a credit balance, and maintains them as current positions. They can increase or decrease. For Alice, receiving money increases her debit balance; sending money reduces it. The matching credit side records the total outstanding claims.
After Bob's withdrawal, the total current debit balance is 110 and the total current credit balance is 110. Both measure the claims that still exist.
That is the accounting innovation at the heart of Ledger: carrying both sides of these current balances through an entire hierarchy of accounts.
From individual accounts to the whole picture
Think of accounts organized like folders. A business might have a Treasury group, with accounts for operating funds, reserves, and individual projects beneath it. A project could have further accounts of its own.
Each group shows the combined debit balances and the combined credit balances of its children. When an individual balance changes, the change travels up its branch of the tree. The kind of account at the end of that branch determines which side changes along the way.
Moving 25 from Alice to Bob changes their individual balances. If they belong to the same group, that group's total stays the same. Depositing or withdrawing changes the total as well.
The account at the top is called the root. Its two sides preserve this relationship:
Total Supply = Total Debits = Total Credits
Here, supply means the claims recorded in that asset's ledger. In our example, it is 110 USDC of claims. It does not mean the worldwide supply of USDC.
Because the root's debit and credit totals match, its net balance is zero. That means the books balance. The vault still contains 110 USDC.
When accounts are organized into a balance sheet, the familiar expression of this balancing principle is Assets = Liabilities + Equity: what a business owns is matched by the claims of its creditors and owners.
Ledger brings that discipline into a programmable service, with current balances visible at every level.
Clear accounts, clear control
Organizing accounts and being allowed to spend from them are separate responsibilities.
Each account has a controller that authorizes spending. That might be a person's wallet or an application following agreed rules, such as releasing an escrow payment when its conditions are met. Creating a group does not give someone permission to spend everyone else's balances beneath it.
Applications can create their own namespaces: separate spaces for their accounts and names. Two applications can each have an account called Treasury without sharing it. Each namespace has its own vault for each supported asset, and anyone can create one without CavalRe approving their application.
The assets remain ordinary Solana tokens. A standard wallet or token explorer can see the vault's holdings; showing Alice's individual share requires reading Ledger's accounts.
Those accounts are publicly readable. “Internal” describes where the accounting happens; it does not provide privacy (yet).
A foundation other applications can use
A treasury, an exchange, and an escrow service have different purposes. All need reliable records of assets, claims, and authority.
Ledger makes that shared work available as an independent product. Applications supply their own business rules and use Ledger for custody and accounting. It also supports accounting records without custody; creating those records cannot create a claim on tokens in a vault.
Ledger is the foundation on which we are building Multiswap and staking rewards. Other builders can use it independently for their own applications.
The goal is to give them a dependable answer to the questions we started with: where the assets are, how they are allocated, and who can authorize a change.
Current status: The independent Solana program is implemented and tested locally. Mainnet deployment and an independent audit remain outstanding. It supports selected Solana token configurations; a token's own restrictions, including the ability to freeze transfers, still apply.