Randomness in Plain English
You might think that 32535354 is more random than 00000000. After all, the first sequence of numbers appears to be completely arbitrary, while the second seems to repeat the same digit over and over. However, the concept of randomness is not always as straightforward as it may seem.
Suppose there are 100 potential events, and if their likelihood is evenly distributed, meaning no outcome is more likely than the others, we consider them to be random. Conversely, if the chance of a specific event, let’s say A, is 90%, then it’s no longer deemed random. Randomness is about probability distribution.
When you roll a dice, the probability of getting any particular number from 1 to 6 is 1/6. This probability is equally distributed among all the possible outcomes. Thus rolling a dice can be seen as random events.
So even though 00000000 appears less random, if the probability of getting 00000000 is the same with that of getting 32535354, then there isn’t much difference between them in terms of randomness.
Semantic Versioning
Semantic versioning helps developers understand the compatibility and impact of changes to software over time.
It uses three digits separated by dots to represent a software version number. e.g. 1.3.0
These digits represent the major, minor, and patch versions of the software, respectively.
MAJOR.MINOR.PATCH
- You increment the
MAJORversion when you make incompatible API changes. - You increment the
MINORversion when you add functionality in a backwards-compatible manner. - You increment the
PATCHversion when you make backwards-compatible bug fixes.
Now, when you install software, how do you specify a range of compatible versions?
You can use the tilde ~ and caret ^.
The tilde matches the most recent minor version (the middle number). ~1.2.3 will match all 1.2.x versions but will miss 1.3.0.
The caret will update you to the most recent major version (the first number). ^1.2.3 will match any 1.x.x release including 1.3.0, but will hold off on 2.0.0.
Here’s a comparison of the ranges specified by tilde and caret:
- ~1.2.3: Accepts any version from 1.2.3 to 1.2.x
- ^1.2.3: Accepts any version from 1.2.3 to 1.x.x
How to Design a DeFi Protocol
I started to design Carapace protocol in 2021. It has been one of the most intellectually challenging and stimulating experience.
I’m nowhere near a position to give advice yet but I will share some lessons learned. Hopefully, my future self and others will find these lessons useful.
Talk to Users
My biggest mistake; I didn’t talk to users enough. The earlier you talk to them, the better. Our users usually asked the toughest and critical questions. They gave us good insight that nudged us to change our protocol design. It’s even better if you are building something that you want.
Collect Mental Models
There are mainly two sources to collect mental models for your DeFi protocol. The first is traditional finance. DeFi protocols usually have something similar in traditional finance. The second is other DeFi protocols. There are some design patterns in DeFi such as an automated market maker, cToken model, veTokenomics, a cycle system, protocol owned liquidity or governance minimization. Keep collecting these models and integrate them into your protocol if it makes sense.
Figure Out Your Design Principles
In my humble opinion, all the DeFi protocol should follow some design principles such as fairness, security, market thickness, aligned incentives, simplicity, composability, privacy, the secondary market liquidity, usability, capital efficiency, and gas-efficiency. But there will be trade-offs you need to make. For example, if you want to make your protocol secure, it might become more complex. Moreover, the magnitude of importance in each principle varies from a protocol to protocol. There are some principles like the secondary market liquidity that some protocols do not care much. You want to make a decision about which principles you value the most.
Get Good At Math
I designed the first version of most of the formulas in our protocol but they were imperfect. I needed some help from an ex-Wall Street quant. I don’t think a single person needs to design every part of a protocol but at least as a founder you need to know enough mathematics to understand a mathematical formula in depth.
Understand Underlying Technology Well
If you want to build your protocol on top of the Ethereum blockchain, deeply understand how it works and start writing code on top of it. Otherwise, you will design something that doesn’t need the blockchain or something that is not feasible. I programmed and tinkered with technology to figure out how it works and what’s feasible. If you are not technical, work with technical people and try to teach yourself how underlying technology works as much as possible.
Keep Refining Your Model
Designing a DeFi protocol is like having a bunch of pieces in your brain to solve a puzzle. You constantly combine them in new and different ways to figure out the right model. It’s challenging because you don’t know how many pieces you need, which pieces you need or how to fit them together in the right way.
And you never want to stop. You want to keep refining your model every time you encounter a new problem and opportunity.
Steve Jobs articulates this point well.
Make a List of Questions
We keep a list of hundreds of questions. I categorize them into critical, key and normal questions, and continuously update them.
Think With Specific Numbers
Once you have a somewhat coherent model, you want to inject data into your abstracted model to see if it works as intended.
We often fall into a victim of thinking in high-level and not thinking about specifics. What happens when you have $1m liquidity in a pool? How does the capital level in a pool affect your price and user behavior?
Ideally, you want to write a script(e.g. the Jypyter Notebook with Python) to simulate your model, but you can start manually by thinking about some specific examples with numbers.
Hack Your Protocol
Put yourself in a position of a malicious hacker or profiteers. How do you game your system? Can you cheat for your financial gain? Can you front-run? Can you flash-loan attack? What happens if there is a bank run? Can you manipulate your system with the Sybil attack? Can you collude?
Talk to Smart People in Your Field
I’ve talked to smart people who ask tough questions to find holes in our design. And of course, I discussed it my team almost everyday to continuously improve our idea and push things forward.
Don’t Give Up
People have told me that our protocol won’t work. I’ve had existential questions that I could not answer right away.
Although there is always a chance that we may be building what people don’t want, I never stopped thinking about the questions and finding the right solutions.
MakerDAO was inspiration for me. I used to think that building a decentralized stablecoin was impossible(back in 2014/2015). But MakerDAO did it and they proved me wrong. Ever since then, I decided to start from an assumption that something that seems impossible can be done.
Over time, despite many problems yet to be solved, I, simply assumed that any remaining issues would be overcome by the hard work and determination.