The three descriptions
Any deployed cryptoeconomic system is described three times over.
There is an economic description: agents, actions, incentives, a state space and the mechanisms that move it. There is a technical description: contracts, accounts, standards, what is on-chain and what is not, who may call what. And there is a legal description: what the assets are, who is liable for what, which activities are regulated, where value accrues and therefore who is taxed.
Each is written by different people, in different notation, against different standards of rigour. Each is internally coherent. And they are descriptions of one object, so they have to agree.
They do not agree by default. They drift apart continuously, and every gap between them becomes a defect that no individual specialist is positioned to notice — because from inside any one description, nothing looks wrong.
What drift looks like
Three examples, all real, all from systems I have worked on or reviewed.
A monetary design taxes consumption and redistributes the proceeds to holders who did not spend. Economically this is clean: it funds a return on money out of activity rather than issuance. Legally it may create two taxable events and a reporting obligation where burning the same tokens would create none. The economics and the tax treatment disagree about what the burn parameter is, and only someone reading both notices that a monetary lever is also a liability lever.
A governance design makes every economic parameter adjustable by token holders, because that is what decentralisation is supposed to mean. The legal structure that wraps those holders covers exactly what they control — so maximising governance scope maximises the surface the wrapper must cover, and the liability that comes with it. The instinct to make everything governable is directly opposed to the instinct to keep exposure small, and neither the governance designer nor counsel owns that trade-off.
A token has utilities that consume balances without a transfer. That is economically natural — you spend, the balance falls. It also breaks strict ERC-20 semantics, which is what institutional custodians require in order to hold the asset at all. A mechanism decision made on a whiteboard silently disqualified an entire class of stakeholder, months before anyone would have found out.
In each case the specialist work was correct. The failure was in the seam.
The job is the seam
This is what I think the protocol designer's job actually is, and why I do not think it reduces to any of its inputs.
It is not doing the economics. Formal mechanism design is a research discipline and it is frequently better done by researchers who spend all their time on it. It is not writing the contracts. It is emphatically not giving legal advice. On the systems I have led, the derivations were done by a specialist research group, the contracts by protocol engineers, and every legal conclusion by counsel.
The job is to decide what question each of those workstreams is answering, to know enough of each discipline to tell when an answer is load-bearing, and to own the integration — including the decisions where one discipline's correct answer has to be given up for another's.
Concretely, that means setting the scope a research group works against — the return must be funded from activity, not issuance is a design constraint, and it determines everything the derivation can look like. It means recognising when a formal result cannot be implemented as stated and sending it back. It means carrying a legal constraint into an economic structure, and being the person who knows that the pooling architecture exists for regulatory reasons rather than economic ones, so that nobody later optimises it away.
Where the method came from
I did not arrive at this from theory. It came from running the same loop on progressively harder systems.
Automated market makers were the first system I worked on where the whole loop was tractable end to end: derive the invariant, specify the mechanism formally, model it, verify the model against the specification, implement it, and then teach it. AMMs were ideal for that — simple enough to state completely, rich enough that stating it completely mattered, and public enough that you could check your answer against a live system. Working out what a formal specification of a constant-product market actually contains is a small exercise with an outsized return, because it is the first time the whole method is visible in one artefact.
Everything after reuses that loop on problems where one part gets harder. Contribution economies add a lane the AMM work never needed — legal structure as a design input rather than a compliance review at the end. Prediction markets close the remaining gap by taking a specification all the way into contracts that strangers trade against, where being wrong is visible.
The methodology is what accumulated across those, not what was applied to them.
Why validation, not assertion
The recurring failure in this field is not bad mechanisms. It is mechanisms that were never checked — designs asserted in a whitepaper, implemented directly, and discovered to be wrong by their users.
The alternative is unglamorous and it works: declare the properties you want, design a mechanism that enforces them, then demonstrate it holds — in a specification, in simulation, and in a contract someone can trade against. Each of those catches a different class of error. Specification catches incoherence. Simulation catches dynamics you did not anticipate. Deployment catches everything you assumed about people.
And a fourth check, which most teams skip: introduce the system to real users in an order where no intermediate stage has perverse incentives. Designing an economy is tractable. Designing one that can be introduced into a live product, under a real company's constraints, is where the failures actually are — and it is the part of the work that only exists in the seam between the three descriptions.
What this means for how I work
I take responsibility for systems rather than for deliverables. On a protocol I lead, I expect to be the person who can explain why the monetary parameter is what it is, why the account model is what it is, and why the legal wrapper covers what it covers — and, more importantly, which of those three had to give way to the others and what that cost.
That requires enough depth in each discipline to be a real interlocutor and enough discipline to not pretend to be the specialist. Both halves matter. A protocol designer who cannot read the derivation cannot direct the research. One who thinks they should have written it will not commission it in the first place.
Related work
- Specifying Uniswap — the method on its simplest complete example.
- Sequencing a token economy into a live product — legal structure as a design input.
- How the work braids — the same loop across eight years and three problem domains.