StoryPress reloaded ... twice!!

StoryPress.info is based on a smart contract (a few of them actually) running on the Fantom blockchain. Here is why we had to redeploy the main StoryPress smart contract ... twice.

Re-entrancy vulnerability

Ok, this is a classic one, which we should be very ashamed of, but the StoryPress smart contract was vulnerable to a re-entrancy attack. Was it a big one? Could your cherries be stollen?

Well no, not really. But a malicious user could figure out a way to create an account on behalf of a smart contract that he owns, without burning a cherry token. But that cherry that every new account must pay to start contributing StoryPress, would still be registered to be burnt. So that would create an imbalance in the StoryPress smart contract.

This would have absolutely no gain for the attacker. That wouldn't allow him (or her, you know how girls can also get) except the pleasure to mess StoryPress's internal balance up.

So we decided to fix that small issue and had to redeploy the contract.

Loosing the state

The problem with redeploying an upgraded version of a smart contract is not that you have to change its address here and there so that your website interface is up to date with that change. The problem is that you loose the state of the now obsolete smart contract. Meaning, you loose all references to stories, comments, and reactions.

Kind of annoying.

The good thing is that all people (but one nice commentor) who had contributed to StoryPress so far are friends and could be contacted so that they could put their stories back if they wanted to.

The stories hadn't vanished, as they are stored on IPFS. We provided our authors with the IPFS content ID of their stories, and all they had to do is re-publish them, by just pasting the content ID at the bottom of the write page.

Cherrific ... take 3

Well, we had another issue. Mulling over StoryPress.info's onboarding experience, we realised that we could make things easier by allowing our users to send some of their internal cherry token balance to each other.

So we fully implemented the ERC-20 token standard for the cherry tokens that you have put inside the StoryPress smart contract (that's a little trick you can do to save gas when you contribute to StoryPress). This CHRY that you own inside the StoryPress smart contract are called CHRF and have a little logo of their own:

And they will make it easier to onboard new users. If you want to know everything about CHRF, please read CHRF: use Cherrific internal balance.

So yes, we had to change the contract, test this new feature, and ... redeploy.

Because we now had around 30 stories published, we even developed a small script to automatically re-publish our old stories inside the new StoryPress smart contract instance.

Yeah, what a pain. That's the issue with non-upgradable smart contracts. But the problem with upgradable smart contract is that you cannot trust them ... because if they can be upgraded, then it means that the rules can be changed whenever we want. Who could trust that?

If you want to read more about my opinion on upgradable smart contracts, you can have a look at I'm a trust maxi.

Edit: a few months after this, The StoryPress smart contract was redeployed once more, to implement NFT functionalities, and finally get rid of this internal balance bad idea. You can read the reflections that introduced these changes in StoryPress: 4 design mistakes.