One of my favorite academic papers is The Economic Organisation of a P.O.W. Camp. You’ve probably heard about it.
It’s the “cigarettes as money” paper.
You see, bank notes didn’t get you much in a Nazi camp. They could only be used in the canteen, where there was just food, and it was bad.
Most of the stuff, you got it from another prisoner.
And sure, there was some initial barter among them. But it was very impractical—POW camps were massive. Almost immediately, prisoners resort to cigarettes as money.
Cigarettes are homogeneous, convenient to carry around, and durable enough. And even though prisoners had to endure a few problems associated with it—deflation, for example, as people slowly removed them from circulation by smoking them—there were no other good alternatives to it.
Cigarettes became money where there was no money.
Building a ledger is a lot like rebuilding the economic life of a POW camp.
You think you’re dealing with real money. You go as far as calling it money, using some library like RubyMoney or py-money to “represent” amounts as money.
But this is just play pretend. In software, you’re not dealing with money. You’re dealing with digital cigarettes.
Economists define money as something that has three functions: unit of account, store of value and means of value. But this definition is impractical for building ledgers.
Just like with payment methods, the traditional view of money is ineffective for building systems that emulate money.
This is The Payments Engineer Playbook, and today we’re looking at the intuitions of money, the API with which the outside world and the inside ledger system interact, and the guarantees that each party must preserve.
Keep reading with a 7-day free trial
Subscribe to The Payments Engineer Playbook to keep reading this post and get 7 days of free access to the full post archives.