This post is the expansion of my original Twitter thread “Beyond smart contracts and code audits: Why Token Engineering is important.”.
Intro
The web3 space is getting more secure every day. Professional auditors have been around for some time now, we’re seeing new programming lenguages appear and constant updates for those already in use. Even though we’ll never finish learning new things (everything keeps changing so fast!), we seem to already have a decent understanding of how building and verifying smart contracts work.
Despite all this, web3 systems as a whole keep failing. Some with pretty obvious design flaws that lead to insane amounts of losses, while others seem to die by natural causes.
We haven’t quite figured out yet how to actually make these systems work.
As interested as we seem to be in security and resilience, the reality is that smart contracts and all code involved with these protocols and applications don’t always paint the full picture, there’s always a wider set of implications behind them. And that’s something not everyone understands.
How will people react to different parameters? Why choose mechanism A vs B? Will my protocol resist economic or social attacks? All these questions are outside of the scope of a regular code audit, but are essential for a system to work in the first place.
Here is where Token Engineering comes in.
The need for Token Engineering
To understand token engineering, it’s important to remember that our fight for anti-capture and decentralized systems means that things built on top of them are not dependent on a single person or institution, therefore can not be fixed by anyone in particular.
In order to be prepared and capable of doing intentional token networks, we need set of practices, theories and tools to analyze, design, and verify these ecosystems. That, in a nutshell, is token engineering (see the yellow and orange area of the following graphic).
In fact, here’s some examples of applied token engineering:
-
Work on Ethereum’s beacon chain and PoS economic policy - agent based models.
-
Reflexer’s RAI Digital Twin - repo.
-
Conviction Voting model - repo.
These are all very advanced projects, some form part of remarkable pieces of engineering that demonstrate the potential of the space, like Ethereum’s move from Proof of Work to Proof of Stake (with all the added efficiency). Or the control theory based monetary policy of RAI, of which I do not think we understand the ripple effects that it will have in the long term.
And that is defenitely no easy task. The theory and tools are just being developed and the talent required to accomplish these tasks succesfully is as broad as it can get. At the end of the day, these are very complex systems at the intersection of multiple domains of knowledge.
We oftentimes make use of the cryptoeconomic flower to represent the beautiful complexity of the domains that compose such systems.
Far from a critique of code audits, what I hoped to accomplish here is to slightly broaden the awareness and paint the full picture of which things do we have to be careful of when designing or interacting with tokenized projects. Many of the things that go wrong have very little to do with the code itself, but in the abscence of better practices and tooling, it’s easier for us to point out and study
This post is just a bunch of lessons learned by some of the brightest minds in the space, you can find some more useful and in-depth reading here: