Should smart contracts be allowed to change?

Questions raised and lessons learned during a wild day and with funds lost in decentralized finance.

7 min readApr 23, 2021

It started with a planned upgrade of the popular protocol Venus on the Binance Smart Chain. Shortly after that things went south for some. Funds were lost and kept leaking. Users were confused and angry. Developers and community managers did what they can.

The projects involved have released their incident reports by now, most prominently Autofarm, Belt, and Beefy. These explain their respective problems and events in detail.

With this article however I’d like to look at this incident from a more general perspective. For me this issue raised fundamental questions about the evolution of smart contracts.

The road to failure

First, a brief history of the relevant events leading to the incident:

Feb 14: Venus announced their roadmap for 2021. That includes a new fee for deposits to and withdrawals from the Venus smart contract.
Venus issued multiple reminders of the upcoming changes on various channels.
Apr 15: Venus created proposal VIP-12 (Part 1/3). It includes the implementation of the new fee, although only for withdrawals (redeeming loans).
Apr 18: Venus governance accepted proposal VIP-12 (Part 1/3).
Apr 20: Venus governance executed proposal VIP-12 (Part 1/3).
To date neither Venus’ docs nor the whitepaper on their website mention the withdrawal fees.

Due to the amount of changes, Part 1 is limited to only a few tokens. The proposals for Part 2 and Part 3 followed roughly half a day later.

The storm begins

After the execution of the proposal problems begin to surface:

Autofarm leaks significant funds from some of their Venus-related vaults.
This withdrawal of a user for example sent $5,092 to the Venus Treasury.
Belt also leaks significant funds similar to Autofarm.
This withdrawal of a user for example sent $6,468 to the Venus Treasury.
In both cases every single withdrawal leaks way more money than Venus’ fee for the individual withdrawal should incur. That adds up quickly.
Beefy notifies its users that they’ve withdrawn all user funds from affected Autofarm vaults. They urge users of the affected Belt vault to manually remove their liquidity on Belt as Beefy cannot do that on behalf of its users.
Shortly after, users start having issues withdrawing their funds from Venus-related Autofarm and Belt vaults. Due to the high number of withdrawals happening quickly Venus temporarily ran out of liquidity needed to redeem loans.
Questions of many concerned users keep developers and community moderators busy. The scope of the issues wasn’t fully clear by then. Problems in communication between users and project teams caused further confusion and anger.

How did that happen?

It didn’t take long for users and project teams to look for someone to blame. But who’s actually at fault here? It’s not as clear as it may seem.

Opinions vary widely:

“Venus is to blame for introducing the fees.”
“Venus is to blame for not communicating the change better.”
“Yield farms are to blame for (de)leveraging so inefficiently.”
“Yield farms are to blame for not knowing about the change upfront.”
“Yield farms are to blame for not testing the change upfront.”
“Yield farms are to blame for not communicating the issue faster.”
“Yield farms are to blame for not having security measures to save funds.”
“Yield farms are to blame for relying on other problematic farms.”
“Users are to blame for not doing enough research about risks.”
“Users are to blame for not tracking Venus protocol changes.”
The list goes on…

It’s all of the above. And none. Keep reading and let me explain.

There is no standard for changing smart contracts

This situation is a prime example for a lack of common ground and standards.

If I intend to change a smart contract…

Should I notify teams of protocols that depend on my contract?
How do I know who depends on my contract?
How do I reach them?
How far in advance and how often should I notify them?
How can they test my changes in advance?
What do I do if something is wrong after the change?
What do I do if protocols that depend on my contract now face issues?
What kinds of changes to my contract are actually acceptable?

If my project depends on a smart contract…

Should I track changes in that contract?
Should I track changes in contracts that the contract depends on?
And changes in contracts that these contracts in turn depend on?
Should I notify my users about upcoming changes in these contracts?
How do I reach them?
How far in advance and how often should I notify them?
How can I test changes in these contracts?
What do I do if something is wrong after the change?
What kinds of changes in these contracts do I have to expect?

The systems we rely on

