Mechanism design

Goals first, rules second

Most token work runs forward. Someone proposes a feature, the team argues about whether it sounds good, and the discussion moves on. Mechanism design runs the other way. You write down the outcome the system has to produce, then you go looking for rules that produce it as an equilibrium, on the assumption that every participant acts in their own interest and tells you nothing they would rather keep to themselves.

The prize committee's own account of Hurwicz's formulation makes the machinery explicit. A mechanism is a communication system in which participants exchange messages that jointly determine the outcome, and those messages may carry private information such as an individual's true or pretended willingness to pay. The mechanism is a machine that compiles and processes what it receives. Each agent maximises their own payoff and may withhold disadvantageous information or send false information. Comparing two designs therefore means comparing the equilibria of the two message games they define.²

That last sentence is the discipline in one line. You do not compare mechanisms by comparing their descriptions. You compare them by comparing what people do when they play them.

The lineage, and why a founder should care about it

The Royal Swedish Academy of Sciences awarded the 2007 prize jointly to Leonid Hurwicz, Eric Maskin and Roger Myerson for having laid the foundations of mechanism design theory. The stated motivation is the same problem a token designer has: information about individual preferences and available technologies is dispersed among many actors who may use their private information to further their own interests, and the theory exists to distinguish situations in which markets work well from those in which they do not.¹

The technical lineage is dated and specific. Hurwicz's work in 1960 and 1972 marks the birth of the field. The revelation principle was extended to Bayesian settings by several researchers independently, and Myerson developed it in its greatest generality across 1979, 1982 and 1986, taking it into regulation and auction theory. Maskin gave the first general solution to the multiple-equilibrium problem in 1977, which is the origin of implementation theory.²

Sixty-five years of formal results sit under the phrase mechanism design. A deck that uses it to mean the team thought about incentives is borrowing standing it has not earned, and the economist on the other side of the table will know inside a minute.

Incentive compatibility is the constraint, not the goal

The definition is narrow and worth memorising. Under a dominant-strategy criterion, a mechanism is incentive compatible if it is a dominant strategy for each participant to report their private information truthfully, where a strategy is dominant when it is the agent's optimal choice irrespective of what other agents do.²

Put into token terms: the behaviour your documentation asks for has to be the behaviour that pays best, for every participant, whatever everyone else does. Not on average. Not for the honest majority. For each one, against every combination of the others.

There is a cost attached and it is the part practitioners skip. The revelation principle generalises Hurwicz's 1972 impossibility result to Bayesian Nash equilibrium, with the consequence that where participants hold private information, Pareto optimality in the classical sense is in general not attainable, and a standard of efficiency that takes incentives into account is needed instead.²

So the honest framing of a finished design is not that it gets the outcome the team wanted. It is that the team chose which impossibility to live with. A memo that reads as though nothing was traded away has not finished the analysis.

One good equilibrium is not enough

Maskin's contribution answers a question most token designs never ask. The revelation principle is useful, but it does not address multiple equilibria: an optimal outcome may be reached in one equilibrium while other, sub-optimal equilibria also exist, and participants may end up playing one of those. Can a mechanism be built so that all of its equilibria are optimal? Maskin gave the first general solution in 1977 and implementation theory grew out of it.²

Every token design has a happy path. Stakers stake, operators operate, users pay fees, and the numbers in the model come out. What implementation theory forces you to ask is what the other equilibria look like, and whether the system can fall into one and stay there.

Death spirals are the answer to that question. A reflexive design where token price funds rewards, rewards attract supply, and supply justifies the price has a second equilibrium: price falls, rewards fall in dollar terms, supply leaves, price falls further. No code is broken when that happens. The system is sitting in the equilibrium the deck did not draw.

EIP-1559, worked from the spec

The clearest example of this discipline applied to a live token is Ethereum's transaction fee mechanism. EIP-1559 puts a base fee per gas in protocol which moves up or down each block as a function of the gas used in the parent block against the parent's gas target, where the gas target is the block gas limit divided by the elasticity multiplier. The base fee per gas is burned. Only the priority fee reaches the block producer.³

The constants turn it into arithmetic. The elasticity multiplier is 2, so the gas target is half the maximum block size and a completely full block is twice the target. The base fee maximum change denominator is 8, so a full block raises the next block's base fee by one eighth, or 12.5%, and a completely empty block cuts it by the same proportion. The initial base fee was set at 1 gwei.³

Run it forward. Ten consecutive full blocks take a 1 gwei base fee to roughly 3.25 gwei. Ten consecutive empty blocks take it back to roughly 0.26 gwei. That is the entire control loop. No governance vote, no oracle, no discretion, just a rule reading one number off the previous block.

Now look at what the design bought. Under the first-price auction Ethereum used before, a user had to guess what to bid.⁵ Under EIP-1559 the price is posted, so a user can set a maximum and expect to pay close to the base fee. Nothing was added to the product. What changed is which strategy is optimal for the user, and the burn is load-bearing in that change rather than sitting on top of it.

The report card, and the fact that it is a report card

Roughgarden's report assesses the game-theoretic strengths and weaknesses of the proposal and explores alternative designs.⁴ That is what a mechanism analysis produces. Not a verdict. A scorecard with conditions attached.

The follow-on paper introduces two forms of incentive compatibility specific to blockchains: one protecting against deviations by profit-maximising miners, and off-chain-agreement proofness, which protects against collusion between miners and users outside the protocol. EIP-1559 satisfies both and is dominant-strategy incentive compatible except when there is a sudden demand spike.⁵

Read that exception again, because it is the habit worth copying. A real result names the conditions under which the mechanism stops holding. A design memo asserting a property with no stated failure condition has not been checked by anyone; it has been claimed.

The second transferable idea is off-chain agreements. It is not enough that no single participant gains by deviating. You also have to ask what two participants gain by agreeing with each other outside the rules you wrote. Most token mechanisms we are asked to review have never been put through that question, and it is where validator cartels, farming rings and sybil airdrop operations all live.

What separates this from adding features

John Conley's 2017 working paper states the practical stake plainly: designing a token has to take account of monetary theory, financial economics and game theory, and failing to do so can put an otherwise excellent project at risk.⁶ A good project is not protection. The mechanism is a separate piece of engineering and it fails separately.

Here is the test we apply, rule by rule. Name the participant the rule binds. Name what they know that you do not. Name the most profitable thing they can do other than what you want. Then show why they do not do it. If there is no answer to the third question, the rule binds nobody and it is decoration. If there is no answer to the fourth, you have a feature and you have been calling it a mechanism.

This is also why the work starts from the business rather than the token. A mechanism routes value that exists. It cannot manufacture value that does not, and no arrangement of staking, burning and locking will make a protocol earning nothing behave like one that earns something. The token is the instrument. The business is the thing it is an instrument for.