a16z: 8 Challenges in Blockchain Mechanism Design
TechFlow Selected TechFlow Selected
a16z: 8 Challenges in Blockchain Mechanism Design
Crypto and Web3 are rife with mechanism design problems.
Navigating Web3 tides with focused insightsAuthor: Tim Roughgarden, Head of Research at a16z crypto
Translation: 0xxz, Jinse Finance
Deep study in any field teaches you to recognize that real-world problems are often just clumsy disguises of well-solved ones. For example, when I teach introductory algorithms, students learn how to identify problems that reduce to shortest-path computations or linear programming.
This kind of pattern matching works equally well in mechanism design—the so-called “reverse game theory” that uses incentives to achieve desirable outcomes. The tools and lessons from mechanism design are especially useful in auction theory, market design, and social choice theory.
Crypto and web3 are rife with mechanism design problems. One might assume many of these could be solved by applying textbook solutions or adapting old ideas in new ways. However, the unique challenges and constraints of permissionless blockchain protocols often force us to re-examine fundamental assumptions behind seemingly settled problems. This makes mechanism design in web3 complex—but it’s precisely these challenges that make it fascinating.
In this article, I’ll explore some of the key challenges facing mechanism design in web3. These may be familiar to crypto-native users, but a deeper understanding of mechanism design can offer all builders a fresh perspective on why these problems are so hard to solve. For those already versed in mechanism design, if you're exploring new applications, you may find the challenges posed by permissionless environments particularly intriguing.
But first: what exactly is mechanism design?
The formal roots of mechanism design trace back at least to 1961, when Columbia University economist and later Nobel laureate William Vickrey formally described the second-price sealed-bid auction. Although such auctions were used earlier—Goethe reportedly employed one in 1797 to sell his epic poem "Hermann und Dorothea," and stamp collectors widely adopted them in the 19th century—it wasn’t until Vickrey’s work that the mechanism was formally articulated. It’s now commonly known as the “Vickrey auction.” In this format, the highest bidder wins but pays the second-highest bid. This encourages bidders to reveal their true valuations and ensures the item goes to whoever values it most.
The Vickrey auction is an elegant and efficient design, adapted to real-world settings over time, with practice informing theory and vice versa. Like the Vickrey auction, the development of mechanism design as a formal discipline is a richly intertwined history of theory and practice—one both profound and beautiful.
Unlike game theory—which starts with a game and explores what rational behavior leads to—mechanism design begins not with a game, but with a desired outcome. The goal is to reverse-engineer a game such that the desired result (perhaps characterized by efficiency, fairness, or certain behaviors) emerges as an equilibrium. In the case of the Vickrey auction, the ultimate aim is to incentivize participants to bid their maximum willingness to pay without penalizing truthful reporting.
There are abundant opportunities for mechanism design in web3. For instance, a blockchain protocol might want to ensure honest participation (i.e., no deviation from expected behavior). Or it may seek accurate information about transaction value to allocate block space efficiently to the most valuable transactions.
Such mechanism design problems are always challenging, but they become uniquely difficult in the context of blockchains.
1. Lack of Trust
Designing mechanisms becomes significantly harder in blockchains due to the absence of a trusted party to enforce rules.
The whole point of using permissionless blockchain protocols is that you don’t need to trust any single entity or individual—only a minimal trust assumption that enough nodes running the protocol behave honestly.
Yet there’s an irony in many blockchain architectures: every batch of transactions added to the chain's history is ultimately the unilateral decision of a single node executing them within the protocol’s virtual machine.
You have no guarantee that this node is trustworthy.
This is partly why Vickrey auctions are rarely seen in blockchain contexts. A naive implementation would quickly fall victim to manipulation by untrusted block producers. Specifically, a block producer could insert a “shill bid”—a fake bid slightly below the winning bid—forcing the winner to pay nearly their full bid instead of the true second-highest price.
Such shill bids effectively collapse the Vickrey auction into a first-price auction, which helps explain why first-price auctions are so prevalent in web3. (There is a recent branch of traditional mechanism design literature on “untrusted mechanisms” that considers auction designs with untrusted auctioneers, though from a different angle.)
2. Collusion Is Common
Another reason mechanism design is difficult in blockchains is collusion among participants. For example, second-price auctions are vulnerable to side payments. The logic is simple: since the winner pays only the second-highest bid, bidders can bribe the second-highest bidder to submit a much lower bid.
Academic literature on mechanism design doesn’t dwell much on this issue, perhaps because collusion—especially with side payments—is hard to enforce in the real world. After colluding, the winner could simply renege on the bribe, making credible side payments difficult. (As the saying goes: “Honor among thieves.”)
However, in blockchain settings, potential colluders can often use smart contracts to make binding commitments, making collusion practically feasible. Another reason is the lack of mechanisms to deter collusion with side payments—many systems follow a “price posting” model, revealing only prices and nothing else.
Worse still, protocol users may not only collude with each other, but also with (untrusted) block producers—a scenario analogous to bidders colluding with auctioneers in traditional auctions.
Resistance to this final form of collusion was a major motivation behind the fee-burning component of Ethereum’s EIP-1559 transaction fee mechanism. Without burning (or otherwise withholding revenue from block producers), users and block producers could collude via side payments and circumvent any reserve price the mechanism attempts to impose.
3. Can’t Rely on Legal Enforcement
Collusion is clearly not a new problem. It has plagued real-world mechanisms for centuries. Yet, if you read the mechanism design literature, you might be surprised by how little attention it receives. While the literature directly addresses individual incentives to manipulate mechanisms, it often leaves collusion prevention to an implicit notion of “legal enforcement.” For example, participants might sign legal contracts agreeing not to collude, with violations referred to law enforcement. Mechanism designers can help by creating mechanisms where collusion is relatively easy to detect.
There’s an open secret in much of mechanism design: dependence on legal enforcement. While we can’t say there’s no rule of law in permissionless blockchain protocols—we frequently see law enforcement successfully prosecuting crimes on public blockchains—the degree of enforceability is far less than in traditional mechanism design applications.
If you cannot rely on external legal enforcement, the designer must address the problem internally. This philosophy permeates mechanism design decisions across blockchain systems. In Ethereum, for example, from EIP-1559’s burning of base fees to slashing misbehaving validators in its consensus protocol, internal enforcement mechanisms abound.
4. Larger Design Space
The design space in web3 is broader than what mechanism designers are accustomed to, requiring a rethinking of every problem. For example, many mechanisms involve payments, which in traditional applications would be made in fiat currencies like USD. But many blockchain protocols have their own native currency, and mechanisms within the protocol can directly manipulate this currency.
Imagine writing a traditional mechanism design paper where part of your mechanism description says: “Print a bunch of new money and distribute it to a group of participants.” Outside the blockchain context, this would sound absurd. But within blockchain protocol design, you can do exactly that. Protocols control their currency, so part of the mechanism can include minting or burning tokens.
This enables designs that would be impossible without a native currency. How, for instance, do you incentivize Bitcoin miners to follow the protocol? Through inflation rewards: minting new bitcoins to reward block producers. Without a native currency, such a design wouldn’t exist.
5. Native Currencies Bring New Risks
The previous point highlights the power of native currencies. You can perform two key operations: “minting” (as Bitcoin does to reward miners) and “burning” (as Ethereum’s EIP-1559 does to combat collusion). But native currencies introduce macroeconomic risks absent in traditional mechanism design: microeconomic design choices can have macroeconomic consequences.
In traditional mechanism design, there’s no concern for macroeconomic forces. No auction design meaningfully affects U.S. monetary supply or inflation rates. But this is a novel challenge in web3. Let me illustrate with two examples—one involving Bitcoin’s minting, the other ETH’s burning.
Bitcoin’s use of block rewards—printing new coins to incentivize miners—forces it into inflation. Therefore, it requires a corresponding monetary policy to determine the inflation rate and how it evolves over time. Satoshi set a hard cap of 21 million bitcoins. With a fixed supply, the inflation rate must eventually approach zero.
Once inflation reaches zero, what will motivate miners to continue securing the network? The hope is that transaction fees will compensate for the missing block reward, though the likelihood of this remains uncertain. It’s well known that if transaction fees approach zero, Bitcoin would face serious security vulnerabilities.
Princeton computer scientists Miles Carlston, Harry Kalodner, Matthew Weinberg, and Arvind Narayanan highlighted another difference between transaction fees and block rewards. While block rewards are identical per block (at least between successive halvings), transaction fees can vary by orders of magnitude—introducing new sources of game-theoretic instability into the protocol. In this sense, the macroeconomic decision of a fixed supply cap imposes negative microeconomic consequences on the protocol and its participants.
Just as block rewards create inflationary pressure for Bitcoin, EIP-1559’s fee burning creates deflationary pressure for Ethereum. Within Ethereum’s protocol—which does use inflationary validator rewards—these two forces compete, with deflation often prevailing. ETH has become a net-deflationary asset, a macroeconomic consequence of microeconomic incentive design in its fee mechanism.
Is deflation good or bad for Ethereum? ETH holders love deflation, as their tokens appreciate over time, all else equal. (Indeed, this side effect may have helped sway public opinion toward adopting EIP-1559.) Yet the term “deflation” alarms traditionally trained macroeconomists, evoking memories of Japan’s lost decade in the 1990s.
Who is right? Personally, I don’t believe sovereign fiat currencies are the right analogy for cryptocurrencies like ETH. Then what is? This remains an open question requiring further exploration by blockchain researchers: Why can a deflationary currency support a blockchain protocol but not a sovereign nation?
6. Cannot Ignore the Underlying Stack
In computer science, one of our goals is modularity and clean abstractions—trusting components without knowing their internals. When designing or analyzing part of a system, you may need to know what functionality another part provides, but ideally not how it’s implemented underneath.
In blockchain protocols, we haven’t achieved this ideal. While builders and mechanism designers may prefer to focus on the application layer, they cannot ignore how the infrastructure layer operates and its intricacies.
For example, if you’re designing an automated market maker (AMM), you must account for the possibility that untrusted block producers control transaction ordering. Or, when designing a transaction fee mechanism for an L2 rollup, you must account not only for L2 resource costs but also for all underlying L1 costs (e.g., calldata storage).
In both cases, effective mechanism design at one layer requires deep knowledge of another. Perhaps, as blockchain technology matures, we’ll achieve cleaner layer separation. But we’re certainly not there yet.
7. Must Operate in Computationally Constrained Environments
The “computer in the sky” realized by blockchain protocols is computationally constrained. Traditional mechanism design focuses solely on economic incentives, ignoring computational feasibility (e.g., the famous VCG mechanism is infeasible for highly complex allocation problems).
When Nisan and Ronen introduced algorithmic mechanism design in 1999, they argued that mechanisms must incorporate computational tractability to be meaningful in practice. They proposed restricting attention to mechanisms whose computation and communication scale polynomially (not exponentially) with problem parameters.
Given the severe computational limits of blockchain VMs, on-chain mechanisms must be extremely lightweight—polynomial time and communication are necessary but insufficient. For example, scarcity is a key reason AMMs dominate Ethereum DeFi rather than more traditional solutions like limit order books.
8. Still in Early Stages
When people say web3 is early-stage, they often mean investment potential or adoption levels. But scientifically, we’re even earlier than that—and this only adds to the difficulty, despite the enormous opportunity.
Working in a mature research field brings benefits taken for granted: established models and definitions, consensus on core problems, shared metrics for progress, common vocabularies, extensive public knowledge, and accelerated learning through vetted textbooks, online courses, and other resources.
In contrast, in many areas of blockchain, we still lack clear models and definitions needed to think rigorously and make progress on key issues. What is the right concept of incentive compatibility in blockchain protocols? What are the layers of the web3 stack? What are the components of MEV (Maximal Extractable Value)? These remain open questions.
For those interested in the science of blockchains, this immaturity is a challenge. But getting involved early—right now—also offers unique opportunities.
Mechanism design has long been a useful tool at the internet’s application layer—for example, in real-time ad auctions or bilateral market design in e-commerce and group-buying platforms.
But in web3, mechanism design also informs the design of the infrastructure itself.
Recall the 1970s and 80s, when internet routing protocols were being debated and designed. To my knowledge, no experts in incentives or mechanism design were involved. In hindsight, we now realize such input could have been invaluable. In contrast, in web3, incentives were part of the conversation from the start—with the original Bitcoin whitepaper.
The current confusion around the “right” models, definitions, and success metrics for web3 is actually a sign that we’re in a golden age. Future generations of students and scientists will look back with envy: we are here, now, at the right place and time, with the chance to shape the trajectory of this technology. So while there may not be many textbooks yet, someday there will be—and what they describe is exactly what we’re building today.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
a16z
