Immutability and Kadena Smart Contracts
TLDR: Most contracts and data stored in them are mutable on Kadena (including by their creators) for various reasons
In this article we’ll cover
- What immutability is and isn’t
- How immutability is handled on Kadena smart contracts
- Levels of trust and safety for smart contracts on Kadena
What is immutability is and isn’t
Immutability means that something cannot be changed. By design, history of transactions on a blockchain are meant to be immutable as they are forever recorded on the blockchain.
However there are many things that are mutable on blockchains. One common use case is updating the balance of a token on a blockchain.
Mutability has nothing to do with who or what can modify data — apart from the scenario where something is immutable, in which case no one can modify the data.
Also immutability has nothing to do with fungible or non-fungible (i.e. NFT) tokens. Here’s a more in-depth article on the distinctions
How immutability is handled on Kadena smart contracts
Kadena smart contracts are designed to be mutable. This was intentional by the Kadena team to allow things like
- Fixing of bugs — this is exactly how a recent core DEX exploit was fixed
- Upgrading contracts — this is exactly how the core KDA coin gets improved, which gave us things like improved cross-chain transfers
- Correctly updating data that was incorrectly set initially
However this also allows downsides where controllers of smart contracts can rewrite contracts and data stored in them. This can lead to things like
- Rug pulls
- Changing functionality of smart contracts to do something users don’t expect
- Maliciously updating data stored in the contract
As you can see, it is a double edged sword. However the issues that come with it are not unique to Kadena
On other blockchains like Ethereum, upgrading the core contract is impossible. However it is common practice use workarounds that allow them to change the underlying implementation of the smart contract via a “proxy” implementation.
Levels of trust and safety for smart contracts on Kadena
There are multiple levels of trust and safety that can be associated with smart contracts. The most common ones are
1. Immutable Smart Contracts
These can never be modified and therefore completely safe from modifications.
The caveat here is that these are not safe from bugs, so this is completely a “trust the code” scenario. For example, there was an exploit found in core DEXs on Kadena which would not have been able to be fixed without upgrade-able smart contracts.
For this reason, there are few to no contracts that behave like this.
2. Kadena Community Controlled Smart Contracts
This only applies to the KDA coin contract but its worthwhile to mention. The official coin contract is upgrade-able only by consensus from the community.
This is in-line with how blockchains guarantee trust, so it’s fairly safe but it also allows the contract to be upgraded over time.
3. Controlled by Trusted Party/ies
These are smart contracts controlled by a trusted party.
It is up-to individuals to determine if the party can be trusted, but for example the Kadena team may be considered a trusted party. An example of a contract they own is the Marmalade ledger on chain 8.
This means that only the trusted party can update the contract and data stored inside it. This doesn’t prevent issues like
- The parties keys getting hacked
- Accidental updates
- Malicious behavior
However this can be reduced by requiring multiple signatures to sign off on changes to the smart contract. This won’t eliminate the risk of issues but it will require more things to go wrong for it to happen.
In practice though, the Kadena team cannot make everything for the community (and it’s likely not their goal) and most things that they do make will require regular parties to implement interfaces / functionality.
4. Controlled by Regular Parties
This is the default on Kadena at the moment and makes up all live community projects at the moment.
This includes every defi (DEXs), coins (apart from KDA) and NFTs live on Kadena.
It is where an individual or team of people can modify the smart contract and the data it holds.
The issues here vary from rug pulls to exploits to accidental mistakes.
The reason this is the default is because #1 comes with risks, #2 is a special edge case and #3 only applies to the Kadena team and in practice still involved regular parties implementing things.
This level of trust/safety is also in line with popular projects on other blockchains like Ethereum due to proxies.
Closing thoughts
This is meant to be an educational article to highlight the risks for projects on Kadena.
Hopefully this article helps folks with their research into projects.
Also this is in no way a judgement of Kadena or the team as they provided something the developer communities on other blockchains were asking for. The issues faced with upgrade-able modules are not unique to Kadena.
