Mechanism design document (MDD)

How it works

A whitepaper is a marketing narrative and a pitch deck is a sales tool. The MDD is the engineering artifact. Every design decision is explicit, every parameter is justified, every dependency is named. It covers the asset and market thesis, the legal entity structure, token supply architecture, the core operating loop of how value enters and circulates and exits, fee schedules, risk surfaces, and a journey for each user archetype.

The bar is deliberate: an independent smart-contract developer should be able to build from it without a phone call, and a sophisticated investor or regulator should be able to evaluate it without a verbal walkthrough. Ambiguity in the spec becomes a bug onchain. Parameters left undefined become attack vectors or governance disputes.

Why it matters

Token economies are interdependent systems. Change fee routing and you change token velocity, which changes price stability, which changes holder behavior, which changes fee volume. The MDD forces every layer to be designed together instead of assembled from independent calls made by different people at different times. That coherence is the difference between a system that behaves as intended and one that surprises its own builders.

Common mistake

Picture a protocol that defines its fee model in a smart contract, its supply cap in a whitepaper, and its governance structure in a six-month-old forum post. When those three contradict each other, there is no authoritative source. The MDD is the single authoritative source by design. Treating it as a documentation afterthought, rather than the primary design artifact, is the failure that costs teams the most.