Renouncing Contract Ownership
Last updated
Last updated
If you come from the Ethereum development landscape, you may be familiar with the idea of "renouncing your contract" so that you can provide peace of mind to your users. This allows people to trust that the contract will not be updated to add a backdoor, or with code that unintentionally introduces a critical security risk.
Keep in mind that this is completely useless if your contract is not open source, with a reproducible WASM hash. Otherwise, it's meaningless if you can't update your contract - because no one knows what code is inside the contract in the first place, and they have no guarantees of safety/security.
Things on WAX work a little bit differently. We've briefly discussed permission structures in other parts of this guide. As of this writing, every account on WAX has an ownerand activepermission. These permissions always exist regardless of what you do with your contract keys.
It is important to note that there is a proposal to update the WAX system contracts to allow for "lite accounts", which may or may not have both active and owner keys. However, given the context of this page (smart contracts), this is likely irrelevant anyway - as you will most likely need both active and owner keys in order to deploy a contract, even if the idea of this proposal comes into existence.
Anyway, as far as renouncing ownership goes, there are a couple of options - and a couple of things to take into consideration.
First, you have to consider if it's actually a good idea to prevent the contract from ever being updated. What happens if you realize there's some bad code that needs to be fixed? Or what happens if your contract relies on a 3rd party contract, and that 3rd party updates their own contract - now you're stuck in a situation where you might have user assets locked in your contract, and can't do anything to get them out.
In a case like this, multisig permission structures are usually a good middleground. For instance, you can set the activeand ownerkeys on your contract to require signature of eosio.prods@active.
This would require 15 of the top 21 block producers on WAX to sign a transaction if you want to update your contract. This way, people know that you can't update things at will - but you do have the option to update if needed, provided you can prove to the block producers that the new code is useful and safe.
Keep in mind, organizing 15 block producers to sign a transaction is easier said than done. People have busy lives, not everyone is always available to read your code and approve a transaction.
Another option you have is a multisig that requires only a few trusted parties. Take a look at the permission structure for WaxFusion's smart contracts, for example.
We require 4 out of 6 signatures - these parties include WaxFusion team, official WAX team, OIG, and a couple trusted block producers on WAX. This still provides plenty of trust, but makes it a bit easier to organize a multisig if we ever need to update the contracts.
Notice that the WAX team has a weight of 2 votes on this structure - so either they sign and 2 other parties sign - or, if we ever want to sign without the WAX team, ALL 4 of the other parties must sign. This was mostly done because the WAX team funded development of WaxFusion, and we wanted to give them as much control as possible, without being 100% dependent on them to sign transactions.
Important: the following should only be used in the case where you are 100% sure that you never plan on updating your contract again. You will be unable to reverse this process ever, under any circumstances.
If you've decided that you aren't interested in multisig structures, and you want to completely renounce your contract - never being able to update it again - you can simply set the permissions on your account to eosio.null@active. This is an account with no private keys, it is essentially used as a "burn" or "renouncing" address, because it can't be accessed - and can't access anything.
This is your best option (that I'm aware of) on WAX, because you can't simply "throw away your keys" here. You have to set the permissions to something, and eosio.null is what you can set them to if you are trying to throw the keys away.
Always test very thoroughly on testnet, before you go and deploy any of these things on mainnet. You will save yourself a lot of headaches, and prevent irreversible damage.
If your contract needs to execute/sign inline actions (which is most likely does), don't forget to add eosio.code permission in addition to whatever multisig structure you use. eosio.code should be able to execute actions on its own, without any multisig etc.