IOST Smart Contract “UPDATE”

“With great power comes great responsibility”

One of the great benefits of IOST Smart Contracts over some other Blockchains is the ability to upgrade a contract it has been deployed. There have been countless times Smart Contracts have been deployed to other Blockchains where bugs and security issues have been found after the fact ~ sometimes resulting in massive loss of funds!

IOST developed a great feature into their Smart Contract platform to help with this problem — the Update Contract feature (

This allows for feature updates and most importantly bug fixes to be rolled out — very simply!

To update a contract, a simple method within the existing contract is checked, if it returns true then the contract is updated:

can_update(data) {

Almost always this method is implemented with a simple check that the owner of the contract is the one performing the update (To ensure nobody else is updating the contract with malicious code!):

can_update(data) {
return blockchain.requireAuth(blockchain.contractOwner(), "active");

But — this gives the contract owner great power!

As Spider Mans’ Uncle Ben is often quoted as saying in the Spider-Man movies…

With great power, comes great resonsibility!

As a user of the contract — you now have to fully trust that the contract owner isn’t going to UPDATE the contract and completely change the mechanisms without you realising! If it were a Consumer DApp for example, a game which held your funds — would you be happy that the contract holder could change the contract and empty it overnight? Change the game rules at whim? Could a distributed exchange change the code and exit with your tokens at will?

Lets take an example imaginary scenario…

A new DApp game sets up — perhaps accepting IOST for plays… building up a large balance over a short period.

But — it has the method setup within their smart-contract. Allowing the contract owner to change the code at any time!

A couple of sample attack patterns….

Exit Scam

  1. You’ve already checked out the source code of the contract and it is safe to use, the owner cannot withdraw funds — so you play the game and have funds entrusted into the contract now.
  2. But — overnight the contract is malicoulsy updated! The contract owner exits with all funds!!
  3. Everything is lost!

Rule Change

  1. Again, you check the source contract (Or someone you trust does) and you feel safe using the DApp…
  2. Over a longer period the contract owner keeps applying various UPDATEs behind the scenes — quickly changing the rules when it suites them so they WIN more and then changing the contract code back… hopefully nobody notices!
  3. Over a long period it could be they end up with a big win!

So at we have come up with a solution that works out well for everyone. It still allows for bug fixes and feature improvements —while giving the users the comfort and confidence that the Smart Contract will not be changed without their knowledge!

The Solution

We propose that we change the methods so that they also check a second variable — a .

So before any update can be applied — a predefined period of time must of elapsed (E.g. 6 hours, 12 hours — whatever the community is comfortable with).

This gives time for any users of the Smart Contract to withdraw any funds, cancel any trades (Or any other financial important activity) before the update if they wish — they can always put their funds back in after the update!

So the process will be:

  1. The Smart Contract owner informs the community of a pending Update — with the reasons (Security or Bug Fix, Feature Update etc)
  2. The Smart Contract owner then triggers the timelock. This sets the timelock to the current time + the minimum period (E.g. 12 hours)
  3. The method will now return until the elapsed time has passed (12 hours)
  4. After 12 hours — the Smart Contract owner can update the code with the update!


trigger_timelock() {
const TIMELOCK_MIN = 120;
// debug, 120 secs - should be several hrs
if(!blockchain.requireAuth(blockchain.contractOwner(), "active"))
return false; // only contract owner can set timelock
storage.put("update_timelock", Math.floor((block.time / 1000000000) + TIMELOCK_MIN).toString()); // store in second accuracy
stats_timelock() {
return storage.get("update_timelock");
// available for public checks
can_update(data) {
if(!blockchain.requireAuth(blockchain.contractOwner(), "active"))
return false;
if( new Int64 (storage.get("update_timelock")||block.time) * 1000000000 > block.time) {
return false;
} else {
// Any other checks performed here...
// (e.g. Check any pending withdrawals are complete)
..... // remove the previous timelock...
return true;

In our opinion — this should now be the standard way of implementing the method in all IOST Smart Contracts that need to use the Update functionaility.

We’ve implemented this in our own smart-contract for ~ check the contract out at:

Share this post if you agree!


BLOCKHEAD.networks is a team of Crypto developers that have been working the space since 2016. We specialize in Ethereum, Tron, TomoChain and IOST but also work in bespoke Blockchain projects.

We now publish our own projects with our first being: has also hosts a full IOST node. We aim to give back to the community through publishing development articles (Like this one), bring new users into the community (We are already doing this with and Airdropping our imoon token to voters!

Vote for our node at:



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store

blockchain expertise since 2016 ~ Ethereum, Bitcoin, EOS, Tron, Tomo, IOST and others! ~ Enterprise development & Consumer DApps ~ Security Audits