Analysis updated 2026-05-18
Study a documented example of double entry ledger design for money systems.
Learn how to prevent double spends and duplicate charges under concurrency.
Reference how a Nigerian fintech might model held versus settled balances.
Use as a portfolio project demonstrating backend engineering discipline.
| dgreegman/vaultpay | advayc/wrapped | aegrail/aegrail-engine | |
|---|---|---|---|
| Stars | 1 | 1 | 1 |
| Language | Go | Go | Go |
| Setup difficulty | moderate | easy | hard |
| Complexity | 4/5 | 2/5 | 5/5 |
| Audience | developer | general | ops devops |
Figures from each repo's GitHub metadata at analysis time.
Requires Go 1.22+, Docker, and golang-migrate, ports 5433 and 6380 must be free or adjusted in the env file.
VaultPay is a fictional digital wallet system built as a portfolio project to show how a real Nigerian fintech company would build its backend, rather than as a product meant to sign up real users. It lets a business create wallets for its customers, move money between them, and connect payments through a documented API, but it handles no real money, no real customer data, and connects to no real bank, since every outside integration is a mock. The project's stated goal is to prove the author understands the hard problems unique to systems that move money, such as double charges from retried requests, balances that quietly drift from reality, and fraud that only shows up under adversarial use, instead of just wiring simple create, read, update, and delete endpoints to a database. Its central design rule is that no code is ever allowed to directly subtract from a balance. Instead every movement of money writes at least two entries, a debit and a credit, into an append only ledger that always nets to zero, and a wallet's balance is treated as something rebuilt from that ledger rather than a number you edit directly. Other documented engineering choices include storing money as whole number kobo or cents instead of decimals to avoid rounding drift, using row level database locking so two simultaneous transfers against the same wallet cannot both succeed if funds cannot cover both, and writing database changes together with outgoing events in the same transaction so a queue outage delays notifications instead of losing them. The design also reflects specifics of how money actually moves in Nigeria, including modeling a held or escrow balance the way the country's real instant payment network settles funds later even though a recipient sees them immediately. The system is built in Go using the Fiber web framework, PostgreSQL for its database, and Redis for caching and rate limiting only, with RabbitMQ, Prometheus, and Grafana planned for a later phase. To run it locally a developer needs Go, Docker, and the golang-migrate tool, then can start the stack with a few make commands. The README lays out a phased roadmap, with early scaffolding and core wallet features further along than later fraud detection and multi currency support, which are still planned.
A fictional Nigerian style digital wallet backend built to demonstrate correct, auditable money-movement engineering rather than to sign up real users.
Mainly Go. The stack also includes Go, Fiber, PostgreSQL.
The README does not state a license, so terms of use are not specified.
Setup difficulty is rated moderate, with roughly 30min to a first successful run.
Mainly developer.
This repo across BitVibe Labs
Verify against the repo before relying on details.