Protocol engineering vs. app engineering

Why this matters

An app uses a protocol; a protocol is the rules everyone else's apps will run against. The first iteration of any protocol you ship is not optimised, polished, or even safe — it exists to falsify your mental model. Treating protocol work like app work (ship, get users, iterate from feedback) reliably produces protocols that look fine until an attacker shows you the hole you couldn't see.

Demo

Same problem, two framings. An app dev thinks 'how do I add staking to my dapp?'. A protocol dev thinks 'what's the smallest set of rules under which staking is well-defined for any participant, and what does an adversary maximise by deviating from them?'

Try it yourself

1. Pick one protocol you use (Aave, Uniswap V3, Lido). In two sentences each, state: (1) the rules every participant must obey, (2) the rule an attacker would most want to break.
2. For the same protocol, identify the smallest behavioural unit (one swap, one deposit, one slash). The protocol's first iteration must define this unit correctly — everything else is composition.
3. Read the Uniswap V2 whitepaper's 'Core' section. Note how few rules it actually has. That smallness is the load-bearing design choice, not the math.

Prompt your AI

Use these three in order. Each builds on the one before.

1. Basics & terminology

In one paragraph, contrast a protocol engineer's mindset with an app engineer's. What changes about who you optimise for?

2. Why it works (the mechanism)

Walk me through the design loop for a new protocol from blank page to a first iteration you'd put on a testnet — what comes first, what comes last, and what you deliberately omit.

3. Advanced — application & what's next

Pick a protocol you admire and identify three design choices its authors *didn't* make. What constraints ruled them out, and how would the protocol differ if those constraints relaxed?

References

• Uniswap V2 Core Whitepaper
• Vitalik — 'How to think about protocol upgrades'