Decentralization as National Security: Economic Warfare in the Age of Stablecoins

How much damage can stablecoins on public ledgers do, anyway?

If your economy relies on stables, is its infrastructure too tempting a target?

Before continuing, I will say that I have had two completely opposite responses to the main arguments in this post—that stables on public blockchains are trivially exploitable, either by chain halt or more esoteric attack.

First, I put this argument to my PhD supervisor and got a “so what?”¹

Second, I put a (much shorter) version as a question to Brunello Rosa, at a seminar on the topics in his 2024 book Smart Money. He said, “I don’t think the Americans are taking that risk seriously.” Whether or not they should be taken seriously is thus at the discretion of the reader.

So, caveat emptor on this post.

CBDCs may still be a long way off for most countries, but stablecoins are all the rage. After a solid year of stablecoin hype and maximalism, there’s no sign of the wave cresting, so it’s time to consider what the infrastructure for this new era of payments might look like, at a time when regulation is struggling to keep up, and institutions are weaker than ever.

In particular, the Americans have gone all-in on a strategy of using private companies to roll out stablecoins. Now, this isn’t necessarily a bad thing in terms of getting to market quickly,² but most of these projects are also relying on public, permissionless blockchains, and that is a problem.

I think this strategy fundamentally understates the risk of disruption to any of that infrastructure.³ Yes, even a total failure will only affect retail consumers (and possibly some small businesses), perhaps the effect would be negligible in the end. And hey, I might be wrong—what do I know? But this is my blog, and I’ll cry if I want to post essay-length musings if I want to.

I’m going to describe how some basic attacks work, and why an attack might be worthwhile, and conclude with some thoughts on decentralization, and whether locality and obliviousness are more useful design goals.

I believe the kind of ‘decentralization’ that most existing blockchain designs offer is likely not proof against the kind of problems a digital currency at scale might face.

How to Attack a Blockchain 101

The most basic kinds of attack we need concern ourselves with are buying, or taking over, the finality of a chain (at a threshold of say, 51% for Bitcoin, or 66.7% for a Tendermint or BFT-based network like Cosmos), and halting a chain.

For some networks, both the threshold that a chain could be halted by taking voting power or hash power offline is the same threshold (what the Nakamoto Coefficient terms the operative threshold).

However, for others, such as the Tendermint-based blockchains in the Cosmos ecosystem, the takeover threshold is 66.7% of voting power, while the operative threshold is 33.4%, the point at which a chain can be halted.

For most networks, simply halting the network is enough to do damage. Finding a zero-day that allows for double-spends or performing an esoteric attack on its cryptography is likely not necessary. In fact, in both the cases I’ve experienced of cyber attacks on blockchains, zero-days were simply used to inject non-determinism into the application state, thus halting the chain when nodes reported different results for a piece of computation.

Since Satoshi’s whitepaper it hasn’t exactly been a secret that the risk of attack is major and only incentives and agent independence keep the party going. Satoshi relied on the rational behaviour of miners to avoid undermining their holdings (assuming that they have what Budish et al. (2024) would call “stock value” in the asset, or what you might call skin in the game).

Budish et al.’s argument has the implication that any attack which is ‘cheap’ to execute⁴ might be free if the attacker has no ‘stock value’, or token holding. The fact that most penalization mechanisms for adversarial actions—be it a rewrite or double spend—are ex-post only makes this harder to reason about.

Houy (2014) argued that a Proof-of-Stake cryptocurrency was even more vulnerable, and that any economic attack would be free for a different reason—that if agents plausibly believe an attack will succeed, they must assume the collapse of the cryptoasset, and sell their tokens to the attacker to avoid ruin.

Budish’s other 2024 paper showed that the cost of securing Bitcoin scales linearly—making it impossible to categorically secure at scale in the face of a large enough attacker, and raising questions of every chain with a different security model or a lower market cap.

Luckily for stablecoins, the easiest and cheapest attacks are on cryptoassets that are endogenous tokens—without external backing or security. Thus the risk is less undermining confidence and the token going to zero as it is disruption or destruction of the underlying ledger.

However, this is an important point—if you launch on a blockchain like Ethereum, you are taking on the technical risk of that ledger and the economic risk of its endogenous token. Just because your externally-backed stable isn’t⁵ vulnerable to going to zero due to a social attack doesn’t mean you’re safe from them.

What if Pearl Harbor, except Shitcoins

So my question: what happens if (a) these systems get adopted at scale, and (b) a sufficiently motivated adversary decides to attack them? I think it would make the Terra/LUNA fiasco look like a footnote.

Perhaps a nation state wants to seed chaos before an invasion of a neighbour, or simply to grief and cause economic damage via disruption (although you would probably keep this in your back pocket for a special military operation occasion; once the stunt has been pulled, it’s unlikely to work twice).

Okay, this doomsday scenario sounds somewhat possible when stated with enough confidence. However, as my long-suffering supervisor pointed out, “so what?”

Whether or not there is a second-order effect, the most likely outcome would be a sort of minor chaos, unless the contagion spread to wider markets, and it’s not clear that the outcome would be a beneficial chaos to the attacker. Or, to paraphrase the argument sent my way:

So you’ve gone into an auditorium with a BB gun, and you’ve shot somebody. Now they’ve got a slightly painful arm, and everybody knows you’re a Bad Guy. Is that really worth doing?

Facetious as ever, I shot back with something like:

Well, if you go in with a black-sprayed BB gun⁶ and shoot the guy on stage, maybe there’s security, maybe they shoot somebody else while shooting at you, and then the chaos gets really out of hand.

Alright. It’s probably not the best example. Getting shot for pulling a griefing stunt is not exactly a dominant strategy. Still, if you’re in a position where you’re already set on being a “bad guy”—perhaps tomorrow morning you will launch an invasion of Ukraine—and you’re reasonably confident that any ill effects will be outweighed by your expected value on success, then it could be worth it.⁷

The Dark Forest

Now, like the true charlatan that I am, I can reveal my true purpose. Just like one of those thought-leaders posting about how AI is going to take jobs (and save businesses zillions) that turns out to be incubating an AI startup, I have a vested interest in oblivious systems. Not private systems, or even systems with privacy-by-design, but systems with obliviousness-by-design.

Decentralization is in the title of this post, but it’s a tricky concept to nail down. The Nakamoto Coefficient mentioned previously is sometimes used for it, and there’s various industry and academic definitions for it. I’m the lead author on a paper which suggests a new model for it. Shilling our paper isn’t the goal here, however, but to question what the desired outcome is of decentralization.

If the goal is systemic robustness, then I would argue that locality is perhaps a more relevant concern,⁸ as you reduce your systemic risk in return for different trade-offs. Locality (or local centrality) is closer in shape, I would argue, to the kind of ‘decentralized’ system that was discussed in Paul Baran’s original 1964 paper that defined ‘decentralization.’

Obligatory diagram from Baran’s paper

If the goal is agency, then perhaps obliviousness is a more relevant issue,⁹ as other agents cannot track, monitor, control or trivially attack you. Pseudonomity is not good enough. This indeed is part of the reason Kahn et al. (2005) make privacy a requirement of any definition of ‘money’, something many stablecoins lack.¹⁰

This is especially true of payment systems, where any payment system necessarily requires some means of identification. In the examples of attack before, you’re exposed to not just every stakeholder or user in the system, but any agent, anywhere that can see your history, or even that can infer you exist.¹¹

Stable, account-style identifiers make accounts trivially targetable, while the kinds of network-level attack described previously can be mitigated by a combination of locality and obliviousness. A global shared ledger implies a single point of failure, a fact that is trivial to intuit, but one which has far-reaching consequences for both governance and counterparty risk.

For science fiction fans, the obliviousness point is a little bit like in the novel The Dark Forest, by Liu Cixin. In the novel, the solution to the Fermi Paradox is that civilisations attempt to go unnoticed by the wider galaxy. To announce your existence to a hostile universe results in the destruction of your civilisation.

Revealing your crypto holdings¹² isn’t quite the same level of existential disaster, but it’s a little like getting doxxed—that genie is hard to get back in the bottle.

Indeed, decentralization can also be thought of as your exposure to risk—at least in terms of the operative subsystems or governance mechanisms that guarantee integrity in the system. I’m simplifying a little bit, but performative decentralization, or ‘decentralization theatre’ does not move the needle on the topology of a system when described this way.¹³

Additionally, as touched on above, systems may have global and local centrality, as we described in our paper for the Sark architecture. This is a crucial distinction, when considering ledgers with global shared state—they necessarily have a single point of failure that is system-wide.

Systems with local centrality may be compromised at the local level, but the contagion is not system-wide. Again, in some ways, this is closer to Paul Baran’s original conception of the term ‘decentralization’.

Regardless of how you define it, the reality is most existing public, permissionless blockchains are not very decentralized. Taking a widely-used industry metric, the Nakamoto Coefficient, we see that for many chains it is often very low in terms of key metrics, such as validator count.

Elsewhere, taking an academic heuristic, the Edinburgh Decentralization Index MDT,¹⁴ many chains due to Foundation delegations or stake concentration violate the MDT.¹⁵

Conclusion (or, maybe we should just use PostgreSQL)

The end result is that either chains need to decentralize further, and not merely in a performative way, or accept other trade-offs, such as local centrality, in exchange for greater systemic robustness.

If you launch a stablecoin on a ledger, obviously you take on the risks of that ledger—unless of course, the use of the ledger itself is performative, and behind the scenes your actual system of record is a normal database duplicating the data, like PostgreSQL.

If your system of record isn’t the blockchain, then using one at all is largely pointless.¹⁶

In our work on Sark, we seek to have a more disintermediated, user-custodial system with fungible assets while still effectively envisioning it being run in a permissioned or consortium way at the node level.

As the users and implementers of stablecoins on systems that include a ledger, we have to evaluate which properties we care about, and carefully weigh up performative security versus actual security.

For most users, a more centralized system that is honest about the topography of its centralization might in the end be a better fit than a more decentralized system that in practice is largely perfromative. There’s a reason regulated banks are the way most people interact with the financial system—how much risk users are comfortable with.¹⁷

1. Indeed, when I described the premise in conversation, somebody else simply said, “isn’t that obvious?”

2. Let’s not ignore the fact that it is problematic in the extreme that the sitting president has a vested interest in being able to profit from stablecoin proliferation as a result of his family business interests.

3. For an interesting hypothetical scenario post on internet infra, see my friend Nick’s post from 2023, as well as the follow-ups. Somehow I missed it at the time, and only read it while preparing links and refs for this piece.

4. ‘Cheap’ in this case simply means ‘what cost is there to an attacker?’ If the only cost from an adversarial action is the loss of value of any held tokens, then the action is potentially cheap, only made expensive if the tokens, and ledger collapse entirely. Even then, an attacker only loses any ‘stock value’, or token holdings, which might be slim or zero.

5. One would hope, unless somebody undermines faith in your stable’s backing or value.

6. Important data point: in the UK, unless you’re part of an airsoft club, BB guns are typically sprayed bright colours, with a red stopper at the end of the muzzle.

7. The counter argument here is simple—any sufficiently dramatic invasion would, of course, create greater market chaos than any attack on a stable could do. Think China and Taiwan. In such a case, the attack would be unnecessary, if the only goal was economic chaos.

8. Locality both as described below at a systemic level, and also arguably in terms of infrastructure sovereignty. In a permissionless, public network this could be node operators, whereas for a consortium network this might be universities, central banks, et cetera.

9. Crucially, any oblivious payments system can be built to interact with systems where visibility is a feature, not a bug, for example working with DAOs (perhaps the oblivious-first model is actually better for some DAOs, but I digress) or NFTs. The obvious limitation is that once you exit the oblivious system via interop, any assets are subject to both the visibility and integrity paradigm of the destination ledger or system.

10. Furthermore, their models are interesting as they require ‘infallibility of memory’, which is why intuitively they map so well onto discussions of assets on a global, shared, ‘immutable’ ledger.

11. Consider in the case where a network has bridges that automatically generate you a counterparty address on a different network or meta-network. Alternatively, look at how addresses work in Cosmos; in both cases addresses can be inferred on other networks that you may not even have interacted with yet.

12. Although I would hypothesise that the belief that agents in a system are independent means that they have more—but not full—agency to behave as if they are independent, even if they are in practice not.

13. “A blockchain system fails the Minimum Decentralization Test (MDT) if and only if there exists a layer for which there is a single legal person that controls a sufficient number of relevant parties so that it is able to violate a property of interest.”

14. At least on what I call the ‘network topology’—the physical structure of the network. They’re not much better in governance terms but in that area belief can keep a system stable until there is a crisis.

15. Note that I include stablecoins in this, if they are associated with an account on a public ledger. Indeed, there’s also the uncomfortable fact that any stablecoins that rely on a public, permissionless ledger, even with privacy affordances baked into their protocol, take on the risk of that ledger halting even if they do not reveal user data.

16. With one possible exception: if, for example, you wrote proofs to a public ledger from your system and provided those to clients as visible artifacts, simply because… building a web portal is hard? Sark relays (Porters) do a version of this where the ledger instead serves as a core element of the system. Additionally, relays are not fungible from the point of view of the user.

17. Yes, it’s also a question of access and opportunity in many cases, but that is a very big and complicated subject that is well beyond the scope for this post.