Written once.
Never rewritten.
Every movement of money on this platform appends one permanent row: what moved, why it moved, and the balance that followed it. Nothing is edited and nothing is deleted, which is the only reason the history can be trusted at all.
- Rows
- Append-only, never edited
- Each row carries
- The balance after it
- Re-proved
- Nightly, platform-wide
What changes
A balance you can explain, line by line.
Most sellers can tell you what is in the account. Very few can tell you how it got there. The difference between those two is a business you can borrow against and one you cannot.
Without it
- A number in an app, with no story behind it
- A notebook that disagrees with the bank
- Corrections made by overwriting the old figure
- “Where did that ₦12,000 go?” is unanswerable
With Traxease
- A number with a row behind every kobo of it
- One record, re-proved against itself every night
- A correction is a new row, so the mistake stays visible
- “Where did that go?” is a line you can point at
Try to break it
Go on — edit a row.
This is a ledger tape behaving exactly like the real one. Try to change a figure or remove an entry. It will not let you, and it will show you what it does instead.
wallet_transactions
4 rows · append-only
- #0001Sale12 Mar · 09:14
Order TRX-1042
+₦45,000
balance ₦45,000
- #0002Sale12 Mar · 16:40
Order TRX-1043
+₦28,500
balance ₦73,500
- #0003Withdrawal14 Mar · 11:02
To 0123456789
−₦30,000
balance ₦43,500
- #0004Commission14 Mar · 11:02
1% on withdrawal
−₦300
balance ₦43,200
Every night this tape is re-added from row #0001 and compared to the stored balance. One kobo of disagreement fails the run.
The refusal is the product. In the real ledger a correction is a new row, never an overwrite.
How it works
Why the arithmetic cannot drift.
Four properties, each enforced by the code rather than by a habit. Hover a step to follow the thread.
The balance and its reason are one write
A wallet balance never changes on its own. The change and the row explaining it are written inside a single database transaction with the wallet row locked, so a crash halfway through leaves neither.
Every row carries its own proof
Each entry stores the balance that existed immediately after it. You never have to trust a running total computed later — the row itself says where the wallet stood at that moment.
Retries cannot double-count
Movements carry an idempotency key. Payment providers retry confirmations as a matter of course; the second delivery of the same event finds its key already recorded and writes nothing.
The whole platform is re-added nightly
A scheduled job walks every wallet, re-adds every row from the beginning, and compares the result to the stored balance. A single kobo of disagreement fails the run loudly rather than rounding it away.
Specification
Properties of the record.
Structural facts about how the money history is stored.
- Write model
- Append-onlyNo update path, no hard delete
- Row contents
- Amount, reason, reference, balance after
- Amounts
- Integer koboNever a float, anywhere in the path
- Atomicity
- One transaction, wallet row locked
- Duplicate protection
- Idempotency key per movement
- Corrections
- A new, opposing rowThe original entry remains readable
- Reconciliation
- Nightly, every walletExits non-zero on any drift
- Visibility
- Full history in your dashboardFilterable and exportable
- Webhook events
- Verified and deduplicatedHMAC-SHA512, stored by event id
Pairs with
None of this works alone.
Each capability assumes the others exist. These three are the ones this page leans on most.
Read your own history.
Every store gets the full ledger, on every plan. It starts writing itself with your first sale.
Free to start · No card required