One of the key ideas behind crypto is to build trustless decentral systems. Such systems should not require its participants to trust each other or third parties like governments, intermediaries, or technology companies.

Instead, their participants rely on protocols and smart contracts to verifiably do exactly what they are written to do. Everyone can explore what a certain smart contract does and either agree and use it or reject it.

The same is true for communication between different protocols and smart contracts. In order for a network of them to collaborate they have to rely on each other’s contract terms, i.e. their behavior. If these expectations aren’t met the results are typically either failure or unexpected behavior.

The human aspect

Back to our problem.

Most of the opinions and questions listed revolve around what people did wrong and what people have to do.

If we have to rely on people to maintain and upgrade smart contracts we give up the trustless and the decentral aspect of our system, at least in part.

Is the system still decentral if someone must actively look for changes in smart contracts to check and upgrade dependent contracts in time?
Is the system still trustless if people do upgrade smart contracts and other someone must maintain and upgrade dependent contracts?

Crypto-based decentral systems are still young and evolving. Today we do depend on human communication and active development to maintain and evolve our systems.

But we also need to work out standards how smart contracts can evolve without actually breaking them.

Broken promises

If you conclude a classic contract written in a human language and approved by lawyers then you have certain guarantees.

Fees are a good example. If the contract states a specific fee, then you have to pay exactly that fee. That fee cannot be changed, unless…

you agree to that change.
the potential for a change was agreed upon in the same contract.
you terminate the contract and conclude a new one.

Instead of having an immutable fee, the contract could also

state a certain range for the fee, so that the fee can be changed by the counter-party depending on various factors.
state that a fee is currently not agreed (i.e. 0%) but may be increased by the counter-party depending on various factors but within a certain range.
state that a certain fee is included but may be waived completely by the counter-party (i.e. setting it to 0%).
and so on.

The contract defines terms and is not changed unilaterally.

The contract can however give certain freedom for certain parameters.

Immutable terms

The incident with Venus and yield farms is an example where one party of a contract (yield farm contracts) expects other contract terms than the other party (Venus).

That’s because the contract’s terms have been changed unilaterally.

When initially accepting the contract of Venus the contracts of yield farms were not prepared for newly introduced fees and had no reason to. Therefor their behavior in such a case was undefined and led to a loss of funds.

If there had already been a small fee initially which was then simply increased then those contracts would likely have become less profitable but not have lost funds. Slightly changing the amount of fees has a much smaller impact than introducing a fee that the dependent contract never even considered.

Similarly, the initial Venus contract could have clearly stated that the addition of a fee for redeeming a loan might be added later on. Then dependent contracts could have been prepared from the start.

For users there is also a violation in the smart contract’s terms. Users agree to the contract of Venus the moment they supply money. At that moment the agreement is that they can withdraw without any fees. Venus however has retroactively changed these terms because the new withdrawal fees also incurred a fee for funds supplied before the change.

Still, none of this means that Venus is to blame here. It merely means that different parties have different approaches to the problem of evolving smart contract-based protocols. Their approaches just didn’t seem to go well together in this case.

One can also easily argue that the upgradable nature of Venus’ smart contracts is a condition to accept when agreeing to that contract. It basically means “almost anything can change”.

Most approaches still depend on human interaction. I’m sure everyone involved is working to the best of their knowledge and ability.

So how can protocols evolve then?

If Venus’ tokenomics demands for a withdrawal fee in order to work and Venus stakeholders agree through government vote, then that’s great. The question is how such a change can be achieved without breaking contract terms for existing counter-parties.

Maybe contract changes can be implemented without affecting existing counter-parties? Maybe a new smart contract is required? Usage could transitions from the old contract to the new one at the speed that dependent protocols can manage. If any smart contract is longer maintained but still in use, it would continue to function properly. That is until the liquidity of the old contract depletes. But that again is expected from the old contract.

Status quo is that there is no standard. No consensus on any approach. The industry is young and we need to work things out together.

In their open letter to the community Venus expressed their intent to form an alliance to tackle exactly that problem. I hope that many projects in the crypto industry embrace that opportunity to do that together.

We’re all learning and we’re all in this together.