You’ve spent months crafting the perfect protocol. Every edge case handled. Every feature documented. You launch it with a polished whitepaper and a neat GitHub repo. Then nothing. A few stars, maybe a pull request fixing a typo, and then silence. The community never comes.
Sound familiar? If it does, you’ve made the same mistake that kills 90% of open-source protocols: you built a solution instead of a question.
The best protocols are not feature-rich. They are feature-poor.
Here’s the uncomfortable truth: the most successful protocols in history succeeded not because of what they did, but because of what they didn’t do. HTTP didn’t tell you how to build a web app. It just said ‘here’s how to transfer hypertext.’ TCP didn’t prescribe your application architecture. It just said ‘here’s how to send packets reliably.’
These protocols were blank canvases. And that’s precisely why they changed the world.
I call this the Mimeng Principle (named after a deep analysis of 1,000+ viral tech articles): the true value of a foundational protocol is not measured by its built-in features, but by its generative potential—the unexpected applications the community builds on top of it.
Yet most protocol designers do the opposite. They try to be smart. They pack in opinionated APIs, rigid data models, and precise use-case definitions. They think they’re being helpful. In reality, they’re being prescriptive. And prescriptive protocols die.
If your protocol dictates what builders should build, you’ve already limited its potential.
Think about it. Ethereum gave us a Turing-complete virtual machine with almost no built-in applications. The community built DeFi, NFTs, DAOs—none of which the original creators could have imagined. Bitcoin gave us a simple ledger and a scripting language so limited it’s almost unusable. That limitation sparked an entire ecosystem of second-layer innovations.
The pattern is clear: protocols that leave the most room for chaos generate the most value.
Now, here’s the twist. You might think I’m arguing for lazy design. I’m not. The hardest part is building something that is just rigid enough to be reliable, yet just open enough to invite surprise. It’s a tightrope walk. You need to enforce the invariant that makes the protocol trustworthy—the cryptographic guarantee, the ordering rule, the minimal interface—but then step back and refuse to fill in the blanks.
Take a look at the Axis Protocol on GitHub. I don’t know what it’s trying to be. But the question I ask when I evaluate any new protocol is the same: What can I build with this that you never thought of?
Most protocols fail not because of poor engineering, but because they are too prescriptive.
If you’re building a protocol, stop asking ‘what does it do?’ Start asking ‘what can others do with it?’ Provide primitives, not products. Offer building blocks, not blueprints.
Neutrality is death in content—the same applies to protocols. Take a side. Choose to be dumb on purpose. Let your users be the smart ones.
The next time you push a commit, ask yourself: is this commit adding a feature or removing a possibility? If you’re not sure, leave it out.
The most successful protocol is the one that makes its creator irrelevant.
Now go build something that you can’t control.
FAQ
Q: But what about protocols that succeed with rich features, like GraphQL?
A: GraphQL succeeded despite its richness, not because of it. Its core—a type system and query language—is still a minimal primitive. The ecosystem built tools like Apollo and Relay on top. The moment it became too opinionated (e.g., Apollo's cache), fragmentation followed.
Q: How do I balance reliability with openness?
A: Enforce only the invariants that make the protocol trustworthy: security, ordering, identity. Everything else is a suggestion. Think of it like a street grid—you lay the roads and the plumbing, but you don't design the houses.
Q: Isn't this just 'build your own platform' advice repackaged?
A: No. Platforms are vertical; protocols are horizontal. A platform tells you what to build on it. A protocol lets you build anything. The difference is control: the former seeks to own, the latter seeks to enable. You want the latter.