TigerBeetle's Stablecoin Mistake
Is there such a thing as "the ultimate fintech database"?
You’ve heard this one already: “skate where the puck is going, not where it has been”.
In order to innovate, companies have to build for the world of the future, where conditions will have changed. What is silly now, where the puck isn’t, may eventually stop being so, because that’s where the puck will be.
But what if the puck ends up being somewhere else?
See, that’s the problem with trying to predict what the future will look like: you aren’t crazy enough to do it. The most you can do is to put yourself in positions where you can take advantage of the opportunities that are presented to you.
So, it’s not about skating where the puck is going. It’s about being able to try again if the puck doesn’t go where you are.
I first heard of TigerBeetle a couple of years ago in a piece from Chris Riccomini called Databases Are Commodities. Now What?. Since then, I’ve been experiencing a Baader-Meinhof phenomeon.
TigerBeetle is always there, everywhere I look.
Readers of this newsletter first recommended it to me, then demanded that I wrote about it. There’s a Primeagen video about it. They hosted a conference where Hillel Wayne gave a talk, and I’ve recently learned that matklad works for the company building it.
So it’s either The Algo really trying, or TigerBeetle having great marketing people. Because this is The Database For Financial Technology, and my newsletter is for engineers using databases (among other tools) for that very industry.
And let me tell you, TigerBeetle is a fine piece of engineering.
Yes, don’t take this article as software criticism: TigerBeetle is a marvelous thing. I’ve played around, tinkered with it, and I can say lots of positive things about it. It’s the kind of database that’s needed in many financial institutions desperately, and the only reason there isn’t more of them adopting it is likely because of banks’ atrocious IT procurement and contracting practices, and not TigerBeetle itself.
However, in trying to predict what the future would look like, TigerBeetle has painted itself into a corner. One that is increasingly clear isn’t the right corner to be.
Databases, like many other systems, are built on tradeoffs. A while ago, we explored QLDB, the now defunct Amazon’s ledger database, and I cheekily compared it to the spacecraft that the star character of The Martian had to propel itself to space with:
QLDB is like that vandalized rocket that Mark uses to take off from Mars and onto the spaceship that would bring him home. If postgreSQL is a fully fledged spacecraft, a BMW of luxurious interplanetary travel, with all the amenities and guarantees, QLDB is stripped from control panels, from backup systems, and all that doesn’t move the system closer to achieving its mission.
To boldly go where no database has gone before.
The problem with these design choices is that they’re so narrowed down on solving one particular aspect of the problem space that they’re very fragile when these solutions don’t make a business difference.
In QLDB, for example, the problem wasn’t really cryptographic verifiability. Sure, you can verify that the data hasn’t been tampered with independently, but does that really align with a system that’s owned by a cloud provider?
I guess that if Amazon couldn’t figure that out, the answer is probably “no”. You may want to verify immutability with Merkle trees, but trusting that the central authority isn’t doing anything with your data is probably a better business decision.
So it is with TigerBeetle. They’ve built a financial database that’s faster than any other alternative out there. And performance is something you desperately need when you build a ledger, since the whole architecture is predicated on lots of data that are accessed very frequently.
But TigerBeetle is very bad at handling multiple currencies. And the world seems to go in the direction of multi-currency ledgers, even if they aren’t the fastest.
TigerBeetle may be a database placed “where the puck is going”. But it’s lost the ability to get back if the puck ends up somewhere else.
I’m Alvaro Duran, and this is The Payments Engineer Playbook. You’re already subscribed to free newsletters that “teach” you how to get a job as a software engineer.
But you don’t want to get a job; you already have one. What you want is to learn how to be great at your job. Especially as a payments engineer, where stakes are sky high, and the margin for errors is razor thin.
In The Payments Engineer Playbook, we investigate the technology that transfers money. All to help you become a smarter, more skillful and more successful payments engineer. And we do that by cutting off one sliver of it and extracting tactics from it.
Today, we’re looking at TigerBeetle’s approach to multi-currency transactions. It sounds a weird topic to dive into, but if you notice how often you’re sending money abroad, pay for goods and services from other countries, or simply buy stocks from international exchange markets, you have to admit that this is becoming something that we’re doing more and more frequently.
And that’s putting a lot of pressure on single-currency ledger systems. Even when they’re 1000x faster than the competition.
In this article, we’re going to look at
What is TigerBeetle’s approach to double entry accounting, and why.
A crash course on stablecoins. What are they, and why everyone is talking about them.
The “impedance mismatch” between TigerBeetle’s design and stablecoins.
The unbounded future of ledger systems.
Enough intro, let’s dive in.
Reference Currency
For the longest time, ledgers have been denominated on one currency, and one currency only.
Our world is already testing this design decision to its limits. We’ve lived in a multi-currency world for quite some time, but the scale of multi-currency transfers was so minimal, humans in between single-currency ledgers were enough to smooth things over. Never needing to answer questions about these transfers with much granularity, nor in real time, also helped. As long as you get the answer by the end of the month, the quarter, even the year, you’re doing pretty well.
Not anymore.
Even startups and small businesses have the same problems as multinationals now, but needing far less scale and therefore much more granularity.
Being remote means now being global. Clients are everywhere, and so are providers and employees.
Banking apps not only handle deposits, but also investments in stocks, payments when we travel abroad, crypto, even angel investing.
To the extent that the USD is no longer the only reserve currency, businesses that operate globally need cash stored in more than just dollars, all fluctuating against each other.
If this sounds intimidating, it’s because it is. Or it would be, if we keep relying on design decisions made in the times of Medici’s Florence.
Transfers, Not Transactions
Transaction is a loaded word.
There are financial transactions and database transactions. There’s also the transactional interpretation of quantum mechanics, and there’s transactional leadership.
But there are no transactions in TigerBeetle. There are transfers.
A transfers are a single movement of money, from a single debit account to a single credit account on—and this is crucial—the same ledger. They cannot be modified, though you can add new transfers to correct them.
And if you want to do more complex money movements, you have to compose multiple transfers.
The actual reason why TigerBeetle has transfers and not transactions isn’t just to mess with you, it’s because a transfer is a fundamental building block of the database.
When I discussed QLDB, I casually mentioned that SQL and JSON weren’t supported because “QLDB does away with everything that’s on the way to its difficult goal.”
SQL is a battle-tested way to get and update data from a general purpose database. But it relies on generic data structures meant to store any kind of data type.
TigerBeetle’s most fundamental optimization is precisely here: we don’t need to store any kind of data type. We just need to store movements of money. So why not making that the fundamental data model, and build everything around it?
In fact, all movements of money boil down to transfers, and two more things:
Two phase transfers: Having the ability to reserve funds (pending), and resolve (post, void, expire) them.
Linked Events: Having the ability to chain multiple transfers as an atomic block.
TigerBeetle leverages these 3 primitives into a set of recipes that allow engineers to do everything with this database as long as it’s about moving money.
But, like I said, a transfer must happen within the same ledger. And that’s the core of TigerBeetle’s mistake.
Stablecoins, and Multi-Currency Ledgers
How would you send somebody money internationally if you couldn’t use a bank?
Cash over email, or over a handcuffed briefcase might work, but you run the risk that it gets lost. No problem; you get creative. How about you buy shares of Apple, and instruct the recipient to short sell them, and then you can just transfer those shares to them?
That works. That’s actually brilliant. But the transaction costs are probably too high: there’s the difference between the buy and sell price, the broker’s comissions, etc.
Let’s go crypto, then: you buy some Bitcoins, and they sell a bit of theirs, and then you can transfer those Bitcoins to them. The transaction costs are somewhat fixed, and low, so this is an improvement. But Bitcoin’s price is much, much more volatile than Apple’s. The risk of having to offset the price difference makes this approach unwieldy at scale.
The good thing about crypto, and the reason why the transaction costs are so low, is because there’s nothing central about it. The recipient may be on the other side of the world, and they have the same level of access and visibility to it than you. It may be slow, but not SWIFT slow. And it’s way cheaper.
So what we probably need is something that’s crypto-like, to retain the global aspect of such a ledger, but without the volatility of crypto currencies. One way to do that is to have a blockchain that distributes the value of a predefined pool of resources, something that doesn’t change in value against a fiat currency.
So that’s what stablecoins really are. And they’re now facilitating $30bn of transactions daily.
Impedance Mismatch
How would you represent a transfer made from a bank account in USD to another in EUR made via Tether, a well-known stablecoin?1
In TigerBeetle, ledgers are denominated on a single currency, and transfers between pairs of accounts in different ledgers aren’t allowed. So what you have to do is to create two linked transfers in two different ledgers, each one moving money within the same ledger (from or to the “liquidity source”).
Using Tether complicates all this even more. We’re going to need 6 accounts:
A source account in USD on
ledger 1A source liquidity account on
ledger 1A source sweep account in Tether on
ledger 2A destination sweep account on Tether on
ledger 2A destination liquidity account in EUR on
ledger 3A destination account that belongs to B on
ledger 3
and a transfer trio:
A transfer from the source account to the source liquidity account (USD)
A transfer from the source sweep account to the destination sweep account (Tether)
A transfer from the destination liquidity account to the destination account (EUR)
Here’s another problem: the exchange rate must be made explicit prior to the transaction. The price risk and any costs derived from the fluctuation of the exchange have to be recorded, as per TigerBeetle’s docs, “as a separate transfer from the source account to the source liquidity account”.
That’s a compensating transfer. Which becomes the fourth in this scenario.
TigerBeetle is built for speed. But makes multi-currency scenarios unmanageable.
Databases are (indeed) Commodities
I’ve been building financial technology for quite some time now, and I’m still as excited as when I started.
TigerBeetle isn’t a failure. On the contrary, it’s the signal that ledger technology isn’t done yet. There’s still so much to do. And that we haven’t nailed down the ultimate financial database yet.
Perhaps we never will.
Most payment engineers think that “rolling out your own ledger” is an unnecessary rite of passage (I already talked about my own), but every financial database that claims to be general purpose I know fails in some particular aspect that makes it work tremendously well for some use cases, and terribly bad for others.
It’s as if rolling out a ledger system isn’t a rite of passage, but the only valid way to build financial technology that truly fits your business.
It sounds absurd, but that brings me a lot of joy. There’s so much that we can do with financial recordkeeping that goes beyond tracking money. We might track a contractor’s hours as inventory. We might see the offices not just as something tangible, but as collateral for a loan, becoming both asset and liability.
We might track who gave us cash, and what we used that cash for.
A ledger then becomes less a cold record of balanced transactions, and more like a map of intent. Relations, obligations, and possibilities find a way into our books, and companies make more informed decisions based on them.
And ultimately, we free ourselves from thinking that only money is valuable, and that valuable can only be represented as money.
I’ll see you next week with another article from The Payments Engineer Playbook.
If you liked this article, consider becoming a subscriber,
or sharing it on Hacker News.
This section relies heavily on TB’s Currency Exchange recipe. You can go there for more info.