To my current understanding there seems to be two different types of smart contracts deployed to the EOS mainnet and EOS.IO chains alike.
System contracts
System contracts are the core contracts that all EOS.IO based chains have and make the blocks go around, these are typically written and maintained by EOS.IO developers at B1.
In the event we see a bug in these types of contracts, there’s usually little hesitance to push the updates by the developers. The community is not protesting against bug fixes in core functionality with update authored by the core developers. Bitcoin does the same as demonstrated in the 184bn BTC hack
“Code is Law is not enforced on system level contracts.”
Private contracts
Private as in privately owned and managed, these are all the other contracts developed by the EOS community.
In the event these contracts are compromised it is only up to the dApp developer to fix it if at all possible. These contracts have virtually never been aided by Block Producers in terms of recovery and been otherwise left in the cold.
SX Vaults Contract
The SX vaults contract was the first private contract to ever receive aid from the 2/3 majority of BPs for it’s compromised funds. This naturally struck debate throughout the community with those arguing for it’s special treatment and others against.
Public Contracts
This is where my idea for public contracts come in, Public contracts are available for public utility, either free of charge of if fees are introduced, either pushed back to REX or funding Eden.
Maintained under the wing of Eden and EOS BPs, they are treated as if they are system level contracts where all parties know their true intent.
I would argue that the SX Vaults contracts actually was somewhat of a hybrid between a Private contract and Public contract, as it was msig’d by a large portion of EOS Block Producers with their backing behind it. So much so they had enough confidence in it’s original intent to execute the account freezing of the hacker.
Public Contract Use Cases
eosio.token
While eosio.token is technically a system level contract you could change it to a public contract. This is because this contract hosts just one token EOS but could easily have the ability of hosting thousands if a few lines of code changed.
By the community creating tokens on a shared token contract they get the benefit of
- Not having to worry about code compromises.
- Being in the same boat as thousands of other tokens, (e.g. block explorers, dApps can easily track more tokens if they’re all in the same place)
- RAM saving! It’s quite wasteful to deploy a new contract for every token when they could utilise an existing one.
- Protection against malicious code secretly introduced into a token contract by the dApp developer! In order to prevent token sale, etc. Trust me, I’ve seen this…
SX Vaults
SX Vaults shared a lot of similarity with the current REX token system, and could have been seen as a bank. You deposited your EOS into it, the vault invested it into a few sources of your choosing and you could come back and withdraw when ready.
Given it’s simplicity I think this would have been a great candidate to be a public contract as every person who’d like to adminster their own vault would not need to deploy their own contract.
This creates
- A reliable smart contract platform for anyone to administer a vault.
- A shared ‘protocol’ like system, e.g. if all vaults have the same contract it’s far easier for Block explorers to support them rather than different contracts each with different ways of interacting with them.
And best of all…
User experience!
What is better than empowering the little guy to utilise the magic of Blockchain without the burden of being a smart contract developer to further innovate in our world.