Thread by @kaiynne

There has been significant debate within the DeFi community lately about centralisation risk, I haven't seen a strong argument for this approach, particularly with respect to trade-offs. So as one of the 'culprits', let me try: 1/20

First let me describe the "pure approach", you spend years writing and testing code, deploy it fully formed to mainnet with no ability to control any aspect of it once deployed. 2/20

Now the "impure approach", spend months writing and testing code, deploy it to mainnet with privileged functions that give the project team the ability to arbitrarily freeze the code or upgrade it with no outside input. 3/20

If you take the pure approach you can still upgrade the protocol after it is deployed, but it means migrating by redeploying new code and getting each user to migrate. This of course adds additional cost in terms of time for migration and managing user expectations. 4/20

How does L1 handle upgrades? A tightly choreographed dance between core devs, client implementors and miners. Which means upgrades are possible but several independent groups must agree or the network will split. This is basically the pure approach described above. 5/20

The pure approach reduces the risks of centralisation, but at the expense of a much larger risk: irrelevance in the market. There are decades of precedent that demonstrate your first intuition about what the market wants is likely to be significantly flawed. 6/20

Markets are not static, so the thing that was perfect when you started working on it two years ago may not fit the market that exists when you deploy it. This is a huge risk the pure approach struggles to address, because the feedback and iteration cycle is so slow. 7/20

The impure approach compels you to move fast and deploy quickly, but still exercise caution, just make a conscious decision to accept that this approach trades the risk of irrelevance for the risk of a bunch of other things, which I will try to list below: 8/20

1. Hacks, moving fast means that you increase the risk of hacks because you haven't tested the code for years and there is probably additional complexity in the functions that allow the contracts to be upgraded. 9/20

2. Theft, e.g. the team stealing user deposited user funds. These are pretty unusual for a smart contract protocol but the risk exists, particularly with any protocols where users are depositing funds 10/20

3. Software defects that cause loss of funds, think parity multisig, though that is not even a great example as it was probably closer to the pure end of the spectrum. 11/20

3a. That's right, even the pure approach doesn't offer a risk free path, you can still get blown up from some unknown unknown after years of toiling away perfecting your creation. 12/20

4. Regulatory interference, having control of the code means there is risk of regulatory interference. This is a significant risk, and while it is offset slightly by the code being open source it needs to be considered. 13/20

The reality is that all of the above risks are significantly mitigated by one thing, obscurity. When you first launch a new protocol it is likely no one is using it and there are few funds at risk. But you need to have a plan to get to the pure path. 14/20

This is the point that appears to be missed by a lot of critics of this approach, the end goal of the all of the projects taking this approach I have spoken to is reducing centralisation over time. 15/20

The impure path is just an interim phase in the lifecycle of a decentralised project. With the hope that the projects becomes valuable enough that people even care whether it is decentralised. 16/20

One of the risks here is sudden growth or an outage. If a project is even slightly unprepared they can suddenly be under significant scrutiny. This has happened to a number of projects, @compoundfinance, @0xProject & @synthetix_io to name a recent few. 17/20

The analogy I typically use is cutting bridges, when you launch you have a bunch of bridges that give you control over the system. Eventually you want to cut all of them, but you do it over time as you progress. 18/20

Keep in mind though, even after all bridges are cut, it is still possible to upgrade by deploying new code and migrating. But hopefully by this point the need to do this is rare and it is critical enough that all participants are motivated to do it. 19/20

The end game is a project that is as far along the decentralisation spectrum as possible, but that also delivers utility. The question is which approach has the highest likelihood of succeeding, we probably won't not know for a few years, but I am betting on impure. 20/20