Crypto: Medium of Exchange, Store of Value, and the Inherited Constraints

This article is based on my thoughts originally shared in the following Zcash Forum post. Even though the post was made in the context of Zcash, the same structural argument applies to Bitcoin and, more broadly, to any cryptoasset with a fixed or highly inelastic supply. The question is not what these systems want to be, but what their design already commits them to.

My core thesis is that in modern finance, Medium of Exchange (MoE) and Store of Value (SoV) are not, and realistically cannot be, the same thing. Zcash’s as well as Bitcoin's design choices effectively force them into the SoV bucket, whether we as a community explicitly acknowledge that or not. If that framing is correct, it has important implications for roadmap decisions and project prioritization.

Historically, MoE and SoV were the same, but largely in an era where financial complexity and credit intermediation were limited. As commerce scaled and financial systems became more complex, these roles separated.
This did not happen in a top-down approach, but rather it has been market forces that shaped the current system.

Why Volatile Assets Fail as MoE at Scale

From a business operation point of view, MoE is more important than SoV. Credit is unavoidable at scale: capex, inventory, payroll, receivables, and payables all require it.

Managing credit requires matching cashflows with liabilities and assets. If the two sides of the book are denominated in different units, and one of those units can fluctuate 20–30% per quarter, the business effectively becomes a trading desk. At that point, it stops focusing on its original core activity.

The global MoE today is not the USD but the elastic credit system built on top of it. The Eurodollar system: repos, bank balance sheets, FX, etc. The unit of account becomes stable because supply is allowed to expand and contract. While SoV in the current system include real estate, stocks, treasuries, etc.

As a result, SoV usage is episodic rather than operational. Most individuals and companies do not use SoVs on a daily basis. Instead, they hold them as part of long-term investment portfolios and capital allocation strategies, transacting infrequently.

Elasticity, Inelasticity, and Why Design Choices Matter

A functioning MoE moved to a ledger-based system that allows for supply elasticity, primarily through credit expansion and contraction. This elasticity is crucial because it dampens demand shocks. When demand for money increases, supply can expand; when demand contracts, supply can shrink.

A SoV, on the other hand, benefits from inelasticity. Scarcity is the point. But because supply cannot adjust, volatility becomes the adjustment mechanism. This volatility is not just early-stage noise or a function of low adoption. It is structural to the design.

Given the limited supply and that enough demand and participants exist, Zcash and Bitcoin are viable SoV. But this comes with a specific set of properties. SoVs are highly reflexive and sentiment-driven. They absorb macroeconomic shocks rather than smoothing them.

If these blockchains keep an inelastic supply by design, then they have already chosen the SoV path and many MoE-oriented proposals are internally inconsistent with that choice.

This is not an ideological claim. It is a structural one. Intentions do not override constraints.

Roadmap Implications of a SoV Positioning

Understanding the situation is the foundation to make better decisions.

If SoV is the path, then certain themes become less critical: everyday transactional UX, very high throughput, or optimizing for constant daily usage. Other themes become central: custody, access, on/off ramps, and liquidity.

Denying this leads to incoherent roadmap decisions, where the system is optimized and resources are spent for use cases its own design undermines.

If these tokens do not become MoE, acquiring them will primarily happen through exchanges rather than direct payment for goods and services. Thus, on/off ramp availability and their liquidity become central.

For example, in the case of Zcash, I argue against forced privacy as that will increase the odds of being delisted from major, regulated exchanges.

This is not a judgment, but an effort to make explicit that system structure constrains outcomes. In monetary systems, design choices tend to reassert themselves regardless of the intentions of builders or users.