I build systems where the money has to add up.

Users hold a USDT balance, trade, and take positions on event outcomes. The requirement that shaped everything: the books have to balance at any moment, including mid-trade and mid-withdrawal.

I put the accounting core in its own reusable module — double-entry postings, accounts, HD wallets, deposits and withdrawals across four networks, on-chain reconciliation, fees, compliance screening. The order book and prediction market sit on top of it. Private keys never live in the application: signing is isolated in a separate service.

The same core now backs a second, unrelated product. That's the test of whether a ledger was built properly: it survives being reused.

Open the full sheet →

Fig. A-1Reserve reconciliation, on sample data: for each asset the ledger’s liabilities against what is held on chain, with transfers in flight, fees, platform-owned funds and unattributed coins as columns of their own — so every row adds up to its residual rather than asking you to trust one. USDT reconciles, BTC carries an unexplained surplus, ETH is short and its withdrawals froze automatically.

Multiple receiving addresses with source attribution, balance accounting, batches of payouts as the central object, recurring debits, screening on the way in. Six coins across eight coin-and-network pairs, because a currency without its network is an incomplete quantity — that rule lives in the data model, not in a convention people are asked to remember.

The part I'd point at first: a batch runs as a dry run before it sends. Every row comes back with its fee on top of the amount and the exact debit that will hit the account. Nobody discovers the cost of a two-hundred-line payout after the money has left. Built on the ledger core above rather than from scratch — which is why it reached 48 endpoints and a full batch lifecycle in weeks, not quarters.

Three rules the dry run enforces, because they are the ones that cost money to learn. A row that failed keeps its key, so loading it again cannot produce a second payment. “Sent, no confirmation” is the one state the system refuses to retry, because the money may already have left. And a payment lookup matches exactly or returns nothing — a plausible wrong match is worse than no match at all.

Open the full sheet →

Fig. A-2The dry run, before anything is sent. 487 rows will go, recipients get 12 480.25 USDT, and 12 967.25 leaves the account because the fee sits on top of each row rather than inside it. Thirteen rows will not go: six addresses belong to another network, seven are short of funds, and each says what it needed against what was left. Test stand — the amounts are not real.

Open the full sheet →

Fig. A-3Rows that did not go, and what the console does about them. No money moved on any of the three, so they can be loaded again — the row key is unchanged, and a row already broadcast is never repeated. At the foot, the one state the system refuses to retry: the send outcome is unknown, the funds stay held, and it is resolved by the transaction hash rather than by sending again. Test stand.

Open the full sheet →

Fig. A-4Receiving with source attribution — each source gets its own address in every network it is paid from, so money identifies itself by where it lands, and the import key never changes: that is what makes a partner’s total add up across renames. The lookup matches exactly and will not guess, because a plausible wrong payment is worse than one not found. Test stand.

A small business goes to a bank, a leasing company or a tender with one question: what does its trading look like to whoever decides. The answer is scattered across account movement, lease agreements, loan schedules, card acquiring, cash collection, payroll and tax load, and it is nowhere assembled. The system assembles it into one working model — who pays whom, for what, on what schedule — runs that model month by month against limits, contractual dates and taxes, and answers three practical questions: where the risk is, where headroom is left, and what a credit analyst will see.

The hard part is placing a flow of payments so that five constraints hold at once: the balance reconciles every day, no counterparty exceeds its limit or its share of turnover, the month stays under its ceiling, and the period closes on exactly the balance asked for. It is solved in layers — a plan, a check against the daily calendar, a sweep of the remainders, and a final pass that distributes the gap across whoever still has headroom, or says plainly that there is nothing left to close it with.

One principle holds the rest up: the model is the source. Monthly cash flow, analytics, the tax return and the note you carry into the bank meeting are derivatives — throw them away and they rebuild; the model cannot. Money moves as strings and is computed on Decimal, never through a float. The frontend's API types are generated from the backend's own OpenAPI contract, so a version bump breaks the build instead of someone's screen. Progress on long jobs goes over SSE rather than WebSocket, because a WebSocket would have needed the token in a query string, and from there it lands in the logs. A year of work; an internal product, in production on two stands, with no public sign-up.

Open the full sheet →

Fig. A-5The model refusing to pretend. Of ₽19,821,470 asked for, ₽17,575,600 can be placed; the ₽2,245,870 that cannot is broken down by counterparty, each with the constraint that would have to move. The notes below say plainly that there is no room left to pay the surplus out to the owner. An invented business on seeded figures.

Open the full sheet →

Fig. A-6The same business month by month across two years: the mandatory floor first — rent, payroll and its tax, owner profit, account fees, with the quarterly regime tax giving the stack its saw-tooth edge — then the month’s spending limit above it and the headroom left to the ceiling. The strip under each bar names what binds that month: the monthly limit, or how much the suppliers can absorb.

Account managers were reading PDF credit reports from three different bureaus by eye and retyping the figures into spreadsheets and deal records. The brief was to remove the manual step entirely, not to speed it up.

A CRM webhook lands in a queue, workers pull the PDFs from cloud storage, parse three unrelated report formats, merge them into one picture, fill seven blocks of a working spreadsheet and write the result back onto the deal. Some documents are scans, so recognition is part of the pipeline rather than a prerequisite for it. This is the second generation — the first had almost no tests and was hard to change without fear, so I pulled the pipeline out and rebuilt it, tests first. The 4,125 tests exist because a misparsed credit figure is not a cosmetic bug — that lesson cost me a rewrite.

One place in the system issues user tokens, so no other service has to store a password or a piece of personal data. Sessions, EdDSA-signed tokens with a published key set for neighbouring services to verify, passwordless keys via WebAuthn, one-time codes, Argon2 hashing, profiles and roles, and the mapping between identity and money accounts.

Fresh dependency releases sit in a one-week quarantine before they can be installed. A compromised package is most dangerous in the hours after publication, before it's pulled; a week closes that window without delaying real security fixes.

When several AI agents work on one system across separate repositories, they need a way to agree — otherwise each fixes the boundary its own way. An MCP server with a shared mailbox: messages addressed to roles, threads with a lifecycle and work status, machine-readable agreement on decisions, and shared contracts held as pinned, versioned entries. Two transports: local, and hosted with isolated channels and token auth.

This is public and MIT, and you can open it. But to judge how I write code for systems that hold money, start with ledger-reconcile instead: 2,177 lines of library and command, and 3,002 of tests, implementing thirteen of the fourteen failure modes from the teardown, name the fourteenth as out of reach, and report what a run could not check.