In early 2026, a military cargo plane carrying 17 million freshly printed banknotes for Bolivia's central bank crashed near El Alto International Airport, scattering roughly $62 million in currency across one of Latin America's most densely populated cities. Thousands of people rushed to collect the bills. The central bank responded by voiding the serial numbers of every note that had been on the plane. And then the real chaos began.
Suddenly, nobody in Bolivia could tell whether their money was good. The voided bills were physically identical to legitimate bills of the same denomination — same size, same color, same feel. The only difference was a nine-digit serial number that might or might not appear on a voided list. The central bank released a mobile app for vendors to manually check each bill's serial number. Vendors responded by refusing to accept any bill from the affected series, legitimate or not. A juice seller in La Paz could not buy fruit because nobody would take her perfectly valid money. The entire currency system for those denominations functionally broke.
This is not just a story about Bolivia. It is a parable about fungibility — and it maps directly onto problems that software founders, SaaS companies, and digital businesses managing digital assets deal with every day.
Fungibility Is the Point of Money (And Licenses, and Access Tokens)
Fungibility means interchangeability. One dollar is the same as any other dollar. One fungible token of value is the same as any other token of the same type. The entire financial system depends on this principle. If you had to verify the provenance of every bill in your wallet before spending it, commerce would grind to a halt. That is exactly what happened in Bolivia: the central bank — the issuer of those notes — made money non-fungible, and the economy around those denominations seized up.
The same principle applies to software licensing and digital content distribution. A valid software license should be interchangeable with any other valid license of the same type. A legitimate API key should work the same as any other legitimate API key. A SaaS subscription should grant the same access regardless of when it was purchased or by whom. Fungibility is what makes these systems scalable — vendors do not need to evaluate the provenance or ownership history of each access credential every time a user logs in.
But what happens when some licenses, keys, or subscriptions are "voided" — terminated, revoked, or modified — while others remain valid, and users cannot easily tell the difference? You get the Bolivian cash problem applied to software.
When Your SaaS Subscription Gets "Voided"
Consider the parallels. A SaaS vendor decides to sunset a product, and some customers' subscriptions are terminated while others are migrated to a replacement. A license key is revoked because the vendor believes the customer violated the acceptable use policy — but the customer disagrees. A vendor is acquired, and the acquiring company decides to honor some existing agreements and terminate others. In each case, some "currency" (access, data, digital content) is voided while other currency of the same type remains valid.
The problems that arise are structurally identical to what happened in Bolivia. Customers cannot tell whether their subscription is still valid without checking. Downstream integrations and business partners do not know whether the data or services flowing from the SaaS product are backed by a live subscription or a terminated one. The uncertainty itself causes damage, even for customers whose subscriptions are perfectly valid, because third parties start treating all subscriptions from that vendor as suspect.
This is not theoretical. When a SaaS vendor experiences financial distress, begins limiting services, or announces a product discontinuation, the market reaction from customers often overshoots the actual impact. Customers who are not directly affected rush to extract their data and find alternatives — not because their service has been terminated, but because they cannot be sure it will not be. The uncertainty is the problem, not the termination itself.
The Serial Number Problem: Verification Costs and Trust
In Bolivia, the central bank's solution was a mobile app that let vendors type in a bill's serial number to verify whether it was voided. This is technically a solution, but practically it is a disaster. Every transaction now requires a manual verification step. The cost of each transaction increases. Speed decreases. Trust between buyer and seller erodes because every bill is treated as potentially invalid until proven otherwise.
Software systems face the same verification cost problem. License management systems, authentication servers, and subscription validation APIs are the digital equivalent of Bolivia's serial number app — they exist to verify that each access credential is still valid. Each check is a query against metadata tied to a specific certificate of access. When they work smoothly, the verification is invisible and the system feels fungible. When they break down — the license server is unreachable, the authentication service is slow, the vendor's API returns ambiguous responses — the user experience degrades and trust erodes.
For SaaS companies building products, this is a design lesson: your license validation and access control systems need to be fast, reliable, and unambiguous. A system that sometimes returns "unknown" instead of "valid" or "invalid" creates the same kind of uncertainty that wrecked Bolivia's small-denomination economy. Your customers need to know, instantly and definitively, whether their access is good. Ambiguity is the enemy of trust.
Data Portability as a "Valid Bill" Problem
The Bolivian crash also illuminates the data portability challenge in SaaS contracts. When a customer's subscription is terminated — voluntarily or involuntarily — the customer needs to get their data out in a format that is usable elsewhere. This is the digital equivalent of converting voided bills into valid currency before the window closes.
If the data export is in a proprietary format that only works inside the vendor's platform, the data is like a voided bill — technically yours, but practically worthless. Your intellectual property and business data lose their utility the moment they cannot move. If the export is in a standard, interoperable format (CSV, JSON, XML), the data retains its value because it can be imported into a replacement system. The "fungibility" of your data depends entirely on the format and the terms of the export.
This is why SaaS agreements must address data portability with specificity. The agreement should state the format in which data will be returned, the timeline for return, and the customer's right to export data at any time during the contract term — not just at termination. A customer who exports their data regularly, in a standard format, has insulated themselves from the "voided bill" problem. A customer who has never exported their data and discovers at termination that it is locked in a proprietary schema is holding currency that nobody else will accept.
Non-Fungible Licenses and the Rise of Usage-Based Models
The cryptocurrency world has spent years debating fungibility. Bitcoin is theoretically fungible — one Bitcoin should be as good as any other — but in practice, every Bitcoin is individually traceable on the blockchain. Bitcoins associated with stolen funds or illicit activity are worth less because exchanges and counterparties will not accept them. The nonfungibility of "tainted" Bitcoin has created an entire ecosystem of compliance tools, chain analysis services, and risk scoring systems. The rise of non-fungible tokens (NFTs) on blockchains like Ethereum took this concept further — each NFT represents a unique digital asset with distinct ownership, enforced by smart contracts rather than a central issuer. The NFT marketplace boom and bust demonstrated what happens when scarcity and provenance are the entire value proposition rather than interchangeability.
Software licensing is moving in a similar direction. Usage-based pricing models, per-seat licensing with individual user tracking, and cloud licensing systems that tie access to specific hardware or user identities all make licenses less fungible. A license that is valid for User A on Device B in Region C is not interchangeable with any other license. It is a unique, individually identifiable credential — like a non-fungible token on a decentralized ledger or a banknote with a specific serial number.
This has implications for how companies manage their software portfolios. As licenses become less fungible, software license management becomes more complex. Redeploying a license from one user to another — transferring ownership — may require the vendor's approval. Transferring a license to an acquirer in an M&A transaction may trigger restrictions in the license agreement. The "license" stops functioning like interchangeable currency and starts functioning like a specific, individually governed asset in a marketplace of non-fungible rights — with all the overhead that implies.
What Founders Should Take From This
The Bolivian cash crash is an extreme case, but the underlying dynamics — fungibility, verification cost, trust erosion, and the cascade effects of uncertainty — show up in software businesses constantly. Here are the practical takeaways:
Design your access systems for clarity. Your authentication and license validation systems should return unambiguous, instant results. "Unknown" is not an acceptable response. If a customer's access is valid, confirm it immediately. If it is not, explain why. Ambiguity destroys trust.
Make your data portable. If your customers cannot export their data in a standard, interoperable format at any time, you are creating a lock-in dynamic that will eventually generate resentment and churn. Portability is a trust signal. It tells customers that their data will remain valuable even if the relationship with you ends.
Negotiate your own SaaS agreements with termination clarity. When you are the customer, ensure your agreement specifies exactly what happens upon termination: how quickly you get your data, in what format, and whether the vendor can withhold it for any reason. Vagueness in termination provisions is the contractual equivalent of voided serial numbers — it creates uncertainty that compounds under stress.
Understand that trust is a system property, not just a contract term. Bolivia's currency problem was not caused by bad monetary policy in the abstract. It was caused by a single event that shattered the assumption of fungibility, and the recovery required rebuilding trust at every level — from the central bank to the juice vendor. Your relationship with your customers works the same way. The systems, contracts, and practices you build either reinforce trust or erode it, and the erosion can happen faster than you expect.
The Bottom Line
A plane crashed in Bolivia and broke the money. But the money was not really broken — the trust in the money was broken, and that turned out to be the same thing. Every SaaS company, every software licensor, and every creator building a digital business should understand this dynamic, because the same forces operate in every system that depends on interchangeable, trustworthy digital credentials — whether those credentials are fungible tokens of access or unique, non-fungible rights. Fungibility is not a given. It is an engineering decision, a contractual commitment, and a business strategy. Treat it accordingly.
At Turley Law, we help founders and technology companies across Connecticut, New York, and Massachusetts navigate the legal architecture of software licensing, SaaS contracts, and digital trust. If the ideas in this article resonate — or if they made you realize your agreements have gaps — we are happy to talk.
Schedule a free assessment to discuss how this applies to your business.
.jpg)
