Building bitsave on algorand has been the longest of work on algorand. Bitsave started when algorand still had just pyteal aside pure teal for working on their smart contracts. Bitsave is a SaveFi protocol for enabling savings on the crypto market.

This requires several features which were not provided by algorand as at that moment.

One of the problems was structs which was really required since a saving is an object also a user who olds the savings which would have been a mapping. However, algorand as at that time supported a linear storage technique and hashing and other techniques were not good options then.

However, we found an alternative structure to use our fond structure of parent-child contract system. This way, we could make the child contract for each user and the parent contract some sort of manager. A problem remained, how do we map the children to the parent. Well, algorand AVM then had a localStorage concept where each user has a sort of heap of memory which is allocated to each contract they opt to bringing the concept of join bitsave.

After sorting this, what about the child contract’s savings structs. Thanks to support on the algorand team and the logic we came up with, we could “hash” the savings with some basic concatenation for the name and the field. This technique worked well and we had the first version of the contract.

However, with this logic, it became difficult to manage the data and just very small amount of savings could be made on this contract due to the limited byte storage for globalStorage on algorand.

At this time, algorand released beaker. Beaker is a python framework to make working with AVM way easier. We had to start porting the contract to use this opportunity. After porting though, the contract worked well except a few little issues. While working on this, beaker launched an update which was recommended to work with. This was the v1. As expected, a lot of breaking changes came in which of course should’ve been expected but is necessary, security and main features were implemented. We contributed a few to this, documentation, supports, reviews, even community wise.

After this update, it became really difficult to work with even though the framework was better. Should use boxes or not? Anyways, the issues were with the join bitsave transaction this time around. However, after a while of debugging, reading and documentation scraping, we figured out the issues and fixed them. Also, the algorand’s DappFlow made this way easier and their algokit release made development a whole lot easier and interesting. There were points of installing a node before.

The initial UI was integrated to work with this but needed more work. In this attempt, work paused on the contract and commenced intensely on the UI. The UI had some issues this time around. Even after figuring out this, beaker’s implementation for the contract used a relatively old version and the generated artifacts needed an update for the most current implementations on algorand.

So what again, update the contract using the latest construct puyapy. This is a beautiful one from algorand and you can basically write python directly. Yeah, supported with beaker and all the work from past on algorand. This issues were due to major dependency on testing stages of frameworks and not following their semver requirements. Also, the need to update made things worse but could be avoided especially now with the stable features from algorand.