Why most ledgers can't represent a wei
A wei is one ten-quintillionth of an ETH, and most ledgers will round it to zero. The fix isn't precision; it's a small set of decisions you have to get right before you start.
A wei is 1 / 10^18 ETH, the smallest unit of the second-most-traded asset on the planet. Ask a typical fintech ledger to store one, and it'll quietly reach for decimal(18,2) and round it to zero, and then nobody will notice for a fortnight.
This isn't really a precision problem. decimal(38,18) exists in every database that matters, and the maths has been solved for decades. The actual problem is that ledger codebases have twenty years of muscle memory built up around assumptions that no longer hold, and those assumptions are usually unwritten, undocumented, and baked deep into the type system where nobody thinks to look for them.
The four assumptions to unlearn
The first one is that money has two decimals, which it doesn't. USDC has six, ETH has eighteen, some Solana SPL tokens have nine, and others have zero. A ledger that bakes "two decimals" into its types is a ledger that will silently round customer balances, which is the worst possible failure mode because nobody notices until the auditor does, and by then you've usually been doing it for months.
The second is that a transaction has one currency. A swap is a single business event that touches two assets at two different precisions, and splitting it into two transactions across two ledgers loses the atomic guarantee that's the whole reason you're using a ledger in the first place. If your model can't express "this debit and that credit happened together or not at all", you don't really have a ledger; you have a journal with optimistic concurrency and a prayer.
The third is that fees are a separate concept. In on-chain land, the gas fee is the transaction. There's no separate "fee" entity to model, and the ledger has to express it as a posting against a fee account at the asset's native precision, alongside the value transfer it's paying for. Treating gas as out-of-band metadata is how you end up with a books-vs-chain reconciliation that's permanently 0.0001 ETH off and nobody can find the cause.
And the fourth is that reconciliation runs nightly. A blockchain is the world's most expensive append-only database, and if your internal ledger and your on-chain state disagree, you find out (at the latest) when the next withdrawal fails in front of a customer. Reconciliation has to be continuous, or it's broken.
What Ledga does
Ledga stores every balance as an i256 integer, scaled by the asset's declared precision, so 1 USDC is 1_000_000 and 1 ETH is 1_000_000_000_000_000_000. There are no floats anywhere in the hot path, because floats are how you accidentally lose a satoshi and spend the next three weeks explaining the discrepancy to the finance team.
Each posting is a tuple of (account, asset, amount), where the asset carries its precision and the amount is always the integer in that precision. Display formatting happens at the API boundary, not in the storage layer, which keeps the storage layer honest and means the only place you can introduce a rounding error is on the way out.
Every transaction is double-entry, atomic, and indexed by an idempotency key the caller supplies. We don't reimplement reconciliation per customer; we expose the ledger as the source of truth, and provide tooling to diff it against the external sources of truth that matter (chains, custodians, payment providers).
What we're not
Ledga isn't a chain, a wallet, or a settlement layer. It's the boring, correct database that sits underneath your money, and you build on top of it rather than expose it directly to your users. If your team has been hand-rolling a ledger because nothing existing speaks your assets' native precision, we built Ledga for you.