Skip to content
Employer product, name withheld2025 — 2026
In productionarchitecturepaymentsdata

Prediction market platform

Binary event markets with an automated market maker and a double-entry ledger underneath

A platform where users trade YES/NO positions on real-world events. Prices come from an automated market maker rather than a matched order book, every balance movement is a double-entry ledger posting, and settlement pays out positions when an event resolves. Most of it is ordinary web work sitting on top of two things that aren't ordinary at all: pricing and money.

Built for
Employer product, name withheld
My role
Full-stack feature development across the trading, wallet, settlement and admin surfaces, in a remote engineering team.
When
2025 — 2026
  • Next.js
  • React
  • TypeScript
  • PostgreSQL
  • Prisma
  • Zustand
  • Tailwind
  • LMSR
Write-up

The longer version

Why an automated market maker

A prediction market with no liquidity isn't a market. It's a form. An order book needs traders on both sides before it can quote anything, and a platform launching new markets continuously never has that on day one.

A scoring-rule market maker always quotes, and its prices move as a function of the positions held rather than of who happens to be online. The cost is that the platform itself carries inventory risk, bounded by the liquidity parameter. That's a trade you make on purpose, in exchange for a market that works from the very first trade.

Why the ledger is double-entry

Because the alternative is a balance column, and a balance column can't tell you when it's wrong. In a system taking deposits, charging fees and paying out settlements, the property you want isn't that the arithmetic is correct. It's that incorrect arithmetic is detectable. Double-entry hands you an invariant to check instead of a number to trust.

A note on this write-up

This was built for an employer and the product is not named here. The engineering described is my own work on it; the commercial detail, the numbers and the brand are theirs.

01The engineering

What made it hard

The problems worth reading about. Everything else in this system was ordinary work.

  1. 01

    Prices come from a logarithmic market scoring rule rather than from matching buyers against sellers. That single decision is what makes a thin market usable at all. A new market with two participants still has a quotable price, where an order book with two participants has a spread nobody will cross.

  2. 02

    Every balance change is a double-entry posting rather than an increment on a user row. Deposits, trades, fees, settlement payouts and withdrawals all have to balance, which turns a discrepancy into a detectable condition instead of a number that quietly drifts.

  3. 03

    Withdrawals above a threshold are gated on identity verification, and the fee is charged on profit rather than on volume. Both are policy decisions, and policy decisions have to be enforced in the ledger rather than described in the interface.

  4. 04

    Markets are embeddable in partner media sites as a widget, with affiliate attribution carried through so commission can be traced back to the placement that produced the trade.

02Numbers

What it measures

Each figure says where it came from, so you can judge how much weight to give it. Some are measurements and some are chosen thresholds; the basis line tells you which.

LMSR
Pricing mechanism

A logarithmic market scoring rule as the automated market maker, rather than a central limit order book.

Double-entry
Accounting model

A ledger module every balance movement posts through, including trades, fees, settlement and wallet operations.

3% on profit
Fee basis

Charged on realised profit rather than on traded volume.