tally
rustearly development
a double-entry financial ledger: an append-only journal of immutable economic facts, and the correctness problems that come with it.
the problem
most systems that move money treat the ledger as a balance column and an UPDATE. that works until it doesn't, and when it doesn't, there is no record of why.
tally takes the opposite position: the ledger is an append-only log of immutable, self-consistent economic facts, and every balance is derived from it. this is not a novel idea, it is how bookkeeping has worked since Pacioli codified it in 1494. but it has real engineering consequences, and working through them carefully is the point of the project.
the interesting questions are things like: what happens when two transactions post concurrently against the same account? where exactly can a retried payment duplicate itself? what does "exactly once" actually mean when a broker is involved? how do you detect that your ledger and your payment processor have silently diverged?
why rust
the ownership model, the type system and explicit error handling make it possible to encode financial invariants such that violating them is a compile error rather than a production incident.
the crate's lint policy denies floating-point arithmetic project-wide and enables integer overflow checks in release builds. Money is an exact amount in i64 minor units plus a currency, with fallible arithmetic that surfaces overflow and currency mismatch instead of rounding or converting implicitly.
Currency is a closed enum carrying its ISO 4217 code and decimal scale, with all three real-world scales represented: JPY = 0, USD/EUR/GBP/BRL = 2, KWD = 3.
current status
worth being explicit: what exists today is the domain module holding the pure financial model, Currency and Money. nothing else. the repository states that on the first screen and makes no claim of production readiness.
the project is built in phases, and a phase does not start before the previous one is solid: domain (accounts, postings, transactions, double-entry validation, property tests) → persistence (postgresql, isolation levels, concurrent posting, immutable journal) → api → idempotency → events (transactional outbox) → reconciliation → production engineering → measured performance.
the reason for listing the roadmap here rather than hiding it is the same reason it is in the readme: a project about financial correctness that overstates its own state has already failed its premise.