Skip to main content
Orientation · 4 min Arc is a simulation of a cross-border payments business, written to be read as much as run. I am modelling a company that moves money between Europe and Africa: it holds customer balances in several currencies, converts them, settles the middle leg on a blockchain, and pays out over local rails like SEPA Instant, NIP, and M-Pesa. The first decision I made was that this would not be a wallet, not a demo app with a balance column, and not a toy. Everything else follows from that one distinction:
A demo stores a balance.UPDATE accounts SET balance = balance - 1000Fast to write. Impossible to audit. When the number is wrong there is nothing to compare it against, because the number is the record.
Arc derives it.A balance is a fold over an append-only entry log. Replay the log and you must get the same figure. If you don’t, the entries are right and the cached number is wrong.
That choice cascades through everything else on this site.

​
What is modelled faithfully

These are simulated, but simulated properly: the behaviour that makes them hard is present, not smoothed away.
Every movement is a balanced set of entries. Debits equal credits exactly, per currency, independently. The posting engine validates before writing, and the Postgres schema validates again via a DEFERRABLE INITIALLY DEFERRED constraint trigger, so a transaction leaving any journal unbalanced cannot commit, even from raw SQL at 3am during an incident.The ledger →
Five chains with genuinely different physics: Solana’s 400ms blocks and 32-confirmation finality, Polygon’s 2s blocks but 128 confirmations. Polygon therefore settles slowest despite looking fastest, exactly what a naive “block time equals speed” model gets wrong. Seeded runs reproduce the same blocks, reorgs and outcomes every time.The chain layer →
Six rails, each with its own latency, cut-off window, cap and failure profile. NIP has the highest rejection rate; M-Pesa the highest timeout rate. Missing SEPA Credit’s 15:00 cut-off by an hour costs a full day, not an hour: the queued payment starts from the next opening and then takes the rail’s normal latency.The cut-off that cost a day →
Quote → compliance → reserve → swap → settle → payout. Each step has an execute and a compensate, and compensation walks completed steps backwards. Failure is a business outcome with a status, not an exception thrown at the caller.The settlement saga →
A transactional outbox stages events in the same database transaction as the state change. Handlers that already succeeded are never re-run on retry, and a poison event is parked for review rather than dropped or left blocking the queue.Contexts and events →

​
What is simulated away

I am stating these plainly, because a simulation that hides its seams teaches the wrong things, and I built this to learn from rather than to demo.
The honest limitation. Because Arc runs as a modular monolith, it never suffers a true network partition between contexts. Sagas, idempotency and at-least-once delivery are genuine: the outbox is a real table with real retry semantics, but split-brain and partial-availability failure modes are reasoned about rather than reproduced. That trade is argued in ADR 0002.

​
Who this is for

Engineers who have never built financial software and want to know why it looks so different from ordinary CRUD. The answer is mostly: because you can never delete anything, and the arithmetic must be exact. Engineers who have and want a worked reference for the saga, the chart of accounts, and the compensation ordering. Product and policy people who need to evaluate a stablecoin payments claim without taking the vendor’s word for it. Start with the case against: it is the page most such sites do not have. Anyone interviewing for a payments, ledger, or infrastructure role. Practice is built for that specifically.

​
The non-goals, one more time

  • Not a real financial system. Every external integration is a simulator.
  • Not production-hardened. No HSM, no real KMS, no PCI scope, no regulatory licensing.
  • Not compliance software. The AML rules and sanctions screening illustrate how such systems are structured. They are not a compliance program and must not be used as one.
  • Not investment, legal, or financial advice.

Next: pick a reading path

Four routes through this site depending on what you came for.