Accounting for Poker Stables with Rich Hickey’s “Database as a Value” Principles
How leveraging time-travel and immutable data models solves the complexities of poker-stable accounting.
Disclaimer: For the Poker Players Reading This
If you’re a poker player stumbling across this blog, let me save you some time: this post will not teach you how to make more money at the tables. Seriously, if you’re concerned about maximizing your hourly rate or grinding out your next big win, you’re better off studying strategy or reviewing hands than reading about accounting systems.
That said, if you’ve ever been confused about how makeup works, or you’ve found yourself staring at your balance wondering, “How does this all add up?”—then this post might clear a few things up for you. It breaks down exactly how funds are tracked and profit is split in a stable, using logic that’s designed to be both fair and transparent.
Now, if you’re someone who wants to take the leap from being a player to becoming the next big staker—building and managing your own stable—then you absolutely need to have your accounting on lock. Running a stable isn’t just about staking the right players; it’s about managing funds with precision and ensuring everyone knows where they stand. This post might not help you with your hourly, but it could save your business down the line.
So, to the grinders out there: read on only if you care about systems and transparency—or if you’re dreaming about becoming the next big shot staker. Otherwise, back to the tables with you!
Introduction
Over the years, I’ve become fascinated by the concepts Rich Hickey (the creator of Clojure and Datomic) has championed—particularly his notion of a database as a value. In his famous talk, “The Database as a Value,” Hickey explores the power of immutable data structures, time-travel queries, and event-driven state management. When I started designing an accounting system for a poker stable back in 2015, I realized something serendipitous: accounting logic and Datomic’s time model fit together like two perfectly aligned puzzle pieces.
Why is that? Because in both systems, historical integrity and auditability matter more than ephemeral or “current” state alone. Like double-entry bookkeeping, Datomic ensures every “transaction” is recorded as an immutable fact along a timeline. This allows us to “time-travel” through the data to see exactly how things changed—and why.
In hindsight, some might consider these design decisions “obvious” now. Today, we’re seeing modern financial platforms (e.g., NuBank and others) adopting epoch-based time models, plus a growing recognition that Clojure is especially strong in finance and accounting contexts. But back in 2015, merging these concepts for a poker stable was a little ahead of its time.
In this post, I’ll outline how an immutable, time-travel-capable data model matches the needs of a poker stable accounting system. We’ll walk through key definitions—Balance, Float, Makeup, Profit Chops—and see why a Datomic-like approach can reduce complexity, increase clarity, and deliver a robust, fault-tolerant system.
1. Why Poker Stables Need Solid Accounting
In a poker stable setup, one or more backers (the stable) provide funds to one or more players who compete in cash games or tournaments. The stable and the player agree to split profits above a certain threshold (or “Makeup”). Crucially, the system must track:
The Player’s Balance on poker sites and sub-accounts.
The Float: Net allocation of funds owned by the player vs. the stable.
The Makeup: If the player is in profit or owes the stable (i.e., negative Makeup).
Much like any ledger, transparency is everything. You need a clear record of who owns what, how much is owed, and how real or virtual transactions affect these numbers. That’s where the synergy with Datomic’s model becomes clear:
In Datomic, every change is stored as an immutable fact.
We can replay transactions to see exactly how the ledger changed over time.
This aligns beautifully with double-entry accounting, where each transaction is recorded in two places to maintain balance.
2. The Core Definitions in Brief
To illustrate how a time-travel model helps, let’s review the key terms that form the backbone of our poker accounting system:
Balance
The total funds in a player’s accounts (poker sites, sub-accounts, etc.).Float
The net allocation of bankroll to a player—comprised of personal bankroll plus stable-provided bankroll.Makeup
Defined by the equation:Makeup=Balance−Float\text{Makeup} = \text{Balance} - \text{Float}Makeup=Balance−Float
Positive Makeup: The player is up money; can request profit distribution.
Negative Makeup: The player is effectively “in the red” relative to the stable.
Profit Chop
A virtual transaction re-allocating positive makeup into personal and stable profit shares.Swaps
Virtual transactions between players to settle side deals or partial staking agreements. No real money changes hands at that moment; only an adjustment of each player’s Float.Stable Action Buys
Another virtual transaction for when the stable buys a portion of the player’s external action or tournaments. This changes the Float to reflect the stable’s stake, without immediate real money movement.
3. Killing Most of the State
Rich Hickey repeatedly warns about “places” and “states” that are mutable, ephemeral, and easy to corrupt. If we try to manage a complex system (like a poker-stable ledger) in a purely mutable database, we run into:
Race conditions: Multi-user access makes overwriting data all too easy.
Loss of history: Once data is updated, it’s gone. How do we reconstruct a prior state?
Complex auditing: If we discover an error, we have to piece together the entire chain of events from incomplete logs.
In an immutable setup (like Datomic’s), the database is not “the current value” but rather a value with a timeline of all states. Each transaction is added but never destroyed:
We can reconstruct the ledger at any point in time.
Mistakes can be corrected with further transactions (not by rewriting past events).
We harness a “time-travel” approach to see exactly how the ledger and makeup have changed.
This mindset is identical to how you must handle proper double-entry accounting: every event (win, loss, deposit, withdrawal, chop) appends to the ledger, rather than mutating an existing row.
4. Transaction Types: Real vs. Virtual
In the poker stable system, we differentiate between real transactions (actual money moving) and virtual transactions (reallocation of shares, profits, or action). This mirrors perfectly how Datomic (or any event-sourced system) might label certain transactions as “cash events” vs. “internal journaling events.”
Real Transactions
Deposit: Player sends funds to the system → Balance and Float increase.
Withdrawal: Player takes funds out → Balance and Float decrease.
Transfer to Stable: Player returns stable funds → Balance and Float decrease.
Virtual Transactions
Profit Chop: Re-allocates positive makeup into personal vs. stable profit.
Swaps: Adjusts the floats between players to reflect personal deals.
Stable Action Buys: Adjusts the player’s Float to reflect stable-owned portions of the action.
In an immutable, event-driven database, these each become a “fact.” We record that on a certain date and time, X deposit of $Y was made, or X chop for $Z was created. Then, from that chain of transactions, we can derive the player’s current Balance, Float, and Makeup at any historical or present moment.
5. Example Walkthrough (Datomic Perspective)
Imagine we store all these transactions as facts in a Datomic-like system:
Initial State
No “facts” yet about the player’s bankroll.
Balance = $0, Float = $0, Makeup = $0.
Stable Funds the Player
Transaction #1: “The stable sent $5,000 to the player’s poker account.”
Balance = $5,000, Float = $5,000, Makeup = $0.
Player Reports a Win (+$2,000)
Transaction #2: “Player’s Balance is now $7,000.”
Balance = $7,000, Float = $5,000 → Makeup = $2,000.
Profit Chop
Transaction #3: “Chop $2,000. $1,000 personal, $1,000 stable.”
Float is now $7,000, matching the new ownership distribution.
Makeup resets to $0.
Withdrawal of $1,000
Transaction #4: “Player withdraws $1,000 real money.”
Balance = $6,000, Float = $6,000, Makeup remains $0.
Swap with Player B
Transaction #5: “Player A owes Player B $500 from a swap.”
Floats are adjusted: Player A +$500, Player B -$500.
Balance and Makeup remain unaffected.
Stable Action Buy
Suppose a big win: $10,000 result, with 30% stable-owned.
Transaction #6: “Stable’s share of external action = $3,000 added to Float.”
Balance remains $10,000, Float is increased by $3,000.
At each step, we are not overwriting data. We’re appending new facts. If we want to see the ledger on any day (or even after each event), we query the database at that time. This is the key advantage: the consistent, historical record.
6. Rules and Why They Matter
Makeup = Balance - Float
This is the simplest formula but also the most crucial. Changing the Float or Balance will directly affect the Makeup.Makeup Changes Only Through Playing Results or Profit Chops
If the player is winning, Makeup becomes positive; losing extends or creates negative Makeup.
Deposits, withdrawals, or stable transfers do not directly change Makeup.
Virtual Transactions (swaps, stable buys) do not immediately change real money balances—they just reassign stakes.
In a time-travel data model, these rules are easy to enforce. We don’t do partial updates that might accidentally cause a mismatch. We simply append an event that states: “The new Float is X because of Y reason.” The system’s rules define how Makeup is then recalculated at the derived stage.
7. Transparency, Auditability, and Time-Travel
Poker players and stables both have a vested interest in accurate, transparent accounting. By using an immutable event log—modeled after Rich Hickey’s data-as-a-value design—we get:
Perfect Audit Trails
We can always see each transaction (real or virtual) in chronological order.Time-Travel Debugging
If a player disputes a prior makeup figure, we can “roll back” to the ledger as of that point in time to see the exact chain of events.Reduced Complexity
Without the need to maintain a complex, mutable data store, we drastically reduce the number of potential “states” that can get out of sync.
8. In Hindsight: Obvious, But Early—and a Little Crazy
From today’s vantage point, it’s clear that epoch-based ledger approaches and Clojure/Datomic-driven designs are transforming the financial world. A prime example is Nu Bank, a Brazilian bank renowned as one of the fastest-growing consumer banks globally. Nu Bank relies on Datomic and Clojure at its core—and went so far as to acquire Cognitect, the company behind both Clojure and Datomic (including Rich Hickey himself).
Although these practices seem almost standard now—especially for innovative financial services—our early application of a time-travel, immutable database model to poker stable accounting back in 2015 was somewhat ahead of the curve. Institutions like Nu Bank have validated the power of these technologies at scale, but a few years ago it felt pioneering—and sometimes downright “hacky.”
A Google Sheets Anecdote
One of my favorite (and maybe slightly embarrassing) stories from this era is how I actually designed the system in a minimal-code way: we used Google Forms and Google Sheets to create a single ledger with hundreds of users and multiple “companies” (i.e., stables) all in one spreadsheet tab. We’d layer on some clever queries and pivot tables to track the floats, balances, and makeup for 300+ players.
Would I recommend this approach?
Absolutely not—but it did work. In fact, it worked so well that we used it in production for three different stables. The system was a bit fragile, but it let us prove the concept quickly without spinning up a new codebase or massive infrastructure.
Then came a moment I’ll never forget: at bitB (a well-known poker staking group), we planned a joint venture with a Gibraltar-based gaming company for an MTT stable. This company had an actual dev team build out their own stable accounting software in house. However, after an evaluation of both systems (their custom-coded solution vs. my Google Sheets approach), the business side opted to use the Sheets-based ledger—over custom code. It was hilarious and a little bonkers—yet a testament to how a well-thought-out data model (even jammed into a spreadsheet) can outperform half-baked proprietary software.
So while a Google Sheets hack might not be the grand architectural showcase we dream of, it shows how sound accounting logic and time-based modeling can triumph in the most unexpected environments. And perhaps that’s the ultimate validation: good design principles shine through, even if you build them in a couple tabs of Google Sheets.
9. Conclusions & Next Steps
Building an accounting system for a poker stable might not be the first place one expects to find advanced computer science concepts, but the synergy is tremendous. The same immutability and timeline-based approach that powers Datomic can powerfully address the complexity of stable transactions.
Kill most of the state: Convert ephemeral state changes into an event-sourced ledger.
Record everything as facts: Let the system store each deposit, chop, and swap as an immutable transaction.
Time-travel for clarity: Offer players and managers the ability to see exactly how the ledger looked on any date.
This approach yields a robust, maintainable, and infinitely more transparent system. For anyone looking to manage multiple players and complex bankroll distributions, the payoff is enormous: fewer disputes, minimal confusion, and a real-time snapshot (or historical viewpoint) of every single transaction.
If you’re intrigued, check out Rich Hickey’s talks on Datomic’s architecture and dive deeper into double-entry accounting principles. Together, they show how to handle the inherent complexity in financial systems—whether you’re running the books for a Fortune 500 or a world-class poker stable.
Further Reading & References
Thanks for reading! I hope this post clarifies how time-travel logic and immutable data models can revolutionize accounting systems—even those for poker stables.